
群组信息应该持久化保存在 db 中,群组相关的操作在群组服务中进行写入和读取,通过 api 对群组进行操作(比如添加成员)那么将会采用一致性 hash 通过群组 id 找到对应的群组服务器中进行业务操作,那么群组信息写入后缓存的操作逻辑有两种:
1:对应请求后从 db 读取缓存在内存中加读写锁维护,进行写入时先写内存后写 db ,读只会读内存
2:纯粹作为缓存来读取,有写入时则删除缓存,后续请求需要再从 db 读取数据
第一种的问题是:如果群组集群有服务器 a 宕机,那么一个群组(id=xxx)就会被分配到新的服务器 b 上,当 b 服务器在写入时,a 服务器恢复上线就会造成 db 层数据不一致;或者是 b 服务器服务了一段时间后,a 重新上线,该群组又会回到 a 上处理,过了段时间又宕机,这时群组 xxx 又被分配到了 b 上,可 b 上的内存数据是旧数据 如果采用第一种感觉对 db 的操作会过于频繁,有什么更好的方案吗
1 codegenerator 2024 年 7 月 24 日 肯定是第二种啊,但是想要优雅就需要特殊的技巧 第一种因为要在分布式环境下保持内存与 db 的一致性太复杂了 |
2 coderxy 2024 年 7 月 24 日 前置逻辑就是错的, 群组不是游戏的房间, 不会说某个群组的信息就在某个具体的服务器上, 群组信息存 db 即可,redis 缓存一份也行,都是无状态的。 im 不是游戏,im 是无状态的。 最多只有最前端的 gateway 需要记录一下某个用户在某个 gateway 上,勉强算是有一点点状态逻辑。 |
4 3IOhG7M0knRu5UlC 2024 年 7 月 24 日 via Android 自相矛盾 |
5 feiyan35488 2024 年 7 月 24 日 服务应该是无状态的,群组缓存直接使用 redis ,把状态抽离出来 |
6 R4rvZ6agNVWr56V0 2024 年 7 月 25 日 任何随时扩容的服务都应保持无状态;任何需要持久化的数据都应及时落盘; CAP 、CAP 还是 CAP 。 |
7 wkong 2024 年 7 月 25 日 要限制写入的节点只有一个,其他节点只能读。 参考 raft 选举机制 |
8 nodesolar 2024 年 7 月 26 日 用户的归属群组存 redis 即可,以前基于 goim 搞过. |