浅谈移动端IM的多点登陆和消息漫游原理

1、前言

在移动端IM大行其道之前的PC端IM时代，所谓的多端登陆控制无非就是当你在一台电脑上登陆后，再在另一台电脑上登陆时就会把之前登陆的账号给踢出（比如QQ就是这样）。同样PC端时代的IM消息漫游不过就是可以在另一台电脑上下载之前的历史记录而已（参考PC端QQ）。

但自从Google在2013年的开发者大会（Google I/O）上公布了一款叫“Google 环聊”（网址：hangouts.google.com）的移动端IM后，凭借Google的创意，多端登陆和消息漫游才真正有了现在的体验（Google环聊无法体验的话，参考当前版本的微信、手机QQ就可以了）：即允许同一账号在多种设备上同时登陆和使用、且消息会以某种逻辑同步到另外的端上（包括自已发出的消息）等特性，使用得移动端IM的消息同步第一次真正的变的友好和易用。下图是Google环聊的主界面。



本文将展开聊聊移动端IM“多点登陆”与“消息漫游”的原理。

* 推荐阅读：阿里的《深度解密钉钉即时消息服务DTIM的技术设计》一文中的“六、多端同步机制设计”章节也详细分享了钉钉的消息同步机制，可以一并阅读。

2、IM开发干货系列文章

本文是系列文章中的第9篇，总目录如下：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
• 《移动端IM登录时拉取数据如何作到省流量？》
• 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
• 《浅谈移动端IM的多点登陆和消息漫游原理》（本文）
• 《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
• 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
• 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
• 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
• 《IM群聊消息的已读回执功能该怎么实现？》
• 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
• 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
• 《一个低成本确保IM消息时序的方法探讨》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
• 《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
• 《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
• 《IM的扫码登功能如何实现？一文搞懂主流应用的扫码登陆技术原理》
• 《IM要做手机扫码登陆？先看看微信的扫码登录功能技术原理》
• 《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
• 《IM开发实战干货：我是如何解决大量离线聊天消息导致客户端卡顿的》
• 《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
  

另外，如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、基本概念

什么是多点登录？
以微信为例：可以PC端、phone端同时登录、同时收发消息。需要注意的是：一个端只能登录一个实例，例如同一个QQ号，在pc1上登录再到pc2上登录，后者会把前者踢出，pc1会收到通知“你已在别处登录xxoo”。比如在微信上两个手机同时登陆同一个账号时就会踢出前一个登陆并给出如下图所示的提示：



什么是消息漫游？
在任何一个终端的任何一个实例登录qq，都能够拉取到所有历史聊天消息，这个就是消息漫游。微信目前只支持“多点登录”同时收发在线消息（如果你同时开过PC端微信和手机端微信，你可以注意到你收到和发出的消息都会在另一个端同时显示出来），没有实现“消息漫游”，潜台词是：登出手机微信，登录PC微信，聊天，再登录手机微信是看不到历史消息的。

4、一个典型的IM消息收发架构

整个IM的架构可以抽象成这么几层：

• 1）客户端：例如pc微信，手机qq
• 2）服务端：
          2.1）入口层gate集群：能够水平扩展，保持与客户端的连接；
          2.2）逻辑层logic、路由层router集群：高可用可扩展，实现业务逻辑，进行消息的路由；
          2.3）cache：高可用cache集群，用来存储用户的在线状态，与接入节点（用户具体连接在哪个gate节点）；
          2.4）db：固化存储消息，群信息，好友关系链等信息。
  

一个典型的消息收发流程如上图步骤1-5：

• 1）用户A登录在gate1上，发出消息；
• 2）gate1将消息给logic/router；
• 3）logic/router查询接收方的在线状态（B在线，C不在线）；
• 4）例如接收方C不在线，存储离线；
• 4）例如接收方B在线，且登录在gate2上，消息投递给gate2；
• 5）gate2将消息投递给B。
  

当然，单对单消息有一系列应用层超时、重传、确认、去重的机制，这不是本文的重点，不进行展开，细节详见《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》、《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》。

