魅族云同步的实践-协议和架构

背景

这里所说的云同步，指魅族的业务背景下，在移动应用场景中，经同步服务把数据保持多端一致的服务。它提供了如联系人、便笺、信息、通话记录、日历、文件等类型的数据同步功能，由移动设备上的客户端和云端组成。

魅族云同步于2008年开始使用，目前服务千万级用户。以下就同步协议，架构部署和数据处理等方面进行一些分享。

业务定义、同步协议

根据场景，把同步业务划分为如下3类型4协议：

MZ-SyncML协议

MZ-SyncML，基于微软的SyncML协议（俗称4步同步），进行重新设计和开发实现的魅族同步协议。它交互精简、业务聚焦，解决了典型的结构化数据同步需求，如联系人、日历、便笺、通话记录、信息等业务。

它采用JSON进行数据交换，由接口层、同步点管理、数据解析、中间缓存数据管理、同步引擎、同步策略、冲突解决机制和Mapping关系管理等逻辑组成。

在同步策略上，实现了双向同步200（Two-way、快同步）、慢同步201（Slow sync）、客户端刷新同步203（Refresh from client）、服务端刷新同步205（Refresh from server）。

在同步点管理上，设计了客户端同步点（ClientAnchor），用于校验验证采用何种同步类型，管理选取客户端增量数据；还有服务端同步点(ServerAnchor)，用于管理选取服务端增量数据。

一个完整的同步有4个阶段，分别为Request、Submitdata、Getdata、Result，简单示意图如下。

其中，sessionId为服务端的会话标识，isFinal为分批数据是否结束标识，clientData为客户端业务数据，serverData为服务端业务数据，resultList为处理data结果数据（标识成功或失败）。

Semi-Sync协议

半同步协议，在快同步和慢同步中，同步失败时，实现不重复上传和拉取已同步成功的数据。请注意，它有别于MySQL同步复制的半同步方案(Semi-Synchronous)。

云同步是批量传输数据的，如果某批次出错，或单批次有若干数据出错，导致同步失败。下次同步时会有两个问题，一是客户端重复提交上次的所有数据（包括已成功的数据），二是拉取上次同步成功的数据。

MZ-SyncML设计了ClientAnchor和ServerAnchor两个同步点，在半同步协议里，我们增加了半同步点（SemiAnchor）。

以201慢同步为例说明。

第一次201同步：

1. 客户端提交100个联系人，当前同步点Anchor
2. 服务端成功写入40个，60个失败；则生成这40个Mapping数据，包括Luid、Guid、Anchor三个字段；更新SemiAnchor的值为Anchor；返回100个Result数据，40个成功，60个失败
3. 客户端接收到100个Result数据，对40个成功的数据生成Mapping；并更新SemiAnchor为Anchor；同步结束，结果为失败

第二次继续发起201同步：

1. 客户端检测有100个联系人，但SemiAnchor与Mapping标记了40个同步过的数据，过滤掉这40个联系人，只上传60个联系人
2. 服务端接收到60个联系人，并成功写入；但服务端有40个联系人，需要返回给客户端；进一步检测到SemiAnchor和Mapping，发现这40个已同步成功，无需返回给客户端
3. 客户端拉取数据为0，无需处理；同步结束，结果为成功；下次则会发起200快同步

如上，根据SemiAnchor和Mapping数据，可以解决同步失败下数据重复提交，二次拉取数据两个场景问题。

File-Sync协议

文件同步协议，是从MZ_SyncML分离出来的独立文件同步协议，它描述了文件类数据的同步方式。

采用和MZ-SyncML类似的方式，把变更文件信息列表进行同步，再按需进行上传与下拉文件。

业务上需要考虑一点，即文件对象需与父对象保持一致。

注意，文件同步需在父对像同步完成后进行；并且，文件同步的类型需与父对象同步类型一致。 如联系人本次同步类型是205，则联系人头像同步类型也必须是205。否则，会导致联系人头像同步时，解决冲突的合并规则与父对象不一致。

One-Sync协议

一次同步，即一次交互完成数据同步的协议，它解决联系人分组，便笺分组，短信快速回复、邮箱帐号和浏览器书签等小数据同步的场景。

数据模型设计为{key,value}的结构。key存储业务的唯一值，如分组名称；value以JSON格式存储多个附属值，如邮箱帐号的帐号类型，帐号名称等。

一般而言，数据变更有增删改（N、U、D）三个类型。对于key变更的操作，One-Sync里把U分解为N、D两个操作。而对于key不变，value变化的变更操作仍为U。 One-Sync只有一个同步点，由服务端同步点ServerAnchor。

在一次请求中，客户端会上传SyncType、ServerAnchor和变更数据；服务端则把ClientData和ServerData进行比对后存储，然后把比对后的SyncType、变更数据和New_ServerAnchor返回客户端。

One-Sync同样支持200、201、203、205同步类型。 以客户端发起205同步为例（服务端刷新同步），逻辑如下：

1. 客户端请求205的同步，不提交本地数据
2. 服务端丢弃客户端提交的数据，返回服务端的所有数据
3. 客户端接收数据成功，数据处理成功；然后清除本地旧数据，保证本地数据与服务端一致；本次同步结束，结果为成功，下次会进行200快同步
4. 客户端接收数据失败，或接收成功后数据处理失败；则不清除本地旧数据；本次同步结束，结果为失败；下次仍进行205同步

同步失败处理机制

同步涉及到客户端、服务端逻辑，实际逻辑中会有失败的场景，我们设计了失败处理的机制。

1. 在Submitdata阶段，服务端处理完客户端数据，会返回每条的结果数据Result给客户端，标记成功或失败；
2. 在Getdata阶段，客户端处理完服务端数据后，也会提交每条Result数据给服务端，标记成功或失败；
3. 只要有一条数据标记为失败，当次同步即被认为失败；
4. 下次同步会使用上次的同步点（如何不重复传输数据，请看Semi-Sync协议）。

服务架构

分析云同步的业务场景，具有下面的特性：