如何设计类似微信的多终端数据同步协议 | Grouk实践分享

原创 2015-09-18 王渊命 高可用架构
本文由王渊命在高可用架构群所做的分享整理而来，转载请注明高可用架构公众号：ArchNotes。

王渊命，团队协作IM服务Grouk联合创始人及CTO，技术极客，曾任新浪微博架构师、微米技术总监。2014年作为联合创始人创立团队协作IM服务Grouk，长期关注团队协作基础工具和研发环境建设，Docker深度实践者。


我们Grouk是一个创业团队，面向团队通讯的主打产品应用刚开始公测，因此我们也需要实现类似微信的多端数据同步功能，下面我主要从技术和产品的结合场景进行一些心得分享，感觉我们在这方面的探索还是值得和大家探讨的，这种需求业界也没有非常成熟的公开解决方案。
 
一、移动互联网时代多终端数据同步面临的挑战
 
首先要讲的是，多终端同步的含义及应用场景。
 
多终端同步是指用户在多个终端切换时可获得一致性体验，不丢失上下文，同时隐含的一个含义是，如果用户多个终端同时在线要能做到实时同步。
 
举几个应用的例子：
 
1、 Trello 看板应用
 
用户打开后，其他人操作看板，要能实时变化，不依赖用户刷新页面。如果用户在多个终端操作，也需要做到实时变化。通过测试，我发现Trello在移动端和PC同步的时候还是有Bug的。例如，PC设置离线，手机上操作card。PC连网，不刷新页面，数据经常无法同步。
 
2、 Quip这样的多人协作编辑
 
某人的编辑结果，其他人要能实时看到。同时还支持离线编辑、冲突合并。例如，Evernote多人协作是文档锁定模式的，冲突很难自动合并，体验上就差些。
 
这几种典型的应用场景是移动互联网爆发以来，应用富客户端化带来的一种趋势性变化。
 
移动端上是独立应用，PC端是基于JavaScript的应用，和原来PC互联网时代刷页面的交互体验完全不一样。这个当然原来也有，但应用没现在这么广泛。
 
移动客户端的爆发和应用富客户端化带来以下几个挑战：
 
服务器端的输出由HTML变成结构化数据（json等）。原来基于浏览器和HTTP协议的缓存规则机制失效，客户端需要针对具体的业务场景设计缓存。没有缓存的话，每次全量拉取很浪费流量。
用户习惯从多个终端进行操作，对跨屏操作的体验要求比较高了。
多人协作场景下，数据需要实时同步到不同用户的不同设备上。
 
二、多终端数据同步与传统消息投递协议的差异
 
接下来说一下多终端数据同步和IM的关系
 
虽然数据同步机制和IM消息投递是两个问题，但如果实现了实时同步，基本上就实现了一种特殊的IM。所以先说一下传统的IM投递机制。
 
传统的IM投递协议，大家应该都比较熟悉，5月的时候群里沈剑分享过一次。
 
这里借用其中的一句话：
 
消息可达性即消息的可靠投递，有一个著名的定理：SMC定理，Single-Message Communication,Published in :Communications, IEEE Transactions on (Volume:24 , Issue: 2 ) ，很短的一个论文。文章的结论是：任何端到端的消息传递协议，消息既不丢失，也不重复是不可能的。
 
也就是说传统的IM消息投递要么接受消息丢失，要么接受消息确认重试导致的重复问题。当然可以通过应用层面的排重机制来解决一问题。这里不再细说传统IM的投递机制，大家想了解可以看本公众号中沈剑的分享（【直播全文记录】 从零开始搭建高可用IM系统）。
 
虽然传统的IM投递机制+历史记录，也可以实现多终端同步：
 
所有设备都在线的情况下，直接投递。
离线→在线时，拉取历史记录补充缺失记录。
 
但这样做比较困难的地方在于：
 
变更如何同步？我们的消息不像传统IM，是不可变对象，我们的消息是可变的。同时，群组列表，联系人列表，这些都是可变的，如何同步？
投递确认机制的缺陷会导致一致性不好控制，如果出现多个终端不一致的情况，客户端无法自修复。只能提供特殊的刷新机制，由用户自己刷新。
 
比如，我前面提到的Trello的情况。当然，Trello的具体实现没分析过，这里只是推测。于是，我们考虑使用同步协议。说到同步机制当然要说一下微信，今天说分享的时候有人就提到了微信的SYNC。
 
