本文原题“搭建高性能的IM系统”，作者“刘莅”，内容有修订和改动。为了尊重原创，如需转载，请联系作者获得授权。

1、引言

相信很多朋友对微信、QQ等聊天软件的实现原理都非常感兴趣，笔者同样对这些软件有着深厚的兴趣。而且笔者在公司也是做IM的，公司的IM每天承载着上亿条消息的发送！

正好有这样的技术资源和条件，所以前段时间，笔者利用业余时间，基于Netty开发了一套基本功能比较完善的IM系统。该系统支持私聊、群聊、会话管理、心跳检测，支持服务注册、负载均衡，支持任意节点水平扩容。

这段时间，网上的一些读者，也希望笔者分享一些Netty或者IM相关的知识，所以今天笔者把开发的这套IM系统分享给大家。

本文将根据笔者这次的业余技术实践，为你讲述如何基于Netty+Zk+Redis来搭建一套高性能IM集群，包括本次实现IM集群的技术原理和实例代码，希望能带给你启发。

学习交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

（本文已同步发布于：http://www.52im.net/thread-3816-1-1.html ）

2、本文源码

主地址：https://github.com/nicoliuli/chat

备地址：https://github.com/52im/chat

源码的目录结构，如下图所示：

3、知识准备

* 重要提示：本文不是一篇即时通讯理论文章，文章内容来自代码实战，如果你对即时通讯（IM）技术理论了解的太少，建议先详细阅读：《新手入门一篇就够：从零开发移动端IM》。

可能有人不知道 Netty 是什么，这里简单介绍下：

Netty 是一个 Java 开源框架。Netty 提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。

也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。

Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 Socket 服务开发。

以下是有关Netty的入门文章：

• 1）新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析
• 2）写给初学者：Java高性能NIO框架Netty的学习方法和进阶策略
• 3）史上最通俗Netty框架入门长文：基本介绍、环境搭建、动手实战

如果你连Java的NIO都不知道是什么，下面的文章建议优先读：

• 1）少啰嗦！一分钟带你读懂Java的NIO和经典IO的区别
• 2）史上最强Java NIO入门：担心从入门到放弃的，请读这篇！
• 3）Java的BIO和NIO很难懂？用代码实践给你看，再不懂我转行！

Netty源码和API的在线查阅地址：

• 1）Netty-4.1.x 完整源码（在线阅读版）
• 2）Netty-4.1.x API文档（在线版）

4、系统架构

系统的架构如上图所示：整个系统是一个C/S系统，客户端没有做复杂的图形化界面而是用Java终端开发的（黑窗口），服务端IM实例是Netty写的socket服务。

ZK作为服务注册中心，Redis用来做分布式会话的缓存，并保存用户信息和轻量级的消息队列。

对于整个系统架构中各部分的工作原理，我们将在接下来的各章节中一一介绍。

5、服务端的工作原理

在上述架构中：NettyServer启动，每启动一台Server节点，都会把自身的节点信息，如：ip、port等信息注册到ZK上（临时节点）。

正如上节架构图上启动了两台NettyServer，所以ZK上会保存两个Server的信息。

同时ZK将监听每台Server节点，如果Server宕机ZK就会删除当前机器所注册的信息（把临时节点删除），这样就完成了简单的服务注册的功能。

6、客户端的工作原理

Client启动时，会先从ZK上随机选择一个可用的NettyServer（随机表示可以实现负载均衡），拿到NettyServer的信息（IP和port）后与NettyServer建立链接。

链接建立起来后，NettyServer端会生成一个Session（即会话），用来把当前客户端的Channel等信息组装成一个Session对象，保存在一个SessionMap里，同时也会把这个Session保存在Redis中。

这个会话特别重要，通过会话，我们能获取当前Client和NettyServer的Channel等信息。

7、Session的作用

我们启动多个Client，由于每个Client启动，都会先从ZK上随机获取NettyServer的的信息，所以如果启动多个Client，就会连接到不同的NettyServer上。

熟悉Netty的朋友都知道，Client与Server建立接连后会产生一个Channel，通过Channel，Client和Server才能进行正常的网络数据传输。

如果Client1和Client2连接在同一个Server上：那么Server通过SessionMap分别拿到Client1和Client2的会话，会话中包含Channel信息，有了两个Client的Channel，Client1和Client2便可完成消息通信。

如果Client1和Client2连接到不同的NettyServer上：Client1和Client2要进行通信，该怎么办？这个问题放在后面解答。

