聊天室架构演进

[katsusan]

refer: https://mp.weixin.qq.com/s?__biz=MjM5ODYwMjI2MA==&mid=2649757129&idx=1&sn=bfbac9fecfcf55b6bff25e59dc96d903&chksm=becc86b289bb0fa4236a0575a0fc7effdfe00c2af90e05be0828a78c0fa21fdab0e741a92377#rd

1. 聊天室1.0架构

消息框架选型：读扩散。 // 微信群采用写扩散。

x	微信群	聊天室
参与人数	<= 500	> 1W
关系链	有	无
成员流动	低	高
离线消息	关注	不关注

First Header	Second Header
Content from cell 1	Content from cell 2
Content in the first column	Content in the second column

通信模式：longpolling模式。 // 不用websocket的原因：(1) ws主要用于推模式，容易丢消息。(2) 推模式需要维护在线列表。(3) longpolling本质是短连接，客户端实现简单。

1.1 无状态cache

读扩散会造成巨大的IO压力，因此需要加入cache。普通的cache有状态且可穿透， 通过异步线程任务来解决这一点。(实时通知、异步拉取、兜底轮训、无锁读取←读写表分离+原子切换、sect化部署)

缺点：流量不可控、大直播信令丢失、单点瓶颈、无在线历史统计、

2. 聊天室2.0架构

针对丢信令消息：打优先级标记、cache内分表、优先收取/下发。

分布式在线统计：拆key+读写分离+异步聚合落盘。

历史在线统计：基于hyperloglog

x	bigtable	bloomfilter	hyperloglog
小样本准确率	高	较高	较高
大样本准确率	高	较高	较高
存储量	大	较大	小
代码复杂度	低	较低	低
并发	低	较高	高

基数小的时候hyperloglog会有误差因此可以结合bigtable和hyperloglog。 即小基数时双写bigtable和hyperloglog，以bigtable的select结果为准，大基数时只写hyperloglog以其估算值为准， 在线统计模块定期把在线列表merge到hyperloglog避免丢数据(?)。

流量隔离vipsect：对大小直播间进行策略分流。

[katsusan]

related 1：

https://zhuanlan.zhihu.com/p/77289303 https://www.jianshu.com/p/55defda6dcd2 hyperloglog 基数统计(一组集合中求不重复元素的个数)。

// TODO