本文由转转 梁会彬、杜云杰分享，原题“转转 IM 的实践与思考”，下文进行了排版和内容优化。

1、引言

接上篇《整体架构设计》，笔者将以转转 IM 架构为起点，介绍 IM 相关组件以及组件间的关系；以 IM 登陆和发消息的数据流转为跑道，介绍 IM 静态数据结构、登陆和发消息时的动态数据变化；以 IM 常见问题为风景，介绍保证 IM 实时性、可靠性、一致性的一般方案；以高可用、高并发为终点，介绍保证 IM 系统稳定及性能的小技巧。

2、系列文章

本文是系列文章中的第 2 篇，本系列文章的大纲如下：

• 转转平台 IM 系统架构设计与实践(一)：整体架构设计

  转转平台 IM 系统架构设计与实践(二)：详细设计与实现（* 本文)

3、本文作者

梁会彬：转转架构部资深 Java 工程师，主要负责服务治理平台、Docker 云平台、IM、分布式 ID 生成器、短域名服务等，有丰富的线上实战经验。

4、 IM 架构回顾

应用层：使用 IM 服务的上游业务方，包括 app（ios 和 android）、小程序/PC/m 页、push、业务方等。

接入层：

• 1）tcp entry：使用 TCP 协议，主要用于长连接保持、会话管理、协议解析；

• 2）http entry：使用 http 协议，采用 long pull 技术，主要用于长连接保持、会话管理、协议解析；

• 3）mq：接收电商推广等系统消息。推送量具有脉冲特点，使用 mq 削峰填谷；

• 4）rpc-server：业务查询用户聊天数据、发送实时系统消息等。

逻辑层：

• 1）logic：核心逻辑服务，负责登陆信息管理、在线消息管理、离线消息管理、在线推送管理等；

• 2）ext-logic：扩展逻辑服务，负责子母账号推送、登陆信息统计、系统消息管理等。

数据层：

• 1）MySQL：联系人数据、消息数据、系统消息数据等；

• 2）Redis：登陆信息等。

5、IM 消息收发

5.1 场景说明

数据流中以用户 A 和用户 B 的对话为例，其中用户 A 的 uid 为 1，用户 B 的 uid 为 2。

下图为用户聊天场景图：

下图为用户聊天 IM 系统的数据流转图：

5.2 数据结构

登陆信息存储在 Redis 中，联系人和消息数据放在 TiDB 中。

1）登陆信息：

key：uid

value：{entryIp:"127.0.0.1",entryPort:5000,loginTime:23443233}

2）联系人：

说明：

• 1）recent_msg_content：最近一条对话消息的内容，用于联系人列表中展示最近的消息内容；

• 2）recent_read_time：最近一次读取该会话消息的时间，用于控制已读状态，小于该时间的所有消息，都为已读状态。

3）消息：

说明：

• 1）client_msg_id：客户端生成的 id，客户端幂等设计，防重复；

• 2）direction：消息方向（0 代表较大 uid 向较小 uid 发送消息，1 则反之）。

数据流=数据+流。上面部分讲数据，即联系人和消息表，从静态的角度介绍了 IM 的数据结构；下面部分讲流（IM 中最重要的两个流程），即登陆和发消息，从动态的角度来阐述 IM 系统中数据的流转。

5.3 主要流程

5.3.1 ）登陆：

1）问题：entry 地址发现：app 直接访问 vip，由 vip 转发到 entry。

2）流程（下面的数字为图中数字的说明）：

• 1）建连：app 通过 vip 发起与 entry 连接；

• 2）转发：entry 转发登陆信息到 logic，获取用户 uid 并管理该用户的连接；

• 3）入库：logic 记录用户登陆信息到 redis。

3）数据：

Redis 中数据如下：

key：1

value：{entryIp:"127.0.0.1",entryPort:5000,loginTime:23443233}

5.3.2 ）发消息（下面的数字为图二中数字的说明）：

1）流程处理：

• 1）发送：通过用户与 entry 的长连接发送文字"hello world"；