8、高效的数据传输

无论是IM系统，还是分布式的RPC框架，高效的网络数据传输，无疑会极大的提升系统的性能。

数据通过网络传输时，一般把对象通序列化成二进制字节流数组，然后将数据通过socket传给对方服务器，对方服务器拿到二进制字节流后再反序列化成对象，达到远程通信的目的。

在Java领域，Java序列化对象的方式有严重的性能问题，业界常用谷歌的protobuf来实现序列化反序列化（见《Protobuf通信协议详解：代码演示、详细原理介绍等》）。

protobuf支持不同的编程语言，可以实现跨语言的系统调用，并且有着极高的序列化反序列化性能，本系统也采用protobuf来做数据的序列化。

关于Protobuf的基本认之，下面这几篇可以深入读一读：

1. 《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
2. 《全方位评测：Protobuf性能到底有没有比JSON快5倍？》
3. 《金蝶随手记团队分享：还在用JSON? Protobuf让数据传输更省更快(原理篇)》

另外：《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》一文中，“3、协议设计”这一节有关于protobuf在IM中的实战设计和使用，可以一并学习一下。

9、聊天协议定义

我们在使用各种聊天APP时，会发各种各样的消息，每种消息都会对应不同的消息格式（即“聊天协议”）。

聊天协议中主要包含几种重要的信息：

• 1）消息类型；
• 2）发送时间；
• 3）消息的收发人；
• 4）聊天类型（群聊或私聊）。

我的这套IM系统中，聊天协议定义如下：

syntax = "proto3";

option java_package = "model.chat";

option java_outer_classname = "RpcMsg";

message Msg{

    string msg_id = 1;

    int64 from_uid = 2;

    int64 to_uid = 3;

    int32 format = 4;

    int32 msg_type = 5;

    int32 chat_type = 6;

    int64 timestamp = 7;

    string body = 8;

    repeated int64 to_uid_list = 9;

}

如上面的protobuf代码，字段的具体含义如下：

• 1）msg_id：表示消息的唯一id，可以用UUID表示；
• 2）from_uid：消息发送者的uid；
• 3）to_uid：消息接收者的uid；
• 4）format：消息格式，我们使用各种聊天软件时，会发送文字消息，语音消息，图片消息等等等等，每种消息有不同的消息格式，我们用format来表示（由于本系统是java终端，format字段没有太大含义，可有可无）；
• 5）msg_type：消息类型，比如登录消息、聊天消息、ack消息、ping、pong消息；
• 6）chat_type：聊天类型，如群聊、私聊；
• 7）timestamp：发送消息的时间戳；
• 8）body：消息的具体内容，载体；
• 9）to_uid_list：这个字段用户群聊消息提高群聊消息的性能，具体作用会在群聊原理部分详细解释。

10、私聊消息发送原理

Client1给Client2发消息时，我们需要构建上节中的消息体。

具体就是：from_uid是Client1的uid、to_uid是Client2的uid。

NettyServer收到消息后的处理逻辑是：

• 1）解析到to_uid字段；
• 2）从SessionMap或者Redis中保存的Session集合中获取to_uid即Client2的Session；
• 3）从Session中取出Client2的Channel；
• 4）然后将消息通过Client2的Channel发给Client2。

11、群聊消息发送原理

群聊消息的分发通常有两种技术实现方式，我们一一来看看。

方式一：假设一个群有100人，如果Client1给一个群的所有人发消息，其实相当于Client1分别给其余99人分别发一条消息。我们可以直接在Client端，通过循环，分别给群里的99人发消息即可，相当于Client发送给NettyServer发送了99次相同的消息（除了to_uid不同）。

上述方案有很严重的性能问题：Client1通过循环99次，分别把消息发给NettyServer，NettyServer收到这99条消息后，分别将消息发给群内其余的用户。先抛开移动端的特殊性（比如循环还没完成手机就有可能退到后台被系统挂起），显然Client1到NettyServer的99次循环存在明显不合理地方。

方式二：上节的消息体中to_uid_list字段就是为了解决这个方式一的性能问题的。Client1把群内其余99个Client的uid保存在to_uid_list中，然后NettyServer只发一条消息，NettyServer收到这一条消息后，通过to_uid_list字段解析群内其余99的Client的uid，再通过循环把消息分别发送给群内其余的Client。

可以看到：方式二的群聊时，Client1与NettyServer只进行1次消息传输，相比于方式一，效率提高了50%。

