IM大量离线消息客户端卡顿问题处理

发表于 | 更新于 | 分类于 | 阅读次数：
本文字数： 3.1k | 阅读时长 ≈ 3 分钟

IM大量离线消息客户端卡顿问题处理

IM产品的主要业务及特点

和传统互联网行业有所不同，笔者所在的公司（名字就不透露了）是一家做娱乐社交app的公司，包括小游戏、聊天、朋友圈feed等。

**大家应该都有体会：**游戏业务在技术上和产品形态上与电商、旅游等行业有着本质上的区别。

大部分做后端开发的朋友，都在开发接口。客户端或浏览器h5通过HTTP请求到我们后端的Controller接口，后端查数据库等返回JSON给客户端。大家都知道，HTTP协议有短连接、无状态、三次握手四次挥手等特点。而像游戏、实时通信等业务反而很不适合用HTTP协议。

原因如下：

  • 1）HTTP达不到实时通信的效果，可以用客户端轮询但是太浪费资源；
  • 2）三次握手四次挥手有严重的性能问题；
  • 3）无状态。

比如说，两个用户通过App聊天，一方发出去的消息，对方要实时感知到消息的到来。两个人或多个人玩游戏，玩家要实时看到对方的状态，这些场景用HTTP根本不可能实现！因为HTTP只能pull（即“拉”），而聊天、游戏业务需要push（即“推”）。

1、IM系统业务现状和痛点

1.1业务现状

笔者负责整个公司的实时聊天系统，类似与微信、QQ那样，有私聊、群聊、发消息、语音图片、红包等功能。

下面我详细介绍一下，整个聊天系统是如何运转的。

**首先：**为了达到实时通信的效果，我们基于Netty开发了一套长链接网关gateway（扩展阅读：《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》），采用的协议是MQTT协议，客户端登录时App通过MQTT协议连接到gateway（NettyServer），然后通过MQTT协议把聊天消息push给NettyServer，NettyServer与NettyClient保持长链接，NettyClient用于处理业务逻辑(如敏感词拦截、数据校验等)处理，最后将消息push给NettyServer，再由NettyServer通过MQTT push给客户端。

**其次：**客户端与服务端想要正常通信，我们需要制定一套统一的协议。拿聊天举例，我们要和对方聊天，需要通过uid等信息定位到对方的Channel（Netty中的通道，相当于一条socket连接），才能将消息发送给正确的客户端，同时客户端必须通过协议中的数据（uid、groupId等），将消息显示在私聊或者群聊的会话中。

协议中主要字段如下（我们将数据编码成protobuf格式进行传输）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
    "cmd":"chat",
    "time":1554964794220,
    "uid":"69212694",
    "clientInfo":{
        "deviceId":"b3b1519c-89ec",
        "deviceInfo":"MI 6X"
    },
    "body":{
        "v":1,
        "msgId":"5ab2fe83-59ec-44f0-8adc-abf26c1e1029",
        "chatType":1,
        "ackFlg":1,
        "from":"69212694",
        "to":"872472068",
        "time":1554964793813,
        "msg":{
            "message":"聊天消息"
        }
    }
}

**补充说明：**如果你不了Protobuf格式是什么，请详读《Protobuf通信协议详解：代码演示、详细原理介绍等》。

如上json，协议主要字段包括：

如果客户端不在线，我们服务端需要把发送的消息存储在离线消息表中，等下次对方客户端上线，服务端NettyServer通过长链接把离线消息push给客户端。

1.2业务痛点

随着业务蓬勃发展，用户的不断增多，用户创建的群、加入的群和好友不断增多和聊天活跃度的上升，某些用户不在线期间，产生大量的离线消息（尤其是针对群聊，离线消息特别多）。

等下次客户端上线时，服务端会给客户端强推全部的离线消息，导致客户端卡死在登录后的首页。并且产品提出的需求，要扩大群成员的人数（由之前的百人群扩展到千人群、万人群等）。

这样一来，某些客户端登录后必定会因为大量离线消息而卡死，用户体验极为不好。

和客户端的同事一起分析了一下原因：

  • 1）用户登录，服务端通过循环分批下发所有离线消息，数据量较大；
  • 2）客户端登录后进入首页，需要加载的数据不光有离线消息，还有其他初始化数据；
  • 3）不同价位的客户端处理数据能力有限，处理聊天消息时，需要把消息存储到本地数据库，并且刷新UI界面，回复给服务端ack消息，整个过程很耗性能。

（庆幸的是，在线消息目前没有性能问题）。

所以针对上述问题，结合产品对IM系统的远大规划，我们服务端决定优化离线消息（稍微吐槽一下，客户端处理能力不够，为什么要服务端做优化？服务端的性能远没达到瓶颈。。。）。

2、升级改造之路

经过一番思考，服务端和客户端最终达成了一致的方案：

  • 1）在未读消息计数器的小红点逻辑中，服务端会把每个会话的最近N条消息一起下发给客户端；
  • 2）客户端进入会话时，会根据未读消息计数器的最近N条消息展示首页数据；
  • 3）客户端每次下拉加载时，请求服务端，服务端按时间倒排离线消息返回当前会话最近一页离线消息，直到离线消息库中的数据全部返回给客户端；
  • 4）当离线消息库中没有离线消息后，返回给客户端一个标识，客户端根据这个标识，在会话页面下一次下拉加载时不请求服务端的离线消息，直接请求本地数据库。

3、消息ACK逻辑的优化

最后，我们也对消息ack的逻辑进行了优化。

**优化前：**服务端采用push模型给客户端推消息，不论是在线消息还是离线消息，ack的逻辑都一样，其中还用到了kafka、redis等中间件，流程很复杂（我在这里就不详细展开介绍ack的具体流程了，反正不合理）。

离线消息和在线消息不同的是，我们不存储在线消息，而离线消息会有一个单独的库存储。完全没必要用在线消息的ack逻辑去处理离线消息，反而很不合理，不仅流程上有问题，也浪费kafka、redis等中间件性能。

**优化后：**我们和客户端决定在每次下拉加载离线消息时，将收到的上一批离线消息的msgId或消息偏移量等信息发送给服务端，服务端直接根据msgId删除离线库中已经发送给客户端的离线消息，再返回给客户端下一批离线消息。

最终消息衔接问题解决方案

地址

http://www.52im.net/thread-3036-1-1.html

-------------本文结束-------------
0%