在如今的移动互联网时代，IM类产品已是我们生活中不可或缺的组成部分。像微信、钉钉、QQ等是典型的以 IM 为核心功能的社交产品。另外也有一些应用虽然IM功能不是核心，但IM能力也是其整个应用极其重要的组成部分，比如在线游戏、电商直播等应用。
在IM技术应用场景越来越广泛的前提下，对即时通讯IM技术的学习和掌握就显的越来越有必要。
在IM庞大的技术体系中，消息系统无疑是最核心的，而消息系统中，最关键的部分是消息的分发和存储，而离线消息和历史消息又是这个关键环节中不可回避的技术要点。
IM消息投递的一般做法
在通常的IM消息系统中，对于实时消息、离线消息、历史消息大概都是下面这样的技术思路。
对于在线用户：消息会直接实时发送到在线的接收方，消息发送完成后，服务器端并不会对消息进行落地存储。
而对于离线的用户：服务器端会将消息存入到离线库，当用户登录后，从离线库中将离线消息拉走，然后服务器端将离线消息删除。
这样实现的缺点就是消息不持久化，导致消息无法支持消息漫游，降低了消息的可靠性。
（PS：实际上，这其实也不能算是缺点，因为一些场景下存储历史消息并不是必须的，所谓的消息漫游能力也不是必备的，比如微信。）
而在我们设计的消息系统中，服务器只要接收到了发送方发上来的消息，在转发给接收方的同时也会在离线数据库及历史消息库中进行消息的落地存储，而历史消息的落地也就能支持消息漫游等相关功能了。
什么是离线消息和历史消息？
关于离线消息和历史消息，在技术上，我们是这样定义。
1）离线消息：
离线消息就是用户（即接收方）在离线过程中收到的消息，这些消息大多是用户比较关心的消息，具有一定的时效性。
以我们的系统经验来说，我们的离线消息默认只保存最近七天的消息。
用户（即接收方）在下次登录后会全量获取这些离线消息，然后在客户端根据聊天会话进行离线消息的UI展示（比如显示一个未读消息气泡等）。
（PS：用户离线的可能性在技术上其实是由很多种情况组成的，比如对方不在线、对方网络断掉了、对方手机崩溃了、服务器发送时出错了等等，严格来讲——只要无法实时发送成的消息，都算“离线消息”。）
历史消息：
历史消息存储了用户所有的聊天消息，这些消息包括发出的消息以及接收到的消息。
在客户端获取历史消息时，通常是按照会话进行分页获取的。
以我们的系统经验来说，历史消息的存储时间我们设计默认为半年，当然这个时间可以按实际的产品运营规则来定，没有硬性规定。
当用户发送聊天消息到服务器端后，首先会进入到消息系统中，消息系统会对消息进行分发以及存储。
这个过程中：对于在线的接收方，会选择直接推送消息。但是遇到接收方不在线或者是消息推送失败的情况下，也会有另外的消息获取方式，比如接收方会主动向服务器拉取未收到的消息。但是接收方何时来服务器拉取消息以及从哪里拉取是未知的，所以消息存入到离线库的意义也就在这里。
消息系统存储离线的过程中，为了不影响整个系统的更为平稳，我们使用了MQ消息队列进行IO解偶，所以聊天消息实际上是异步存入到离线库中的（通过MQ进行慢IO解偶，这其实也是惯常做法）。
在分发完消息后：消息服务会同步一份消息数据到历史消息服务中，历史消息服务同样会对消息进行落地存储。
对于新的客户端设备：会有同步消息的需求（所谓的消息漫游能力），而这也正是历史消息的主要作用。在历史消息库中，客户端是可以拉取任意会话的全量历史消息的。
1）离线消息我们存储介质选用的是 Redis；
2）历史消息我们选用的是 HBase。
对于为什么选用不同的存储介质，其实我们考虑的是离线消息和历史消息不同的业务场景和读写模式。
下面我们重点介绍一下离线消息和历史消息存储的区别。
离线消息存储模式——“扩散写”
离线消息的存储模式我们用的是扩散写。
每个用户都有自己单独的收件箱和发件箱：
1）收件箱存放的是需要向这个接收端同步的所有消息；
2）发件箱里存放的是发送端发出的所有消息。
以单聊为例：聊天中的两人会话中，消息会产生两次写，即发送者的发件箱和接收端的收件箱。
而在群的场景下：写入会被更加的放大（扩散），如果群里有 N 个人，那一条群消息就会被扩散写 N 次。
小结一下：
1）扩散写的优点是：接收端的逻辑会非常清晰简单，只需要从收件箱里读取一次即可，大大降低了同步消息所需的读的压力；
2）扩散写的缺点是：写入会被成指数地放大，特别是针对群这种场景。
历史消息存储模式——“扩散读”
历史消息的存储模式我们用的是扩散读。即时通讯聊天软件app开发可以咨询蔚可云。
因为历史消息中，每个会话都保存了整个会话的全量消息。在扩散读这种模式下，每个会话的消息只保存一次。
对比扩散写模式，扩散读的优点和缺点如下：
1）优点是：写入次数大大降低，特别是针对群消息，只需要存一次即可；
2）缺点是：接收端接收消息非常的复杂和低效，因为这种模式客户端想拉取到所有消息就只能每个会话同步一次，读就会被放大，而且可能会产生很多次无效的读，因为有些会话可能根本没有新消息。