5、接收方多点登陆时的消息投递原理

接收方多点登录：pc登录、phone也登录，后一端登录不会将前一端踢出，cache中存储状态与登录点时，不再以user_id为key，改为以user_id+终端类型为key即可。

传统的PC端IM时的B客户端信息为：online(状态)，gate2(登录点)。

在支持多端登陆的移动端IM时信息应改为：
B的pc客户端：online(状态)，gate2(登录点)；
B的phone客户端：online(状态)，gate3(登录点)。

当用户A给用户B发送消息时，取出所有B的登录点，进行消息群发即可（如上图中步骤4与步骤5）。

6、发送方多点登陆时的消息投递原理

有朋友可能要问，发送方和多点登录有什么关系？

假设用户A登录了两个点：A1和A2；用户B登录了两个点B1和B2：

• A(A1发出的)发送消息给B(B1和B2)；
• B(B1发出的)发送消息给A(A1和A2)。
  

不就可以了么？

其实不然：A(A1发出的)发送消息给B(B1和B2)，B(B1发出的)发送消息给A(A1和A2)。A2端虽然收到了所有B回复的消息，但消息其实是在A1端发出的，故A2端只知道聊天消息的一半(所有B的回复)，缺失了聊天的上下文(所有A1端的发出)。故：如果发送方也进行了多点登录，发送出去的任何消息，除了要投递给多点登录的接收方，还需要投递给多点登录的发送方（说白了就是自已发出的消息，也要发送到自已登陆的其它客户端上）。



如上图所示，发送方A和接收方B都进行了多点登陆，服务端cache中存储的信息为：

• A的pc端：online(状态)，gate0(登录点)；
• A的phone端：online(状态)，gate1(登录点)；
• B的pc端：online(状态)，gate2(登录点)；
• B的phone端：online(状态)，gate3(登录点)。
  

当用户A（phone端）给用户B发送消息时，除了要投递给B的所有多点登录端，还需要投递给A自已多点登陆的其他端（pc端），如上图中步骤4与步骤5。只有这样，才能在所有用户的所有端，恢复与还原双方聊天的上下文。

7、消息漫游原理

如果业务不需要支持“消息漫游”的功能，对于在线消息，如果用户实时接收到则是不需要存储到数据库的。但如果要支持“换一台机器（指的是用户的客户端）也能看到历史的聊天消息”，就需要对所有消息进行存储了。


消息投递如上图：用户A发送消息给用户B，虽然B在线，仍然要增加一个步骤2.5，在投递之前进行存储，以备B的其他端登陆时，可以拉取到历史消息。


消息拉取如上图：原本不在线的B(phone端)，又重新登录了，他怎么拉取历史消息？只需要在客户端本地存储一个上一次拉取到的msg_id(time)，到服务端重新拉取即可。这里还有个问题：由于服务端存储所有消息成本是非常高的，所以一般“消息漫游”是有时间（或者消息数）限制，不能拉取所有所有几年前的历史消息，比如只能拉取3个月内的云端消息等。

8、本文小结

“多点登录”是指多个端同时登录一个帐号，同时收发消息，关键点是：

• 1）需要在服务端存储同一个用户多个端的状态与登陆点；
• 2）发出消息时，要对发送方的多端与接收端的多端，都进行消息投递。
  

“消息漫游”是指一个用户在任何端，都可以拉取到历史消息，关键点是：

• 1）所有消息存储在云端；
• 2）每个端本地存储last_msg_id，在登录时可以到云端同步历史消息；
• 3）云端存储所有消息成本较高，一般会对历史消息时间(或者条数)进行限制。
  

（原文链接：微信多点登录与QQ消息漫游架构随想，内容有修订和改动）

虽然思路并不太完整，但总结的不错

符合我们目前线上的实现机制

这网站好叼啊！

如果是同一种设备的多个设备有什么思路吗？是否可以做到消息同步？
比如A1(phone)和A2(phone)，交换登录，A1和A2的消息想做到同步。

