写扩散: 简单,但是群里面每个人都要写一遍缓存.数据量有点大,而且增加网络消耗(比如写redis的时候).读扩算: 只写一份到缓存,拉取的时候,从这个群缓存消息里面拉,需要增加一点逻辑处理,方便在所有群成员都拉取完后删掉缓存数据...群方式在线的,msg只有一份到db中, index还是写扩散到cache和db中.离线的,缓存中,写扩散(msg和index),如果缓存失效,则穿透到db中拉取.对于群消息,每条消息都需要拉取群成员的在线状态....如果存放在redis,拉取会太过频繁.连接数会暴增,并发过高.....这样保证消息不丢.服务端确保msgid生成器的极度高的可用性,并且递增, 通过msgid的大小,来保证消息的顺序详细说明消息防丢失机制为了达到任意一条消息都不丢的状态,最简单的方案是手机端对收到的每条消息都给服务器进行一次..., 需要qps到3w.之前测试redis的时候, 有测试过,如果并发太高,会导致拉取redis耗时较长,超过3s左右.正常情况下,一个人发送一条消息需要耗时至少5s左右(6-8个字).要深入提高IM技术