请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 7
浅谈移动端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环聊的主界面。

2013516161516320320.png

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

2、IM开发干货系列文章


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


另外,如果您正在查阅移动端IM开发资料,推荐阅读《新手入门一篇就够:从零开发移动端IM》。

3、基本概念


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

x.jpg

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

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


1.jpg

整个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、接收方多点登陆时的消息投递原理


2.jpg

接收方多点登录: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端的发出)。故:如果发送方也进行了多点登录,发送出去的任何消息,除了要投递给多点登录的接收方,还需要投递给多点登录的发送方(说白了就是自已发出的消息,也要发送到自已登陆的其它客户端上)。

3.jpg

如上图所示,发送方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、消息漫游原理


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

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

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

8、本文小结


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

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

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

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

(原文链接:微信多点登录与QQ消息漫游架构随想,内容有修订和改动)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:一个低成本确保IM消息时序的方法探讨下一篇:关于IM离线消息拉取的疑问

本帖已收录至以下技术专辑

推荐方案
评论 7
虽然思路并不太完整,但总结的不错
签名: 天气变冷了!
符合我们目前线上的实现机制
签名: 该会员没有填写今日想说内容.
这网站好叼啊!
如果是同一种设备的多个设备有什么思路吗?是否可以做到消息同步?
比如A1(phone)和A2(phone),交换登录,A1和A2的消息想做到同步。
签名: 有是美好的一天
引用:张小驰_q6jys 发表于 2017-11-03 15:11
如果是同一种设备的多个设备有什么思路吗?是否可以做到消息同步?
比如A1(phone)和A2(phone),交换登录, ...

同一种备在qq和微信直接给踢下线了,你得想清楚你要的是哪种逻辑。
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
被踢之后,再重新登录后,如何能做到同步之前设备的消息?我本地已经有一部分消息了。
签名: 有是美好的一天
引用:张小驰_q6jys 发表于 2017-11-03 15:32
被踢之后,再重新登录后,如何能做到同步之前设备的消息?我本地已经有一部分消息了。

拉取服务器上最新消息序列号至你本地序列号间的所有消息。
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

Processed in 0.140626 second(s), 40 queries , Gzip On.

返回顶部