11、技术关键点1：客户端分别连接在不同IM实例时如何通信？

针对本文中的架构，如果多个Client分别连接在不同的Server上，Client之间应该如何通信呢？

为了回答这个问题，我们首先要明白Session的作用。

我们做过JavaWeb开发的朋友都知道，Session用来保存用户的登录信息。

在IM系统中也是如此：Session中保存用户的Channel信息。当Client与Server建立链接成功后，会产生一个Channel，Client和Server是通过Channel，实现数据传输。当两端链接建立起来后，Server会构建出一个Session对象，保存uid和Channel等信息，并把这个Session保存在一个SessionMap里（NettyServer的内存里），uid为key，我们可以通过uid就可以找到这个uid对应的Session。

但只有SessionMap还不够：我们需要利用Redis，它的作用是保存整个NettyServer集群全部链接成功的用户，这也是一种Session，但这种Session没有保存uid和Channel的对应关系，而是保存Client链接到NettyServer的信息，如Client链接到的这个NettyServer的ip、port等。通过uid，我们同样可以从Redis中拿到当前Client链接到的NettyServer的信息。正是有了这个信息，我们才能做到，NettyServer集群任意节点水平扩容。

当用户量少的时候：我们只需要一台NettyServer节点便可以扛住流量，所有的Client链接到同一个NettyServer上，并在NettyServer的SessionMap中保存每个Client的会话。Client1与Client2通信时，Client1把消息发给NettyServer，NettyServer从SessionMap中取出Client2的Session和Channel，将消息发给Client2。

随着用户量不断增多：一台NettyServer不够，我们增加了几台NettyServer，这时Client1链接到NettyServer1上并在SessionMap和Redis中保存了会话和Client1的链接信息，Client2链接到NettyServer2上并在SessionMap和Redis中保存了会话和Client2的链接信息。Client1给Client2发消息时，通过NettyServer1的SessionMap找不到Client2的会话，消息无法发送，于是便从Redis中获取Client2链接在哪台NettyServer上。获取到Client2所链接的NettyServer信息后，我们可以把消息转发给NettyServer2，NettyServer2收到消息后，从NettyServer2的SessionMap中获取Client2的Session和Channel，然后将消息发送给Client2。

那么：NettyServer1的消息如何转发给NettyServer2呢？答案是通过消息队列，如Redis中的list数据结构。每台NettyServer启动后都需要监听一个自己的Redis中的消息队列，这个队列用户接收其他NettyServer转发给当前NettyServer的消息。

* Jack Jiang点评：上述集群方案中，Redis既作为在线用户列表存储中心，又作为集群中不同IM长连接实例的消息中转服务（此时的Redis作用相当于MQ），那Redis不就成为了整个分布式集群的单点瓶颈了吗？

12、技术关键点2：链接断开，如何处理？

如果Client与NettyServer，由于某种原因（客户端退出、服务端重启、网络因素等）断开链接，我们必须要从SessionMap删除会话和Redis中保留的数据。

如果不清除这两类数据的话，很有可能Client1发送给Client2的消息，可能会发给其他用户，或者就算Client2处于登录状态，Client2也收到不到消息。

我们可以在Netty框架中的channelInactive方法里，处理链接断开后的会话清除操作。

13、技术关键点3：ping、pong的作用

当Client与NettyServer建立链接后，由于双端网络较差，Client与NettyServer断开链接后，如果NettyServer没有感知到，也就没有清除SessionMap和Redis中的数据，这将会造成严重的问题（对于服务端来说，这个Client的会话实际处于“假死”状态，消息是无法实时发送过去的）。

此时就需要一种ping/pong机制（也就是心跳机制啦）。

实现原理就是：通过定时任务，Client每隔一段时间给NettyServer发一个ping消息，NettyServer收到ping消息后给客户端回复一个pong消息，确保客户端和服务端能一直保持链接状态。如果Client与NettyServer断连了，NettyServer可以立即发现并清空会话数据。Netty中的我们可以在Pipeline中添加IdleStateHandler，可达到这样的目的。

如果你不明白心跳的作用，务必读以下文章：

1. 《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
2. 《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》

也可以学习一下主流IM的心跳逻辑：

1. 《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
2. 《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
3. 《移动端IM实践：实现Android版微信的智能心跳机制》
4. 《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》

如果觉得理论不够直观，下面的代码实例可以直观地进行学习：