• 2）转发：entry 转发文字信息"hello world"到 logic；

• 3）入库：logic 存入数据库，即更新联系人表和消息表，其中联系人表更新 recent_msg_content 字段，消息表增加一条新消息记录；

• 4）推送：从 Redis 中获取用户 B 登陆 entry，如果未登录，走离线逻辑（发送 push、推送微信、短信唤起）；

• 5）送达：用户 B 收到消息；

• 6）确认：发送 ack 到 entry；

• 7）完成：logic 收到 ack，取消定时器；如果没有收到 ack，logic 会定时重发（用户在线时）。

2）数据：

联系人数据如下：

消息表数据如下：

5.3.3）关于数据的几个问题：

1）消息和联系人是如何分库分表的？使用 TiDB，无需分库分表（现在的表设计支持根据 uid_a 分表，也就是无缝支持以 MySQL 为存储）。

2）联系人表一条消息为什么记录了两条数据？业务逻辑上，考量支持已读、删除联系人；索引性能上，考虑用户查询联系人时，sql 条件为 where uid_a=？，联系人表索引为 uid_a，如果存单条数据，无法有效利用索引。

3）消息表一条消息记录一条数据，用户 B 与用户 A 的消息怎么查询？该表索引为<big_uid, small_uid>联合索引，无论是用户 A 查询与用户 B 的聊天信息，还是用户 B 查询用户 A 的聊天信息，其 sql 统统为 where big_uid =max(uid_a,uid_b) and small_uid =min(uid_a,uid_b)，然后根据 direction 字段展示聊天方向，这样就可以用一条消息，无需和联系人表一样存储两份数据，满足两种查询，节省一半的消息存储。

6、IM 常见问题

6.1 消息的实时性

1）是什么：

用户 A 给用户 B 发送消息"hello world"，用户 B 怎么第一时间感知到？这里说的实时性，就是指用户如何实时获取发送的消息。

2）io 模型带来的启示：

• 1）poll、select、epoll；

• 2）poll/select 相比 epoll 最大的劣势在于轮询，轮询就需要轮询间隔，间隔小会浪费 cpu，间隔大会不实时。epoll 具有 don't call me i will call you 的特点，保证实时性；

• 3）IM 也面临着轮询还是通知的问题，也就是 pull 和 push 的问题。

3）怎么办：

• 1）向 epoll 致敬：epoll_create、epoll_ctl、epoll_wait（此三者是 epoll 系统调用 api）；

• 2）整个 IM 系统和 epoll 模型类似，app 和 entry 保持长连接（epoll_create）；entry session 管理（即长连接管理 epoll_ctl）；logic 等待用户 A 发送给用户 B 消息，获取用户 B 所登陆 entry，触发推送消息（epoll_wait）；综述，entry 扮演着（epoll_create，epoll_ctl），logic 扮演着（epoll_wait）这样 IM 系统就解决了消息实时性问题。

6.2 消息的可靠性

1）是什么：

• 1）用户 A 给用户 B 发送消息"hello world"，用户 B 在线，怎么保证用户 B 确实收到了消息。这里说的可靠性，就是指用户如何可靠发送的消息。

2）tcp 模型带来的启示：

• 1）失败重传、ack 确认。

3）怎么办：

• 1）失败重传：图二中（1、发送 2、转发 3、入库）失败，告知客户端失败，由客户端重传；

• 2）ack 确认：图二中（4、推送 5、送达 6、确认 7、完成）失败，即 ack 处理失败，启动重新通知逻辑。

6.3 消息的一致性

1）是什么：

• 1）现象：本来用户 A 给用户 B 发送了一个"hello world"，而用户 B 确收到了两个"hello world"；

• 2）原因：由于可靠性逻辑中的重传逻辑，可能造成客户端认为失败了，但是服务端却成功了；推送 ack 返回错误，造成重推。

2）身份证带来的启示。

3）怎么办：

