在现在的挪动互联网时代，IM 类产品已是咱们生存中不可或缺的组成部分。像微信、钉钉、QQ 等是典型的以 IM 为外围性能的社交产品。另外也有一些利用尽管 IM 性能不是外围，但 IM 能力也是其整个利用极其重要的组成部分，比方在线游戏、电商直播等利用。
在 IM 技术利用场景越来越宽泛的前提下，对即时通讯 IM 技术的学习和把握就显的越来越有必要。
在 IM 宏大的技术体系中，音讯零碎无疑是最外围的，而音讯零碎中，最要害的局部是音讯的散发和存储，而离线音讯和历史音讯又是这个关键环节中不可回避的技术要点。
IM 音讯投递的个别做法
在通常的 IM 音讯零碎中，对于实时音讯、离线音讯、历史音讯大略都是上面这样的技术思路。
对于在线用户：音讯会间接实时发送到在线的接管方，音讯发送实现后，服务器端并不会对音讯进行落地存储。
而对于离线的用户：服务器端会将音讯存入到离线库，当用户登录后，从离线库中将离线音讯拉走，而后服务器端将离线音讯删除。
这样实现的毛病就是音讯不长久化，导致音讯无奈反对音讯漫游，升高了音讯的可靠性。
什么是离线音讯和历史音讯？
对于离线音讯和历史音讯，在技术上，咱们是这样定义。
1）离线音讯：
离线音讯就是用户（即接管方）在离线过程中收到的音讯，这些音讯大多是用户比较关心的音讯，具备肯定的时效性。
以咱们的零碎教训来说，咱们的离线音讯默认只保留最近七天的音讯。
用户（即接管方）在下次登录后会全量获取这些离线音讯，而后在客户端依据聊天会话进行离线音讯的 UI 展现（比方显示一个未读音讯气泡等）。
2）历史音讯：
历史音讯存储了用户所有的聊天音讯，这些音讯包含收回的音讯以及接管到的音讯。
在客户端获取历史音讯时，通常是依照会话进行分页获取的。
以咱们的零碎教训来说，历史音讯的存储工夫咱们设计默认为半年，当然这个工夫能够按理论的产品经营规定来定，没有硬性规定。即时通讯聊天软件开发能够征询蔚可云。
当用户发送聊天音讯到服务器端后，首先会进入到音讯零碎中，音讯零碎会对音讯进行散发以及存储。
这个过程中：对于在线的接管方，会抉择间接推送音讯。然而遇到接管方不在线或者是音讯推送失败的状况下，也会有另外的音讯获取形式，比方接管方会被动向服务器拉取未收到的音讯。然而接管方何时来服务器拉取音讯以及从哪里拉取是未知的，所以音讯存入到离线库的意义也就在这里。
音讯零碎存储离线的过程中，为了不影响整个零碎的更为安稳，咱们应用了 MQ 音讯队列进行 IO 解偶，所以聊天音讯实际上是异步存入到离线库中的（通过 MQ 进行慢 IO 解偶，这其实也是惯常做法）。
在散发完音讯后：音讯服务会同步一份音讯数据到历史音讯服务中，历史音讯服务同样会对音讯进行落地存储。
对于新的客户端设施：会有同步音讯的需要（所谓的音讯漫游能力），而这也正是历史音讯的次要作用。在历史音讯库中，客户端是能够拉取任意会话的全量历史音讯的。
1）离线音讯咱们存储介质选用的是 Redis；
2）历史音讯咱们选用的是 HBase。对于为什么选用不同的存储介质，其实咱们思考的是离线音讯和历史音讯不同的业务场景和读写模式。
上面咱们重点介绍一下离线音讯和历史音讯存储的区别。
每个用户都有本人独自的收件箱和发件箱：
1）收件箱寄存的是须要向这个接收端同步的所有音讯；2）发件箱里寄存的是发送端收回的所有音讯。以单聊为例：聊天中的两人会话中，音讯会产生两次写，即发送者的发件箱和接收端的收件箱。
而在群的场景下：写入会被更加的放大（扩散），如果群里有 N 集体，那一条群音讯就会被扩散写 N 次。
小结一下：
1）扩散写的长处是：接收端的逻辑会十分清晰简略，只须要从收件箱里读取一次即可，大大降低了同步音讯所需的读的压力；2）扩散写的毛病是：写入会被成指数地放大，特地是针对群这种场景。历史音讯存储模式——“扩散读”
历史音讯的存储模式咱们用的是扩散读。
因为历史音讯中，每个会话都保留了整个会话的全量音讯。在扩散读这种模式下，每个会话的音讯只保留一次。
比照扩散写模式，扩散读的长处和毛病如下：
1）长处是：写入次数大大降低，特地是针对群音讯，只须要存一次即可；2）毛病是：接收端接管音讯十分的简单和低效，因为这种模式客户端想拉取到所有音讯就只能每个会话同步一次，读就会被放大，而且可能会产生很屡次有效的读，因为有些会话可能基本没有新音讯。在 IM 这种利用场景下，通常会用到扩散写这种音讯同步模型，一条音讯产生一条，然而可能会被读屡次，是典型的读多写少的场景。
一个优化好的 IM 零碎，必须从设计上均衡读写压力，防止读或者写任意一个维度达到天花板。
当然扩散写这种模式也有其弊病，比方万人群，会导致一条音讯，写入了一万次。
综合来讲：咱们须要依据本人的业务场景做相应设计抉择，以咱们的 IM 零碎为例，就是是依据了离线和历史音讯的不同场景抉择了写扩散和读扩散的组合模式。适宜的才是最好的，没有必要死搬硬套实践。
离线音讯拉取逻辑
对于 IM 客户端而言，离线音讯的获取针对的是本人的整个离线音讯，包含所有的会话（直白了说，就是上线时拉取此次离线过程中的所有未收取的离线音讯）。
离线音讯的获取是自上而下的形式（按工夫序），咱们的教训是一次获取 200 条（PS：如果离线音讯过多，会分页屡次拉取，拉取 1“次”能够了解为拉取 1“页”）。
在客户端拉取离线音讯的信令中，须要带上以后客户端缓存的音讯的最大工夫戳。
通过上节的图咱们应该晓得，离线音讯咱们存储的是一个线性构造（指的是按工夫程序），Server 会依据这个工夫戳向下查找离线音讯。当重装或者新装置 App 时，客户端的“以后客户端缓存的音讯的最大工夫戳”能够传 0 上来。
Server 也会缓存客户端拉取到的最初一条音讯的工夫戳，而后依据业务场景，客户端类型等因素来决定从哪里开始拉取，如果没有拉取完 Server 会在拉取音讯的应答中带相应的标记位，通知客户端持续拉取，客户端循环拉取，直到所有离线音讯拉完。
历史音讯的获取通常针对的是繁多会话。
在拉取过程中，须要向服务端提交两个参数：
1）对方的 ID（如果是单聊的话就是对方的 UserID，如果是群则是群组 ID）；2）以后会话的最后面音讯的工夫戳（即以后会话最老一条音讯的工夫戳）。Server 据这两个参数，能够定位到这个客户端的此会话，而后一次获取 20 条历史音讯。
音讯的拉取时序上采纳的是自下而上的形式（也就是工夫序逆序），即从最初面往前翻。只有有音讯，客户端能够始终向前翻，手动触发获取会话的历史音讯。