1. 《正确理解IM长连接的心跳及重连机制，并动手实现（有完整IM源码）》
2. 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
3. 《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
4. 《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》

其实，心跳算法的实际效果，还是有一些逻辑技巧的，以下两篇建议必读：

1. 《Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？》
2. 《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》

14、技术关键点4：为Server和Client添加Hook

如果NettyServer重启了或者进程被kill掉，我们需要清除当前节点的SessionMap（其实不用清理SessionMap，数据在内存里重启会自动删除的）和Redis保存的Client的链接信息。

我们需要遍历SessionMap找出所有的uid，然后一一清除Redis的数据，然后优雅退出。此时，我们就需要为我们的NettyServer添加一个Hook，来做数据清理。

15、技术关键点5：对方不在线该如何处理消息？

Client1给对方发消息，我们通过SessionMap或Redis拿不到对方的会话数据，这就表明对方不在线。

此时：我们需要把消息存储在离线消息表中，当对方下次登录时，NettyServer查离线消息表，把消息发给登录用户（最好是批量发送，提高性能）。

IM中的离线消息处理，也不是个简单的技术点，有兴趣可以深入学习一下：

1. 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
2. 《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
3. 《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
4. 《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
5. 《喜马拉雅亿级用户量的离线消息推送系统架构设计实践》

16、写在最后

代码写成这样，也算是了确了自已手撸IM的心愿。唯一遗憾的是，时间比较紧张，还没来得及实现消息ack机制，保证消息一定会送达，这个笔者以后会补充上去的。

好了，这就是我开发的这个简易的聊天系统，麻雀虽小，五脏俱全，大家有什么不明白的地方，可以直接在下方留言，笔者会一一回复的，谢谢大家。

17、系列文章

• 《跟着源码学IM(一)：手把手教你用Netty实现心跳机制、断线重连机制》
• 《跟着源码学IM(二)：自已开发IM很难？手把手教你撸一个Andriod版IM》
• 《跟着源码学IM(三)：基于Netty，从零开发一个IM服务端》
• 《跟着源码学IM(四)：拿起键盘就是干，教你徒手开发一套分布式IM系统》
• 《跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现》
• 《跟着源码学IM(六)：手把手教你用Go快速搭建高性能、可扩展的IM系统》
• 《跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天》
• 《跟着源码学IM(八)：万字长文，手把手教你用Netty打造IM聊天》
• 《跟着源码学IM(九)：基于Netty实现一套分布式IM系统》
• 《跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）》（* 本文）

18、参考资料

[1] 新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析

[2] 写给初学者：Java高性能NIO框架Netty的学习方法和进阶策略

[3] 史上最强Java NIO入门：担心从入门到放弃的，请读这篇！

[4] Java的BIO和NIO很难懂？用代码实践给你看，再不懂我转行！

[5] 史上最通俗Netty框架入门长文：基本介绍、环境搭建、动手实战

[6] 理论联系实际：一套典型的IM通信协议设计详解

[7] 浅谈IM系统的架构设计

[8] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端

[9] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[10] 一套原创分布式即时通讯(IM)系统理论架构方案

[11]  一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[12] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[13] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[14] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[15] 基于实践：一套百万消息量小规模IM系统技术要点总结

（本文已同步发布于：http://www.52im.net/thread-3816-1-1.html ）

关于RainbowChat-Web

► RainbowChat-Web详细介绍：http://www.52im.net/thread-2483-1-1.html
► 历史版本更新记录：http://www.52im.net/thread-2480-1-1.html

RainbowChat-Web是一套基于MobileIMSDK-Web的网页端IM系统。

▲ 主界面（更多截图点此进入、更多演示视频点此进入）

▲ 主界面(聊天窗全屏时)（更多截图点此进入、更多演示视频点此进入）

v4.0 版更新内容

此版更新内容：

• 1）[前端] [新增] 增加了消息“撤回”功能，体验与微信保持一致（支持3种聊天模式，包含完整的前后端处理逻辑）；
• 2）[前端] [新增] 增加了删除聊天消息功能；
• 3）[前端] [新增] 增加了设置好友备注（及附属字段）的功能；
• 4）[前端/服务端] [优化] 升级MobileIMSDK-Web库至v5.0版（支持完整消息送达保证机制）；
• 5）[前端] [优化] 将原UI各模块代码按js文件分拆，使得代码更易理解和阅读；
• 6）[前端] [优化] 增强了表情功能，且可与APP产品互通；

