共计 3134 个字符，预计需要花费 8 分钟才能阅读完成。
要实现一整套能用于大用户量、高并发场景下的 IM 群聊，技术难度远超 IM 零碎中的其它性能，起因在于：IM 群聊音讯的实时写扩散个性带来了一系列技术难题。
举个例子：如一个 2000 人群里，一条一般音讯的收回问题，将霎时写扩散为 2000 条音讯的接管问题，如何保障这些音讯的及时、有序、高效地送达，波及到的技术问题点切实太多，更别说个别场景下万人大群里的炸群音讯难题了更别说个别场景下万人大群里的炸群音讯难题了。
这也是为什么个别中大型 IM 零碎中，都会将群聊独自拎进去思考架构的设计，独自有针对性地进行架构优化，从而升高整个零碎的设计难度。
所谓的群聊音讯零碎，就是一种多对多群体聊天形式，譬如直播房间内的聊天室对应的服务器端就是一个群聊音讯零碎。
零碎名词解释：
1）Client : 音讯发布者【或者叫做服务端群聊音讯零碎调用者】，publisher；
2）Proxy : 零碎代理，对外对立接口，收集 Client 发来的音讯转发给 Broker；
3）Broker：零碎音讯转发 Server，Broker 会依据 Gateway Message 组织一个 RoomGatewayList【key 为 RoomID，value 为 Gateway IP：Port 地址列表】，而后把 Proxy 发来的音讯转发到 Room 中所有成员登录的所有 Gateway；
4）Router：用户登录音讯转发者，把 Gateway 转发来的用户登入登出音讯转发给所有的 Broker；
5）Gateway：所有服务端的入口，接管非法客户端的连贯，并把客户端的登录登出音讯通过 Router 转发给所有的 Broker；
6）Room Message : Room 聊天音讯；
7）Gateway Message : Room 内某成员 登录 或者 登出 某 Gateway 音讯，蕴含用户 UIN/RoomID/Gateway 地址 {IP：Port} 等音讯。
当一个 Room 中多个 Client 连贯一个 Gateway 的时候，Broker 只会依据 RoomID 把房间内的音讯转发一次给这个 Gateway，由 Gateway 再把音讯复制多份别离发送给连贯这个 Gateway 的 Room 中的所有用户的客户端。
这套零碎有如下特点：
1）零碎只转发房间内的聊天音讯，每个节点收到后立刻转发进来，不存储任何房间内的聊天音讯，不思考音讯失落以及音讯反复的问题；
2）零碎固定地由一个 Proxy、三个 Broker 和一个 Router 形成；
3）Proxy 接管后端发送来的房间音讯，而后依照肯定的负载平衡算法把音讯发往某个 Broker，Broker 则把音讯发送到所有与 Room 有关系的接口机 Gateway；
4）Router 接管 Gateway 转发来的某个 Room 内某成员在这个 Gateway 的登出或者登录音讯，而后把音讯发送到所有 Broker；
5）Broker 收到 Router 转发来的 Gateway 音讯后，更新（增加或者删除）与某 Room 相干的 Gateway 汇合记录；
6）整个零碎的通信链路采纳 UDP 通信形式。
从以上特点，整个音讯零碎足够简略，没有思考扩缩容问题，当零碎负载达到极限的时候，就从新再部署一套零碎以应答后端 client 的音讯压力。
这种解决形式实质是把零碎的扩容能力甩锅给了后端 Client 以及前端 Gateway：每次扩容一个零碎，所有 Client 须要在本地配置文件中增加一个 Proxy 地址而后全副重启，所有 Gateway 则须要再本地配置文件增加一个 Router 地址而后全副重启。
这种“幸福我一人，辛苦千万家”的扩容应答形式，必然导致公司外部这套零碎的使用者口碑载道，下一阶段的降级就是必然的了。
接下来迫切要解决的：零碎稳定性
零碎具备了可扩展性仅仅是零碎可用的初步，整个零碎要保障最低粒度的 SLA（0.99），就必须在两个维度对系统的可靠性就行感知：音讯提早和零碎外部组件的高可用。
音讯提早
精确的音讯提早的统计，通用的做法能够基于日志系统对零碎所有音讯或者以肯定概率抽样后进行统计，但限于人力目前没有这样做。即时通讯聊天软件开发能够征询蔚可云。
目前应用了一个办法：通过一种结构一组伪用户 ID，定时地把音讯发送给 proxy，每条音讯通过一层就把在这层的进入工夫和收回工夫以及组件本身的一些信息填入音讯，这组伪用户的音讯最终会被发送到一个伪 Gateway 端，伪 Gateway 对这些音讯的信息进行归并统计后，即可计算出以后零碎的均匀音讯延迟时间。
通过所有音讯的均匀提早能够评估零碎的整体性能。同时，因为零碎音讯路由的哈希形式已知，当固定工夫内伪 Gateway 没有收到音讯时，就把音讯当做发送失败，当某条链路失败肯定次数后就能够产生告警了。
高可用
下面的办法同时可能检测某个链路是否出问题，然而链路具体出问题的点无奈判断，且实时性无奈保障。
为了保障各个组件的高可用，零碎引入了另一种评估办法：每个档次都给后端组件发送心跳包，通过心跳包的提早和成功率判断其下一级组件的以后的可用状态。
譬如 proxy 定时给每个 Partition 内每个 broker 发送心跳，能够根据心跳的成功率来疾速判断 broker 是否处于“假死”状态（最近业务就遇到过 broker 过程还活着，然而对任何收到的音讯都不解决的状况）。
同时依附心跳包的提早还能够判断 broker 的解决能力，基于此提早值可在同一 Partition 内多 broker 端进行负载平衡。
进一步优化：音讯可靠性
公司外部外部原有一个走 tcp 通道的群聊音讯零碎，然而通过除夕一次大事变（简直全线崩溃）后，相干业务的一些重要音讯改走这套基于 UDP 的群聊音讯零碎了。这些音讯如服务端下达给客户端的游戏动作指令，是不容许失落的，但其特点是绝对于聊天音讯来说量十分小（单人 1 秒最多一个），所以须要在目前 UDP 链路传递音讯的根底之上再构建一个可靠消息链路。
UDP 通信的实质就是假装的 IP 通信，TCP 本身的稳定性无非是重传、去重和 ack，所以不思考音讯程序性的状况下能够通过重传与去重来保障音讯的可靠性。
基于目前零碎的可靠消息传输流程如下：
1）Client 给每个命令音讯根据 snowflake 算法配置一个 ID，复制三份，立刻发送给不同的 Proxy；
2）Proxy 收到命令音讯当前随机发送给一个 Broker；
3）Broker 收到后传输给 Gateway；
4）Gateway 接管到命令音讯后依据音讯 ID 进行反复判断，如果反复则抛弃，否则就发送给 APP，并缓存之。
失常的音讯在群聊音讯零碎中传输时，Proxy 会依据音讯的 Room ID 传递给固定的 Broker，以保障音讯的有序性。
当线上须要部署多套群聊音讯零碎的时候，Gateway 须要把同样的 Room Message 复制多份转发给多套群聊音讯零碎，会增大 Gateway 压力，能够把 Router 独自独立部署，而后把 Room Message 向所有的群聊音讯零碎转发。
Router 零碎原有流程是：Gateway 依照 Room ID 把音讯转发给某个 Router，而后 Router 把音讯转发给上游 Broker 实例。新部署一套群聊音讯零碎的时候，新零碎 Broker 的 schema 须要通过一套约定机制告诉 Router，使得 Router 本身逻辑过于简单。
相似于 Broker，Router Partition 也以 2 倍扩容形式进行 Partition 程度扩大，并通过肯定机制保障扩容或者 Partition 外部各个实例进行运行或者新启动时，尽力保证数据的一致性。
Router Replica 收到 Gateway Message 后，replica 先把 Gateway Message 转发给 Partition 内各个 peer replica，而后再转发给各个订阅者。Router 转发音讯的同时异步把音讯数据写入 Database。