微信的SYNC协议没有详细的公开分享，按照公开说明，是参考Activesyec实现的。据我的观察，当然，以下微信协议的说明不保证正确性，群里也有微信的同学，可以纠正。
 
同步机制是通过服务器通知，客户端拉取机制实现的。IM协议投递的是新消息的通知，拉取是根据版本号增量同步，将消息投递转换为基于状态同步的协议。（这个有公开说明）
每个Folder的版本号是严格有序递增的，Folder不是按照会话划分的。
微信投递消息和邮件类似，是将消息投递到每个人的收件箱中，每投递一个消息增加一个版本号。
 
以上只是我个人的简单分析，不确定微信的服务器端是如何存储的。也不确定微信是如何处理变更的，比如，通讯录的同步。所以我们还是得自己设计一个同步协议。
 
三、Grouk在多终端数据同步协议上的探索实践
 
到这里，先总结下我们设计的该同步协议的目标 :
 
解决接口数据做本地缓存需要根据具体接口单独设计的问题，设计一种统一的客户端缓存数据机制。这个问题应该是所有App类应用都会遇到的问题。
实现消息的多终端增量同步，然后通过同步机制确保不丢消息。同步机制必须避免流量浪费，所以需要做增量。
消息同步和联系人/群组等同步使用同一套机制。这个也为以后的业务数据类型扩充做准备。
客户端数据能自修复达到最终一致性。
不解决冲突合并问题。因为我们的消息比较轻量，不需要像文档一样考虑冲突问题，降低复杂性。
 
有了目标后，我们首先想到了Git等版本管理系统。因为二者要解决的问题是类似的，区别在于实时性上，还有Git的Server和Client是对等的，而我们这里的Client只是Server的子集。
 
因为时间关系，关于Git等版本管理系统的机制这里不细说了。直接说一下我们的抽象和解决方案 。
 
数据结构图，如下：

每个需要同步的数据集抽象成一个Folder，Folder可能是多人共享的，也可能是某人专用的。这里的Folder相当于一个索引表，引用的是对象ID。
每个Folder维护一个变更集（ChangeSet），增量同步通过变更实现，变更的版本号有序递增。变更是每次操作生成的，每一次Folder索引或者Folder引用对象的操作都生成一个变更。
变更（Change）有对应的操作（OP）。如：新增、更新、删除等。包括索引变更和索引引用对象的变更。携带变更数据。客户端根据操作要在本地实现重放逻辑。
每个Folder中的索引对象会被分配一个该Folder中的有序递增ID。每个索引对象也可以拥有自定义属性。
所有的数据对象都统一定义，有更新时间，等基本字段。抽象出通用的操作接口（ObjectStore）。
客户端会通过Change将服务器的Folder及对象库同步下去，不过同步的只是服务器上的一个子集，并不是全量。
 
客户端可以通过对象的更新时间来确定本地缓存的有效性。
 
下图是我们利用这套机制的流程：

用户发消息、修改消息、修改个人信息等操作，都触发一次相关Folder的变更，存到变更集中，实时投递到在线客户端。
在线客户端收到变更后，检查本地的版本号和当前版本号是否连续。如果不连续说明有消息丢失，从服务器拉取二者之间丢失的变更。然后客户端根据操作定义将变更应用（apply  change）到本地的Folder和对象库。
离线客户端上线后，带上本地的Folder的版本号，发起sync request，去服务器端同步变更。同步后需要进行的操作同上。
所有的对象通过统一的接口获取。支持类似于HTTP的ETag，变更更新模式，不过是针对每个对象的版本，以增强本地缓存机制。
 
可以说，相当于实现一个服务器和客户端实时同步的轻型数据库。
 
以下是我们这样设计的优缺点。
 
优点：
用户在线的情况下，大多数情况变更是直接投递下去的。比通知→拉取模式的和服务器的交互少，更省资源。
离线缓存比较容易实现，离线浏览的体验会比较好。
能保证终端和服务器的数据一致性。
相对比较通用，可以适用于多个业务场景。
 
缺点：
本地客户端的实现逻辑比较重。微信的思想是轻客户端，重服务器。我估计我们在这里还得踩些坑。
只能保证同一个Folder的最终一致性。
 
基本协议设计就讲这里了，再说一下我们的技术栈。
 
主要还是基于Java+Netty研发。我们撸了一个简单的前端框架，主要是为了实现用同一套逻辑，服务多个接入层。
 