引用：张小驰_q6jys 发表于 2017-11-03 15:11
如果是同一种设备的多个设备有什么思路吗？是否可以做到消息同步？
比如A1(phone)和A2(phone)，交换登录， ...

同一种备在qq和微信直接给踢下线了，你得想清楚你要的是哪种逻辑。

被踢之后，再重新登录后，如何能做到同步之前设备的消息？我本地已经有一部分消息了。

引用：张小驰_q6jys 发表于 2017-11-03 15:32
被踢之后，再重新登录后，如何能做到同步之前设备的消息？我本地已经有一部分消息了。

拉取服务器上最新消息序列号至你本地序列号间的所有消息。

很不错的分享，支持群主

学习了

大赞

楼主不知我这个思路对不对，主要是跟多端登陆时消息同步跟离线的拉取有点疑问
1、PC、phone可以同时登陆，另外安卓和苹果只能同时在线一个
2、假如PC端登陆在线的，phone端登陆不必再拉取离线，只做多端消息同步(根据本地的消息id与服务端id比较)
3、主要疑问：假如客户端在安卓登陆有收发一些消息，然后退出登录，之后再到苹果登录，同时在退出到苹果登录期间有离线消息，此时登录的苹果设备要拉取离线消息和多端消息同步两个都要做，这部分的处理感觉不好，毕竟离线消息被包含在要做的多端同步消息里了
4、多端同步的依据是根据本地的id做比较，服务器生成消息id，对于发送方发送的消息存到本地是没有id的，后续做多端同步可能会出现重复的消息

引用：lmyJavaDE1 发表于 2018-09-28 18:31
楼主不知我这个思路对不对，主要是跟多端登陆时消息同步跟离线的拉取有点疑问
1、PC、phone可以同时登陆， ...

1、2两点基本上理解是对的。

3、不需要区分什么离线还是多端，反正大于本地消息id或时间戳的就拉下来。
4、发送方自已的消息也是同样的道推到服务端，只是在另一端拉取的时候看到的发送人就是“我”而已，不矛盾

引用：JackJiang 发表于 2018-09-28 18:45
1、2两点基本上理解是对的。

3、不需要区分什么离线还是多端，反正大于本地消息id或时间戳的就拉下来 ...

如果这样说的话，要考虑多端同步的问题，客户端登录之后是不用拉取离线消息，只需消息同步就行了？

引用：lmyJavaDE1 发表于 2018-09-29 09:19
如果这样说的话，要考虑多端同步的问题，客户端登录之后是不用拉取离线消息，只需消息同步就行了？

同步跟离线在这里已经没有区别了。。。

引用：JackJiang 发表于 2018-09-29 09:51
同步跟离线在这里已经没有区别了。。。

还有就是 目前消息表分成单聊、群聊，通知类消息(好友申请，同意添加。。。)也是存贮在这两个表中，如果做多端同步的话，理所应当要限制某段时间内或者消息条数，但是按目前这样做法，那些好友列表，群相关类似这类数据如果在另外一端没拉取到通知消息(在限制范围之外)就不会做接下去的逻辑操作(新增好友，群成员等等)

消息漫游和多点登录，还会有ack确认吗？假如投递到每个端了，服务端的消息需要删除吗？

引用：某非著名程序 发表于 2021-03-10 20:08
消息漫游和多点登录，还会有ack确认吗？假如投递到每个端了，服务端的消息需要删除吗？

用时间戳增量更新，不需要删除

楼主，针对消息漫游，提出个问题，望指导。
消息漫游如何实现历史消息都可支持查询？终端不能保证所有数据都有，所以只能通过服务器查询或者把数据同步至终端？如果通过服务器查询，比如搜索“你好”，查到了1条记录，但是，终端的交互应该都是有侧边滚动条的吧，那就是需要有上下知道数量才能做到。你这边有接触过吗？有什么好方案可以指导指导，谢谢

引用：小张 发表于 2021-08-26 11:13
楼主，针对消息漫游，提出个问题，望指导。
消息漫游如何实现历史消息都可支持查询？终端不能保证所有数据 ...

“侧边滚动条”你指的是什么样的东西？能截个图我理解一下吗