要实现一整套能用于大用户量、高并发场景下的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。