本文来自转转技术李帅的原创分享，已进行修订和排版优化。
1、引言
在当今互联网时代，高效的用户服务是提升用户体验的关键。转转自研的客服IM聊天系统作为用户与客服沟通的桥梁，承担着传递信息、解决问题的关键角色。然而，消息数据的流转并非一帆风顺，本文将深入探讨IM系统在消息传递过程中遇到的问题和挑战，以及相应的技术解决方案。
如图是IM系统中一条消息的流转链路：
![]()
相较于普通web系统，IM系统的消息数据流转链路更长、更复杂。从客户端到服务端，再从服务端到另一个客户端，任何一个环节的故障都可能导致消息延迟、丢失、乱序或重复，从而影响用户体验。
网络波动和客户端设备性能的不稳定性是影响IM系统性能的主要因素，这些因素可能导致消息的实时性、可靠性和完整性受到威胁。
2、关于作者
李帅：转转履约中台研发工程师，主要负责客服工单、IM等系统研发。
3、如何保证聊天消息的实时性
首当其冲的就是消息延迟问题：当一条消息发出后，我们的系统需要确保这条消息最快被接收人感知并获取到，并且保证资源消耗较少。
这里关键的点是：
方案1：长短轮询
在PC web早期，大部分应用都是采用“一问一答”的请求响应模式来获取数据，IM系统采用客户端轮询的方式，定期、高频轮询获取服务端的新消息。这种方式开发成本较低、容易实现，但是高频轮询很多请求是无用请求，客户端浪费流量和电量，服务端资源压力很大。
后来基于短轮询进化出长轮询模式，相较于前者，后者在请求时获取到新数据时不会立即返回，而是在服务端保持连接等待一段时间，如果等待期间有新消息就立即返回响应，长轮询仅仅解决了客户端的无用消耗，但是服务端资源高负载情况依然未能解决。
方案2：WebSocket
随着HTML5的出现，全双工的WebSocket成为解决这一问题的关键。基于WebSocket实现的IM服务，客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时的双向数据传输。
关于传统Web和现代Web的实时通信技术，可详读以下几篇：
- Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
- 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
- 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
4、什么是聊天消息的可靠性
如图是一条消息发送的核心步骤，整个过程中可以分为两个部分，消息由客户端发送到服务端（第1、2步），服务端将消息推送至另一个客户端（第3步），发送过程中任何一步出现问题都会导致消息发送失败。
PS：限于篇幅原因，本文不想深入探讨，有兴趣可详读《零基础IM开发入门(三)：什么是IM系统的可靠性？》。
5、如何保证聊天消息触必达？
我们参考使用了TCP/IP协议中的ACK机制来实现防丢逻辑（《TCP/IP详解 - 第17章·TCP：传输控制协议》）。ACK机制是TCP/IP协议三次握手重要的一环（请详读《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》），用于确认对方发送信息无误。
ACK响应机制如下：
- 1）发送者发送消息时会携带一个消息标识符(此处使用发送方id和消息发送时间戳)、并在本地维护一个“等待ACK消息列表”；
- 2）接收者收到消息后对消息进行存储得到消息id；
- 3）随后再将该标识回传给发送方(ACK消息)；
- 4）发送方收到ACK消息后将消息从“等待ACK消息列表”删除；
- 5）当发送方没有在约定时间内收到ACK消息时，就需要执行失败消息处理逻辑：自动重发、客户端标记发送失败等。
服务端实现与客户端稍有不同，服务端需要要维护全量用户的消息，使用定时任务检查等待ACK消息列表效率比较低，此处通过mq的延迟消息来实现：
当消息发出时同时发送一个延迟mq，延迟消息被消费时对应的消息仍在等待ACK列表中，则表示消息未能在规定时间内被确认，需要进行重试发送。
如图为完整的ACK实现机制：
另外客户端也会在页面刷新、WebSocket重连时触发http接口重新拉取当前会话的所有消息进行渲染，保证消息不丢失。
PS：相关资料可进一步阅读：
- IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递
- 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践
- 融云技术分享：全面揭秘亿级IM消息的可靠投递机制
- 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
6、如何对聊天消息去重？
消息重推解决了消息丢失的问题，但是因为ACK消息本身就可能会丢失从而导致消息重复，因此我们需要保证推送消息和重推消息有相同且唯一的消息id，接收方可以根据该消息id进行数据去重。
具体是：
- 1）发送方：客户端使用发送人id和消息发送时间戳作为唯一的ACK标识，传递给服务端；
- 2）服务端：使用雪花算法接收到的消息生成消息id，将ACK标识与消息id建立映射关系；服务端再将消息id推送至发送方和接收方。
一个完整的消息发送流程如图所示：
7、心跳保活机制
IM系统中接收和发送消息都是使用长连接实现，但是如果连接断开，那发送和接收数据就会出现问题。在客服业务中，人工客服席位有限，系统需要可靠的机制保证人工客服资源有效利用。
为此我们在应用层设计心跳消息，使用该机制更新用户当前状态、保证会话有序退出。
心跳机制设计如下。
客户端：设置定时器，用户建立连接后，定时发送(30s)心跳消息给服务端。
服务端：
- 1）接收心跳消息，更新心跳时间；
- 2）设置定时任务，定时扫描在线用户上次心跳时间，执行以下逻辑；
- 3）上次心跳时间超出30s，将其标记为离线状态，关闭连接，等待用户重连；
- 4）上次心跳时间超出2分钟则认为用户已经彻底离开，执行会话关闭逻辑释放人工客服资源。
应用层心跳消息仅用于保活和状态更新，因此数据结构设计十分精简，不携带额外信息。
关于心跳保活这方面的资料，可以进一步阅读：
- 为何基于TCP协议的移动端IM仍然需要心跳保活机制？
- 一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等
- 微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)
- 融云技术分享：融云安卓端IM产品的网络链路保活技术实践
- 跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现
- 阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践
- 万字长文：手把手教你实现一套高效的IM长连接自适应心跳保活机制
8、消息协议的设计
在IM系统中消息格式的设计也十分重要，良好的数据格式可以准确传递消息内容并具有极高的可读性。
我们根据消息类型和发送流向将消息数据格式大致分为如下几部分：
- 1）消息类型：用于描述消息的用途、流向，如心跳消息、用户/客服消息、系统消息等；
- 2）客服id：接收或者发送消息的客服标识；
- 3）用户id：接收或者发送消息的用户标识；
- 4）消息内容：实际的消息，与消息类型相关；
- 5）消息格式：用于描述用户/客服消息格式，如文本、图片、视频、订单卡片、优惠券等；
- 6）消息文本：消息的展示内容。
PS：IM协议设计相关资料可进一步阅读：
- 简述移动端IM开发的那些坑：架构设计、通信协议和客户端
- 理论联系实际：一套典型的IM通信协议设计详解
- APP与后台通信数据格式的演进：从文本协议到二进制协议
- IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！
9、本文小结
转转客服IM系统通过引入WebSocket协议、ACK机制、消息重推和数据去重等策略，有效应保障了消息传递过程中的实时性、可靠性和完整性。这些技术的应用，不仅提升了用户与客服之间的沟通效率，也为转转平台提供了更加稳定、高效的服务支持。
在未来的发展中，我们将继续优化和完善，以应对不断变化的需求和用户期望，为用户提供更加优质的服务体验。
10、参考资料
[0] TCP/IP详解 - 第17章·TCP：传输控制协议》
[1] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[2] 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
[3] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
[4] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？
[5] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端
[6] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递
[7] 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践
[8] 阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践
[9] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制
[10] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
[11] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨
[12] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗
[13] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践
[14] IM群聊消息如此复杂，如何保证不丢不重？
[15] 开发IM是自己设计协议用字节流好还是字符流好？
[17] 零基础IM开发入门(二)：什么是IM系统的实时性？
[18] 零基础IM开发入门(三)：什么是IM系统的可靠性？
[19] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？
[20] 脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手
技术交流：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步发布于：http://www.52im.net/thread-4874-1-1.html）