增强版的表情功能效果截图：

消息“撤回”功能效果截图：

消息气泡右键功能效果截图：

设置好友备注功能效果截图：

本文由融云技术团队原创分享，原题“聊天室海量消息分发之消息丢弃策略”，内容有修订。

1、引言

随着直播类应用的普及，尤其直播带货概念的风靡，大用户量的直播间场景已然常态化。

大用户量直播间中的实时互动是非常频繁的，具体体现在技术上就是各种用户聊天、弹幕、礼物、点赞、禁言、系统通知等实时消息（就像下图这样）。

▲ 某电商APP的卖货直播间

如此大量的实时消息，在分发时如何处理才能不至于把服务端搞垮，而到了客户端时也不至于让APP出现疯狂刷屏和卡顿（不至于影响用户体验），这显然需要特殊的技术手段和实现策略才能应对。

其实，直播间中的实时消息分发，在技术上是跟传统的在线聊天室这种概念是一样的，只是传统互联网时代，聊天室同时在线的用户量不会这么大而已，虽然量级不同，但技术模型是完全可以套用的。

本文将基于直播技术实践的背景，分享了单直播间百万用户在线量的实时消息分发的技术经验总结，希望带给你启发。

学习交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

（本文已同步发布于：http://www.52im.net/thread-3799-1-1.html）

2、系列文章

本文是系列文章中的第6篇：

• 《直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路》
• 《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》
• 《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》
• 《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》
• 《直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践》
• 《直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践》（* 本文）

3、技术挑战

我们以一个百万人观看的直播间为例进行分析，看看需要面临哪些技术挑战。

1）在直播中会有一波一波的消息高峰，比如直播中的“刷屏”消息，即大量用户在同一时段发送的海量实时消息，一般情况下此类“刷屏”消息的消息内容基本相同。如果将所有消息全部展示在客户端，则客户端很可能出现卡顿、消息延迟等问题，严重影响用户体验。

2）海量消息的情况下，如果服务端每条消息都长期存储将导致服务缓存使用量激增，使得内存、存储成为性能瓶颈。

3）在另外一些场景下，比如直播间的房间管理员进行操作后的通知消息或者系统通知，一般情况下这类消息是较为重要的，如何优先保障它的到达率。

基于这些挑战，我们的服务需要做一个基于业务场景的优化来应对。

4、架构模型

我们的架构模型图如下：

 

如上图所示，下面将针对主要服务进行简要说明。

1）直播间服务：

主要作用是：缓存直播间的基本信息。包括用户列表、禁言/封禁关系、白名单用户等。

2）消息服务：

主要作用是：缓存本节点需要处理的用户关系信息、消息队列信息等。

具体说是以下两个主要事情。

直播间用户关系同步：

• a）成员主动加入退出时：直播间服务同步至==> 消息服务；
• b）分发消息发现用户已离线时：消息服务同步至==> 直播间服务。

发送消息：   

• a）直播间服务经过必要校验通过后将消息广播至消息服务；
• b）直播间服务不缓存消息内容。

3）Zk（就是 Zookeeper 啦）：

主要作用就是：将各服务实例均注册到 Zk，数据用于服务间流转时的落点计算。

具体就是：

• a）直播间服务：按照直播间 ID 落点；
• b）消息服务：按照用户 ID 落点。

4）Redis：

主要作为二级缓存，以及服务更新（重启）时内存数据的备份。

5、消息分发总体方案

直播间服务的消息分发完整逻辑主要包括：消息分发流程和消息拉取流程。

5.1 消息分发流程

如上图所示，我们的消息分发流程主要是以下几步：

• 1）用户 A 在直播间中发送一条消息，首先由直播间服务处理；
• 2）直播间服务将消息同步到各消息服务节点；
• 3）消息服务向本节点缓存的所有成员下发通知拉取；
• 4）如上图中的“消息服务-1”，将向用户 B 下发通知。

另外，因为消息量过大，我们在在分发的过程中，是具有通知合并机制的，通知合并机制主要提现在上述步骤 3 中。

上述步骤3的通知合并机制原理如下：

• a）将所有成员加入到待通知队列中（如已存在则更新通知消息时间）；
• b）下发线程，轮训获取待通知队列；
• c）向队列中用户下发通知拉取。

通过通知合并机制，我们可以可保障下发线程一轮只会向同一用户发送一个通知拉取，即多个消息会合并为一个通知拉取，从面有效提升了服务端性能且降低了客户端与服务端的网络消耗。

