Closed AlexiaChen closed 1 year ago
title: 即时通信消息的可靠性保证---离线篇 date: 2017-10-29 21:26:00 tags:
上一篇讲解了IM消息可靠性保证的双方在线情况，以及实现方案。那如果Client-B不在线，IM应用又是如何保证消息的可达性的呢？ 这就是本文所要讨论的问题。
注意，对于步骤4而言，无论是传统的PC客户端IM，比如QQ。还是主流的移动端IM，比如Wechat，消息发送出去以后，无论是对方实时在线收到还是对方不在线被IM-Server离线存储了，对于发送方而言只要消息没有因为网络等原因莫名消失，就应该被认为是对方收到消息了。
从技术角度讲，消息接收方是“收到消息发送消息Ack包”的真正发起者，但是实际有两种可能，一种是接收方发出，而另一种是由IM-Server代为发送（伪应答）。
-- 消息接收者ID,一般是帐号，QQ号，微信号，手机号之类的 receiver_uid varchar(50), -- 消息的唯一指纹码（即消息ID），用于去重等场景，单机情况下此id可能是个自增值、分布式场景下可能是类似于UUID这样的东西 msg_id varchar(70), -- 消息发出时的时间戳（如果是个跨国IM，则此时间戳可能是GMT-0标准时间） send_time time, -- 消息发送者ID，也是帐号，QQ号，微信号，手机号这样等价的ID sender_uid varchar(50), -- 消息类型（标识此条消息是：文本、图片还是语音留言等） msg_type int, -- 消息内容（如果是图片或语音留言等类型，由此字段存放的可能是对应文件的存储地址或CDN的访问URL） msg_content varchar(1024), …
接收方B要拉取发送方A给它发送的离线消息，只需在recceiver_uid(即接收方B的用户ID)，sender_uid（即发送方A的用户ID）上查询，然后收到消息后，接收方B发送Ack:notify包通知IM-Server，这时候IM-Server才把离线消息删除。
SELECT msg_id, send_time, msg_type, msg_content FROM offline_msgs WHERE receiver_uid = [接收方ID] and sender_uid = [发送方ID]
注意，因为接收方B，User-B一旦登录上线，就会首先拉取离线消息，遍历自己的好友列表，获取好友的用户ID，填入发送方ID，发送一条“获取所有好友离线的请求”到IM-Server，这样就知道谁昨天，前天，几天前给我发消息了。必须遍历好友列表，因为User-B不知道谁在它离线的时候给它发过消息。
步骤1，User-B开始拉取User-A发送给它的离线消息 步骤2，IM-Server从DB-Server中拉取离线消息 步骤3，IM-Server从DB-Server中把离线消息删除 步骤4，IM-Server把离线消息返回给User-B
一旦User-B有很多好友，登录时客户端需要对所有好友进行离线消息拉取，客户端与IM-Server互交次数就会比较多
for(const auto& id : friend-id-list){ getOffLineMessage(user-B-id, id); // RPC或者是http协议的封装或者自定义协议 }
优化方案一：
类似于lazy load的方式，当User-B对User-A感兴趣，点击User-A头像图标打开聊天对话框的时候，这时候再发送获取User-A发送给User-B的离线消息。这是按需拉取优化。 但是这个方案一般在实际场景中不用，因为聊天消息如果是按需才拉取，那么User-B可能永远也不会点击User-A的头像，因为你看各种IM App都不是这么做，你一旦登录，就会有消息框弹出来，XX给你发了消息，不然你很可能错过重要的消息，容易误事。一般登录都要主动提示拉取。
所以这里可以变通一下，还是lazy load的思想，User-A登录，拉取给User-A发送离线消息的好友的ID列表，也就是，弹出消息框，报告User-A，XXX,XXX给你发离线消息了，你点开哪一个，我就去请求IM-Server去拉取对应用户发过来的Message Content。如果把消息框给关闭了，那么直接就不去拉取了，这样流量就小了很多。特别适用于移动端。
优化方案二：
User-B在登录的时候，一次性拉取所有好友给它的离线消息，把这些离线消息在本地持久化，可以存储在SQLite中，也可以自己定义数据文件格式，当然，无论什么样的方式，数据总是类似以下二维表的方式:
sender_uid send_time message_content User-A-id xxxxx 你好 User-C-id xxxxx 晚上来我家吃饭 User-F-id xxxxx 领导，明天请假
这样，开始流量是大一些，但是一劳永逸，到时候按需查询本地数据文件即可。
卡顿其实不存在的，速度慢倒是可能，卡顿其实就是UI线程被阻塞了一样，是把网络请求离线数据的工作放到了UI线程上，这样其实是不合适的，UI线程只需要关注用户点击，拖拽等UI事件。把计算量大，网络IO，文件IO等延迟性高的放到后台的worker线程中。现在有各种响应式编程框架，什么RxJava，RxJs等，已经不需要担心不同线程互交数据很难了，而且很轻松就可以做到不用显式加锁，完全异步。
这里的速度慢只是数据量大，传输到Client端需要很多时间，但是这个请求数据是后台线程来做的，从UI上用户是感觉不到速度慢的，用户自己也不知道有没有离线消息，如果要做到离线消息快点到达的话，做离线消息分页请求就可以了。
注意，响应式编程与信号槽机制还是有区别的，信号槽机制是对象之间观察者模式的一种实现，响应式编程与信号槽很相似，但是它在相似的基础上还加强了数据流的概念，而观察者模式非常适合描述这样的数据流。
如果一次性拉取离线消息到本地持久化，那么不存在重复拉取的问题。
title: 即时通信消息的可靠性保证---离线篇 date: 2017-10-29 21:26:00 tags:
即时通讯
前言
上一篇讲解了IM消息可靠性保证的双方在线情况，以及实现方案。那如果Client-B不在线，IM应用又是如何保证消息的可达性的呢？ 这就是本文所要讨论的问题。
消息接收方不在线时的简化流程
注意，对于步骤4而言，无论是传统的PC客户端IM，比如QQ。还是主流的移动端IM，比如Wechat，消息发送出去以后，无论是对方实时在线收到还是对方不在线被IM-Server离线存储了，对于发送方而言只要消息没有因为网络等原因莫名消失，就应该被认为是对方收到消息了。
从技术角度讲，消息接收方是“收到消息发送消息Ack包”的真正发起者，但是实际有两种可能，一种是接收方发出，而另一种是由IM-Server代为发送（伪应答）。
典型离线消息表的设计以及拉取离线消息的过程
接收方B要拉取发送方A给它发送的离线消息，只需在recceiver_uid(即接收方B的用户ID)，sender_uid（即发送方A的用户ID）上查询，然后收到消息后，接收方B发送Ack:notify包通知IM-Server，这时候IM-Server才把离线消息删除。
注意，因为接收方B，User-B一旦登录上线，就会首先拉取离线消息，遍历自己的好友列表，获取好友的用户ID，填入发送方ID，发送一条“获取所有好友离线的请求”到IM-Server，这样就知道谁昨天，前天，几天前给我发消息了。必须遍历好友列表，因为User-B不知道谁在它离线的时候给它发过消息。
步骤1，User-B开始拉取User-A发送给它的离线消息 步骤2，IM-Server从DB-Server中拉取离线消息 步骤3，IM-Server从DB-Server中把离线消息删除 步骤4，IM-Server把离线消息返回给User-B
上述流程中存在的问题以及优化方案
一旦User-B有很多好友，登录时客户端需要对所有好友进行离线消息拉取，客户端与IM-Server互交次数就会比较多
优化方案一：
类似于lazy load的方式，当User-B对User-A感兴趣，点击User-A头像图标打开聊天对话框的时候，这时候再发送获取User-A发送给User-B的离线消息。这是按需拉取优化。 但是这个方案一般在实际场景中不用，因为聊天消息如果是按需才拉取，那么User-B可能永远也不会点击User-A的头像，因为你看各种IM App都不是这么做，你一旦登录，就会有消息框弹出来，XX给你发了消息，不然你很可能错过重要的消息，容易误事。一般登录都要主动提示拉取。
所以这里可以变通一下，还是lazy load的思想，User-A登录，拉取给User-A发送离线消息的好友的ID列表，也就是，弹出消息框，报告User-A，XXX,XXX给你发离线消息了，你点开哪一个，我就去请求IM-Server去拉取对应用户发过来的Message Content。如果把消息框给关闭了，那么直接就不去拉取了，这样流量就小了很多。特别适用于移动端。
优化方案二：
User-B在登录的时候，一次性拉取所有好友给它的离线消息，把这些离线消息在本地持久化，可以存储在SQLite中，也可以自己定义数据文件格式，当然，无论什么样的方式，数据总是类似以下二维表的方式:
这样，开始流量是大一些，但是一劳永逸，到时候按需查询本地数据文件即可。
接收方一次性拉取大量离线消息导致速度慢，卡顿的解决方案
卡顿其实不存在的，速度慢倒是可能，卡顿其实就是UI线程被阻塞了一样，是把网络请求离线数据的工作放到了UI线程上，这样其实是不合适的，UI线程只需要关注用户点击，拖拽等UI事件。把计算量大，网络IO，文件IO等延迟性高的放到后台的worker线程中。现在有各种响应式编程框架，什么RxJava，RxJs等，已经不需要担心不同线程互交数据很难了，而且很轻松就可以做到不用显式加锁，完全异步。
这里的速度慢只是数据量大，传输到Client端需要很多时间，但是这个请求数据是后台线程来做的，从UI上用户是感觉不到速度慢的，用户自己也不知道有没有离线消息，如果要做到离线消息快点到达的话，做离线消息分页请求就可以了。
注意，响应式编程与信号槽机制还是有区别的，信号槽机制是对象之间观察者模式的一种实现，响应式编程与信号槽很相似，但是它在相似的基础上还加强了数据流的概念，而观察者模式非常适合描述这样的数据流。
解决重复拉取离线消息的问题
如果一次性拉取离线消息到本地持久化，那么不存在重复拉取的问题。