client A
2. 数据落盘
具有push能力的MQ
4. 本地缓存维护自己持有的长连接，自己根据group房间号去分发消息，维护自己本地缓存
redis cache
IM SDK
4. 将消息传递给长连接userB在的机器落本地缓存，提高性能，减少redis压力
2. 数据落盘限流和选择性丢弃
接受写请求
session读写
client B
分发连接
直播聊天室/群聊
查询用户在哪台机器上
推模式，参考Linux底层内存逻辑页和物理页映射的数据结构页表（64位操作系统有4级页表）。用分层法解决 推送的风暴系数
IM服务 流程设计
传统客户端：客户端来说，一般每秒接收几十条消息就已经是极限了。
这里采用推还是拉模式，值得思考参考： RocketMQ的push模式是伪推模式，建议实时性不是要求非常高，建议使用pull模式，也可以按业务部分推（vip通道），部分拉（普通用户）一定推可以做多级推送，或者类似微信做群聊人数限制
IM Server Cluster
3. 寻找userB长连接在哪
群聊application，负责推送
智能负载均衡
5. 传递消息给B
路由中心
到了后期，worker会成为瓶颈，出现消息积压，参考微信的做法
微信的后台具有多IDC分布的特点，不同IDC与苹果推送服务（APNs）之间的网络质量参差不齐，部分链路故障频发。
本地缓存+增量同步
优化点一：拆，按两个纬度拆：核心业务和非核心业务，容易出现瓶颈和不容易出现瓶颈，把消息的发和收从接入层到业务处理层都进行隔离拆分容易出现瓶颈的长连接入服务比如下图的application独立进行部署优化点二：自动扩容、缩容。设定一些阈值比如：直播间人数、发消息QPS，机器性能指标（带宽、系统负载、IOPS）自动扩容，缩容。优化点三：智能负载均衡。可以根据机器的负载来选择哪个机器与其建立长连接优化点四：从业务上入手，比如vip用户建立vip通道推送，礼物使用礼物通道（类似红包），使用二次拆的动作转化成读，从而降低压力
1. 发送消息给B
1. 发送消息群A
根据nodeId，找到clientB连接的机器IP，然后传递数据过去
worker
mq: 消息中心
IM架构
Sharding
消息中心
mysql: 数据落盘
Application
client C
p2p
长连接
跨机消费模式。其目标是实现一个去中心化、自适应的弹性消费网络实现：1. mq消息做广播推送，并且能做加权发送消息2. worker能自动识别自己的负载，然后通知mq自己的负载，mq去计算权值
发送了一条消息，比如是这个主播的vip第一人
3. 分组广播策略 订阅topicapplication去维护哪些消息需要发送给哪些用户
负载均衡器分发连接，Rest请求
数据落盘
智能负载均衡。可以根据机器的负载来选择哪个机器与其建立长连接如果是群/房间号，发起消费topic：群id
5. 传递消息给C
房间号:clientB，clientCclientB：nodeBclientC；nodeC维护在线状态
注册，登陆等等
发送给不在线的用户
自动扩容、缩容
sync data asyncexample：RocketMQ，Kafka
... ...
redis: 查询用户在哪台机器上
不在线的用户第三方push
MySQL
