微信多点登录与QQ消息漫游架构随想精选.pdfVIP

微信多点登录与QQ消息漫游架构随想 【需求缘起】 之前的⼀些⽂章简单介绍了 《“单⼈消息”》 《“离线消息”》 《“群消息”》 《“⽤户状 态”》的⼀些相关技术 （点击 ⾯的link直接阅读），今天来聊⼀聊“多点登陆”与“消息 漫游”。 提问：什么是多点登录？ 回答：以微信为例，可以PC端，phone端同时登录，同时收发消息。 需要注意的是，⼀个端只能登录⼀个实例，例如同⼀个QQ号，在pc1 登录，再到pc2 登录，后者会把前者踢出，pc1会收到通知“你已在别处登录xxoo”。 提问：什么是消息漫游？ 回答：在任何⼀个终端的任何⼀个实例登录qq，都能够拉取到所有历史聊天消息，这 个就是消息漫游。 微信⽬前只⽀持“多点登录”同时收发在线消息，没有实现“消息漫游”，潜台词是：登 出⼿机微信，登录PC微信，聊天，再登录⼿机微信，是看不到历史消息的。 【架构回顾】 整个即时通讯架构可以抽象成这么⼏层： （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 当然，单对单消息有⼀系列应⽤层超时、重传、确认、去重的机制，这不是本⽂的重 点，不进⾏展开，细节详见 《微信为什么不丢消息》。 【接收⽅多点登陆】 接收⽅多点登录，pc也登录，phone也登录，后⼀端登录不会将前⼀端踢出，cache中 存储状态与登录点时，不再以u er_id为key，改为以u er_id+终端类型为key即可。 B：online(状态)，gate2(登录点) 改为 B+pc：online(状态)，gate2(登录点) B+phone：online(状态)，gate3(登录点) 当⽤户A给⽤户B发送消息时，取出所有B的登录点，进⾏消息群发即可 （如 图中步 骤4与步骤5）。 【发送⽅多点登陆】 有朋友可能要问，发送⽅和多点登录有什么关系？ 假设⽤户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。 只有这样，才能在所有⽤户的所有端，恢复与还原双⽅聊天的 下⽂。 【消息漫游】 如果业务不需要⽀持“消息漫游”的功能，对于在线消息，如果⽤户接收到，是不需要 存储到数据库的。但如果要⽀持“换⼀台机器也能看到历史的聊天消息”，就需要对所 有消息进⾏存储了。 消息投递如 图，⽤户A发送消息给⽤户B，虽然B在线，仍然要增加⼀个步骤2.5，在 投递之前进⾏存储，以备B的其他端登陆时，可以拉取到历史消息。 消息拉取如 图，原本不在线的B(phone端)，又重新登录了，ta怎么拉取历史消息？ 只需要在客户端本地存储⼀个 ⼀次拉取到的m g_id(time)，到服务端重新拉取即 可。 这⾥还有