群组信息应该持久化保存在 db 中,群组相关的操作在群组服务中进行写入和读取,通过 api 对群组进行操作(比如添加成员)那么将会采用一致性 hash 通过群组 id 找到对应的群组服务器中进行业务操作,那么群组信息写入后缓存的操作逻辑有两种:

1:对应请求后从 db 读取缓存在内存中加读写锁维护,进行写入时先写内存后写 db ,读只会读内存
2:纯粹作为缓存来读取,有写入时则删除缓存,后续请求需要再从 db 读取数据

第一种的问题是:如果群组集群有服务器 a 宕机,那么一个群组(id=xxx)就会被分配到新的服务器 b 上,当 b 服务器在写入时,a 服务器恢复上线就会造成 db 层数据不一致;或者是 b 服务器服务了一段时间后,a 重新上线,该群组又会回到 a 上处理,过了段时间又宕机,这时群组 xxx 又被分配到了 b 上,可 b 上的内存数据是旧数据 如果采用第一种感觉对 db 的操作会过于频繁,有什么更好的方案吗

最新回复 (5)
  • codegenerator5月前
    引用2
    肯定是第二种啊,但是想要优雅就需要特殊的技巧
    第一种因为要在分布式环境下保持内存与 db 的一致性太复杂了
  • coderxy5月前
    引用3
    前置逻辑就是错的, 群组不是游戏的房间, 不会说某个群组的信息就在某个具体的服务器上, 群组信息存 db 即可,redis 缓存一份也行,都是无状态的。
    im 不是游戏,im 是无状态的。 最多只有最前端的 gateway 需要记录一下某个用户在某个 gateway 上,勉强算是有一点点状态逻辑。
  • voidmnwzp楼主5月前
    引用4
    @coderxy 在微服务设计下 群组服务器是负责维护信息和根据群组路由到具体 gateway 的服务,对 gateway 来说只是将查询群组信息和具体业务操作抽离出来作为单独可横向扩容的服务
  • GooMS5月前
    引用5
    自相矛盾
  • feiyan354885月前
    引用6
    服务应该是无状态的,群组缓存直接使用 redis ,把状态抽离出来
  • 回复请 登录 or 快速注册
返回