本文主要节选和总结自沈剑大佬的 微信多点登录与QQ消息漫游架构随想和文章的评论，略有删改
1、多点登录和消息漫游架构
多点登录指的是同个账号可以在多类终端（安卓、pc）同时登录，但是同类终端只能在唯一的一台设备上登录。
消息漫游指的是服务端保存聊天消息，使得用户在任何终端设备登录账号，都能拉取到所有历史聊天消息。
1.1 多点登录下的消息发送
用来保存用户在线状态的缓存从用户id为key，改成用户id拼接上终端类型和登录点。
用户 A 给好友 B 发送消息时需要给自己的其他终端登录设备和好友 B 的所有终端登录设备发送消息。
1.2 消息漫游实现
（1）所有消息需要在云端存储一份
（2）每个端本地存储last_msg_id，在登录时可以到云端同步历史消息（web端不允许拉取历史数据）
（3）云端存储所有消息成本较高，一般会对历史消息时间(或者条数)进行限制，比如3个月
2、问题
问：如果在某一端，比如 pc 删除了好友，怎么保证其它终端的好友列表一致性
如果其他终端也在线，需要服务端实时推送更新事件到其他端，修改本地数据
如果其他终端暂时不在线，那么需要其他终端在下次登录时重新拉取用户列表
问：数据库存放何种类型的数据合适 ， 消息 这种临时性数据 持久化到关系型数据库合适吗
大文件二进制类放db不一定适合。离线消息数据，放数据库合适
问：如果一台服务器比如gate宕机或者重启，连接上来的用户的缓存信息应该怎么处理？简单的说就是高可用如何实现？
（1）消息可达性不会受影响，要么落地，要么没有ack。
（2）状态一致性不会有问题：投递失败，可以将状态置为离线，暂时离线存储，恢复后重新投递消息。
（3）客户端有重连机制，一台挂了，可以连另一台。
问：关于拉取离线消息，由于本地存储了last msg id如果本地应用清除数据，重装，换手机登录，又或是h5页面登录没有本地缓存的情况，如何拉取消息，3个月的消息全拉？
策略pm可以定，架构都可以实现。常见策略是：分页拉取，按需拉取。