PS：以上通知合并机制，在大消息量的情况下，非常适合使用Actor分布式算法来实现，有兴趣的同学可以进一步学习《分布式高并发下Actor模型如此优秀》、《分布式计算技术之Actor计算模式》。

5.2 消息拉取流程

 

如上图所示，我们的消息拉取流程主要是以下几步：

• 1）用户 B 收到通知后将向服务端发送拉取消息请求；
• 2）该请求将由“消息服务-1”节点处理；
• 3）“消息服务-1”将根据客户端传递的最后一条消息时间戳，从消息队列中返回消息列表（原理详见下图 ▼）；
• 4）用户 B 获取到新的消息。

上述步骤 3 中拉取消息的具体逻辑如下图所示：

6、消息分发的丢弃策略

对于直播间中的用户来说，很多消息其实并没有太多实际意义，比如大量重复的刷屏消息和动态通知等等，为了提升用户体验，这类消息是可以有策略地进行丢弃的（这是跟IM中的实时聊天消息最大的不同，IM中是不允许丢消息的）。

PS：直播间中消息分发的丢弃策略，跟上节中的通知合并机制一起，使得直接间海量消息的稳定、流畅分发得以成为可能。

我们的丢弃策略主要由以下3部分组成：

• 1）上行限速控制（丢弃）策略；
• 2）下行限速控制（丢弃）策略；
• 3）重要消息防丢弃策略。

如下图所示：

我们来逐个解释一下。

1）上行限速控制（丢弃）策略：

针对上行的限速控制，我们默认是 200 条/秒，根据业务需要可调整。达到限速后发送的消息将在直播间服务丢弃，不再向各消息服务节点同步。

2）下行限速控制（丢弃）策略：

针对下行的限速控制，即对消息环形队列（见“5.2 消息拉取流程”中的拉取消息详细逻辑图）长度的控制，达到最大值后最“老”的消息将被淘汰丢弃。

每次下发通知拉取后服务端将该用户标记为“拉取中”，用户实际拉取消息后移除该标记。

拉取中标记的作用：例如产生新消息时用户具有拉取中标记，如果距设置标记时间在 2 秒内则不会下发通知（降低客户端压力，丢弃通知未丢弃消息），超过 2 秒则继续下发通知（连续多次通知未拉取则触发用户踢出策略，不在此赘述）。

因此消息是否被丢弃取决于客户端拉取速度（受客户端性能、网络影响），客户端及时拉取消息则没有被丢弃的消息。

3）重要消息防丢弃策略：

如前文所述：在直播间场景下对某些消息应具有较高优先级，不应丢弃。

例如：直播间的房间管理员进行操作后的通知消息或者系统通知。

针对此场景：我们设置了消息白名单、消息优先级的概念，保障不丢弃。如本节开始的图所示，消息环形队列可以为多个，与普通直播间消息分开则保障了重要消息不丢弃。

通过上述“1）上行限速控制（丢弃）策略”和“下行限速控制（丢弃）策略”保障了：

• 1）客户端不会因为海量消息出现卡顿、延迟等问题；
• 2）避免出现消息刷屏，肉眼无法查看的情况；
• 3）同时降低了服务端存储压力，不会因为海量消息出现内存瓶颈从而影响服务。

7、写在最后

随着移动互联网的发展，直播间的实时消息业务模型和压力也在不停地扩展变化，后续可能还会遇到更多的挑战，我们的服务会与时俱进、跟进更优的方案策略进行应对。

附录：多人群聊天技术文章

[1]《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》

[2]《IM群聊消息如此复杂，如何保证不丢不重？》

[3]《移动端IM中大规模群消息的推送如何保证效率、实时性？》

[4]《现代IM系统中聊天消息的同步和存储方案探讨》

[5]《关于IM即时通讯群聊消息的乱序问题讨论》

[6]《IM群聊消息的已读回执功能该怎么实现？》

[7]《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》

[8]《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》

[9]《IM群聊机制，除了循环去发消息还有什么方式？如何优化？》

[10]《网易云信技术分享：IM中的万人群聊技术方案实践总结》

[11]《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》

[12]《IM群聊消息的已读未读功能在存储空间方面的实现思路探讨》

[13]《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》

[14]《融云IM技术分享：万人群聊消息投递方案的思考和实践》

（本文已同步发布于：http://www.52im.net/thread-3799-1-1.html）