我们的接入层支持的协议有HTTP，自定义TCP，WebSocket。通过接入层转换后，变为内部的request/response，后面共享同一套逻辑。也就是说同一个请求，可以通过HTTP发送，也可以通过长连接（TCP/WebSocket）发送。
 
数据对象上，我们接口支持JSON/Protobuf两种。根据客户端的accept自动适配。接口输出格式统一定义对象，客户端可以和服务器端共用。
 
总结下当前应用，尤其是工具应用的一种趋势。
 
IM已经变得不像IM，不是IM的要变成IM。前半句是说，当前的IM已经逐渐不像传统的IM了，无论是微信，还是Slack，还是我们的Grouk，和传统的IM区别越来越大。后半句是说，不是IM的应用因为要做多终端实时同步，协议越来越靠近IM机制了。
 
另外个人感觉这种趋势不一定仅局限在工具类。哪怕是电商网站，如果能同步用户的购物车到多个终端，用户的体验也会更进一步。
 
我们应用使用同步协议已实现的效果 :
 
多终端数据保持一致，用户切换后不会丢失上下文（比如QQ的消息只投递到一个终端）。
允许多个终端登录，比如，多个手机、多个Web。
历史记录可以在任何一个端获取，也可以通过搜索从任何一条历史消息开始上下回溯。
未读数/收藏实时同步。
联系人信息/群组信息实时同步。
更多欢迎注册体验     https://（顺便打个广告）。
 
最后，再说一个题外话，就是创业公司做技术类的创新是否值得？
 
我们也讨论过，假设当初直接拿现成的XMPP来做，估计我们的推出时间也可以早几个月。我们在这套机制上花费的时间也不少。但我们还是觉得当前IM这么多，用户的体验已经被QQ、微信等工具教育的情况下，如果体验不能更进一步，估计用户连尝试的愿望都没有。但到底花多少时间，估计要做个平衡。
 
Q&A
 
Q1：为什么不采用XMPP协议呢？多人协作时后端出现用户不在一台服务器上如何同步？

XMPP由于众所周知的原因，XML不太适合移动使用。一般移动上使用都要做压缩，比如WhatsApp。另外就是前面描述的，做变更同步比较麻烦。
 
Q2：客户端所有请求都是通过和服务器的长连接过来吗？没有走比如短连接的HTTP协议之类的？

不是所有，有走短连接的。我们采用一种动态机制，长连接优先。消息上我们没有采用长轮询的方式。客户端是TCP长连接，Web版本是WebSocket。
 
Q3：这个版本号必须是有序的吗？是否可以跟Git一样用随机字符+链表的方式做？

我们这个方案里版本号必须是有序严格递增的，因为要靠这个判断是否丢失消息。Git的方案是因为需要离线写操作，我们当前没这个需求，写都是通过服务器中心写的。
 
Q4：QQ的消息只投递到一个终端？这是多年前了吧？
 
QQ是对移动端做了写优化，离线登陆后会补充投递一部分消息，但做不到全终端一致同步。
 
Q5：如何选择客户端服务器之间心跳的时长？有哪些选择的因素考虑，怎么权衡？

这个说实话我们也在摸索。没有太多数据支撑的经验。移动端其实心跳已经不是很重要了，大家的使用习惯基本上是查看消息回复，然后就沉后台了。我们做了点优化就是所有的消息都视为一种心跳。心跳其实是服务器端判断客户端是否在线的一种方式。移动客户端网络变化能收到通知，一般是几分钟一次。 Web版本没有这种功能，所以要靠心跳来判断网络，一般是几秒钟一次。
 
Q6：发现消息版本不连续后，是全量拉取吗？还是可以判断拉去到哪？

发现消息不连续后，由于版本号是有序递增的，可以计算出中间的差距，直接拉缺失的即可。当然服务器的版本是有限的，如果发现客户端的本地数据太旧，是需要重新全量拉取的。全量拉取的机制不同，Folder的规则不一样。
 
想和群内专家继续交流有关高可用架构的问题，请关注公众号后，回复arch，申请进群。
 
本文策划庆丰@微博，内容由王杰@益体康编辑，庆丰@微博校对与发布，其他多位志愿者对本文亦有贡献。更多关于架构方面的内容，读者可以通过搜索"ArchNotes"或点击页首的蓝字，关注"高可用架构"公众号，查看更多架构方面内容，获取通往架构师之路的宝贵经验。转载请注明来自"高可用架构 (ArchNotes)"微信公众号。