【架构-案例】聊天系统

参考：

https://my.oschina.net/vivotech/blog/17778514 百万级群聊的设计实践

微博的设计

关键设计：

通信方案选型：即时通信常见的通信技术有短轮询、长轮询、Server-Sent Events (SSE)、Websocket。Websocket 适用于实时双向通信的场景，实时性好，且服务端、前端都有比较成熟的三方包

消息存储：群聊消息的保存方式，主流有 2 种方式：读扩散、写扩散

读扩散
就是所有群成员共用一个群信箱，当一个群产生一条消息时，只需要写入这个群的信箱即可，所有群成员从这一个信箱里读取群消息。
优点：写入逻辑简单，存储成本低，写入效率高。

缺点：读取逻辑相对复杂，要通过消息表与其他业务表数据聚合；消息定制化处理复杂，需要额外的业务表；可能还有 IO 热点问题。很常见的场景，展示用户对消息的已读未读状态，这个时候公共群信箱就无法满足要求，必须增加消息已读未读表来记录相关状态。还有用户对某条消息的删除状态，用户可以选择删除一条消息，但是其他人仍然可以看到它，此时也不适合在公共群信箱里拓展，也需要用到另一张关系表，总而言之针对消息做用户特定功能时就会比写扩散复杂。

写扩散
每个群成员拥有独立的信箱，每产生一条消息，需要写入所有群成员信箱，群成员各自从自己的信箱内读取群消息。

优点是读取逻辑简单，适合消息定制化处理，不存在 IO 热点问题。

缺点是写入效率低，且随着群成员数增加，效率降低；存储成本大。
所以当单群成员在万级以上时，用写扩散就明显不太合适了，写入效率太低，而且可能存在很多无效写入，不活跃的群成员也必须得有信箱，存储成本是非常大的，因此采用读扩散是比较合适的。
据了解，微信是采用写扩散模式，微信群设定是 500 人上限，写扩散的缺点影响就比较小。　　

消息有序性：单用户保持有序、推拉结合、

消息可靠性：TCP传输、增加ACK机制，最终一致性设计

未读数统计: