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

1、引言

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

技术交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

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

2、系列文章

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

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系统就解决了消息实时性问题。