• 1）client_msg_id：客户端发送消息时生成客户端 id，对于单个客户端，该 id 具有唯一性，像身份证一样；

• 2）客户端去重：如果客户端发现相同 client_msg_id 的消息，则仅仅展示一条数据。

7、IM 高可用、高并发

1）扩缩容：

依托公司 rpc 服务注册发现能力，借助 docker 快速扩容，核心处理逻辑 logic 服务实现秒级扩容。扩容依据为各种监控指标，包括机器性能指标、 entry/logic qps 指标、jvm 指标、sql 监控等综合考量。

2）熔断：

当大流量进入时，如果核心服务依赖的服务（比如母子账号服务）出现不可用的情况。这时，我们是直接使 IM 服务不可用吗？是不是有更好的选择？答案是肯定的，我们可以牺牲母子账号功能，也就是熔断不重要的依赖服务，做到柔性可用。

3）限流：

如果遇到瞬时高流量，仅仅扩容有可能适得其反。如果 db 处理能力达到极限，扩容就不是明智的选择，扩容反而会导致 db 连接增多，增加 db 的压力，导致服务崩溃。这时退一步采用限流，应用“fast fail”策略，让部分流量快速失败，减小服务压力，达到部分可用的效果。

4）总结：

IM 作为电商应用中的一个重要节点，其重要性不言而喻，对其怎么重视都不为过。我们使用监控工具定义 IM 的核心 metrics，根据指标进行扩缩容，这样做到了高可用；

高可用是万能的吗？IM 依赖了很多服务，比如用户，母子账号，风控等服务，如果这些服务出现不可用的情况呢？这个时候就要学习一下古人的智慧，壮士断腕，牺牲小我，换取大我了，也就是柔性可用；

仅仅这样还是不够的，如果遇到突发流量，db（不可瞬时扩大处理能力）等处理能力达到极限时这个时候就要牺牲部分请求了，也就要做到部分可用。从“高可用”到“柔性可用”再到“部分可用”，面对不同 case，IM 要做到游刃有余。

其实，这种思想又何止 IM 呢，任何重要的服务都要面对这些问题吧，推而广之，面对自己负责的服务，怎么精细小心都不为过。

8、本文小结

诚然，这篇文章给大家对 IM 系统简单的认识，阐述了 IM 的一般架构、主要业务逻辑、常见问题和解决方案以及服务治理相关应用，IM 还有很多业务逻辑和技术挑战。

在业务上，如未读数、群聊、多端登陆、母子账号等；在技术上，entry 长连接 100k 问题优化、时间轮计时器实现、海量数据拆分与存储选型等。

路漫漫其修远兮，吾将上下而求索。（本文已同步发布于：http://www.52im.net/thread-4773-1-1.html）

9、参考资料

[1] 零基础 IM 开发入门(二)：什么是 IM 系统的实时性？

[2] 零基础 IM 开发入门(三)：什么是 IM 系统的可靠性？

[3] 零基础 IM 开发入门(四)：什么是 IM 系统的消息时序一致性？

[4] IM 消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[5] IM 消息送达保证机制实现(二)：保证离线消息的可靠投递

[6] 如何保证 IM 实时消息的“时序性”与“一致性”？

[7] 阿里 IM 技术分享(四)：闲鱼亿级 IM 消息系统的可靠投递优化实践

[8] 阿里 IM 技术分享(五)：闲鱼亿级 IM 消息系统的及时性优化实践

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

[10] 融云技术分享：全面揭秘亿级 IM 消息的可靠投递机制

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

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

[13] 从零到卓越：京东客服即时通讯系统的技术架构演进历程

[14] 蘑菇街即时通讯/IM 服务器开发之架构选择

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

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

[17] 马蜂窝旅游网的 IM 系统架构演进之路

[18] 一套分布式 IM 即时通讯系统的技术选型和架构设计

[19] 微信团队分享：来看看微信十年前的 IM 消息收发架构，你做到了吗

[20] 携程技术分享：亿级流量的办公 IM 及开放平台技术实践