這里所說(shuō)的云同步,，指魅族的業(yè)務(wù)背景下,，在移動(dòng)應(yīng)用場(chǎng)景中，經(jīng)同步服務(wù)把數(shù)據(jù)保持多端一致的服務(wù),。它提供了如聯(lián)系人,、便箋、信息,、通話記錄,、日歷、文件等類(lèi)型的數(shù)據(jù)同步功能,，由移動(dòng)設(shè)備上的客戶端和服務(wù)端組成,。

魅族云同步于2008年開(kāi)始使用，目前服務(wù)千萬(wàn)級(jí)用戶,。以下就同步協(xié)議,，架構(gòu)部署和數(shù)據(jù)處理等方面進(jìn)行一些分享。

根據(jù)場(chǎng)景,，把同步業(yè)務(wù)劃分為如下3類(lèi)型4協(xié)議：

MZ-SyncML協(xié)議

MZ-SyncML，基于微軟的SyncMl協(xié)議（俗稱(chēng)4步同步），進(jìn)行重新設(shè)計(jì)和開(kāi)發(fā)實(shí)現(xiàn)的魅族同步協(xié)議,。它交互精簡(jiǎn),、業(yè)務(wù)聚焦，解決了典型的結(jié)構(gòu)化數(shù)據(jù)同步需求,，如聯(lián)系人,、日歷、便箋,、通話記錄,、信息等業(yè)務(wù)。

它采用JSON進(jìn)行數(shù)據(jù)交換,，由接口層,、同步點(diǎn)管理、數(shù)據(jù)解析,、中間緩存數(shù)據(jù)管理,、同步引擎、同步策略,、沖突解決機(jī)制和Mapping關(guān)系管理等邏輯組成,。

在同步策略上，實(shí)現(xiàn)了雙向同步200（Two-way,、快同步）,、慢同步201（Slow sync）、客戶端刷新同步203（Refresh from client）,、服務(wù)端刷新同步205（Refresh from server）,。

在同步點(diǎn)管理上，設(shè)計(jì)了客戶端同步點(diǎn)（ClientAnchor）,，用于校驗(yàn)驗(yàn)證采用何種同步類(lèi)型,，管理選取客戶端增量數(shù)據(jù)；還有服務(wù)端同步點(diǎn)(ServerAnchor),，用于管理選取服務(wù)端增量數(shù)據(jù),。

一個(gè)完整的同步有4個(gè)階段，分別為Request,、Submitdata,、Getdata、Result,，簡(jiǎn)單示意圖如下,。

其中，sessionId為服務(wù)端的會(huì)話標(biāo)識(shí),，isFinal為分批數(shù)據(jù)結(jié)束標(biāo)識(shí),，clientData為客戶端業(yè)務(wù)數(shù)據(jù),，serverData為服務(wù)端業(yè)務(wù)數(shù)據(jù)，resultList為處理data結(jié)果數(shù)據(jù)（標(biāo)識(shí)成功或失?。?。

Semi-Sync協(xié)議

半同步協(xié)議，在快同步和慢同步中,，同步失敗時(shí),，實(shí)現(xiàn)不重復(fù)上傳和拉取已同步成功的數(shù)據(jù)。請(qǐng)注意,，它有別于MySQL同步復(fù)制的半同步方案(Semi-Synchronous),。

云同步是批量傳輸數(shù)據(jù)的，如果某批次出錯(cuò),，或單批次有若干數(shù)據(jù)出錯(cuò)，導(dǎo)致同步失敗,。下次同步時(shí)會(huì)有兩個(gè)問(wèn)題,，一是客戶端重復(fù)提交上次的所有數(shù)據(jù)（包括已成功的數(shù)據(jù)），二是拉取上次同步成功的數(shù)據(jù),。

MZ-SyncML設(shè)計(jì)了ClientAnchor和ServerAnchor兩個(gè)同步點(diǎn),，在半同步協(xié)議里，我們?cè)黾右粋€(gè)半同步錨點(diǎn)（SemiAnchor）,。

以201慢同步為例說(shuō)明,。

第一次201同步：

1. 客戶端提交100個(gè)聯(lián)系人，當(dāng)前同步點(diǎn)Anchor

2. 服務(wù)端成功寫(xiě)入40個(gè),，60個(gè)失?。粍t生成這40個(gè)Mapping數(shù)據(jù),，包括Luid,、Guid、Anchor三個(gè)字段,；更新SemiAnchor的值為Anchor,；返回100個(gè)Result數(shù)據(jù)，40個(gè)成功,，60個(gè)失敗

3. 客戶端接收到100個(gè)Result數(shù)據(jù),，對(duì)40個(gè)成功的數(shù)據(jù)生成Mapping；并更新SemiAnchor為Anchor,；同步結(jié)束,，結(jié)果為失敗

第二次繼續(xù)發(fā)起201同步：

1. 客戶端檢測(cè)有100個(gè)聯(lián)系人，但SemiAnchor與Mapping標(biāo)記了40個(gè)同步過(guò)的數(shù)據(jù),，過(guò)濾掉這40個(gè)聯(lián)系人,，只上傳60個(gè)聯(lián)系人

2. 服務(wù)端接收到60個(gè)聯(lián)系人，并成功寫(xiě)入；但服務(wù)端有40個(gè)聯(lián)系人,，需要返回給客戶端,；進(jìn)一步檢測(cè)到SemiAnchor和Mapping，發(fā)現(xiàn)這40個(gè)已同步成功,，無(wú)需返回給客戶端

3. 客戶端拉取數(shù)據(jù)為0,，無(wú)需處理；同步結(jié)束,，結(jié)果為成功,；下次則會(huì)發(fā)起200快同步

如上，根據(jù)SemiAnchor和Mapping數(shù)據(jù),，可以解決同步失敗下數(shù)據(jù)重復(fù)提交,，二次拉取數(shù)據(jù)兩個(gè)場(chǎng)景問(wèn)題。

File-Sync協(xié)議

文件同步協(xié)議,，是從MZ_SyncML分離出來(lái)的獨(dú)立文件同步協(xié)議,，它描述了文件類(lèi)數(shù)據(jù)的同步方式。

采用和MZ-SyncML類(lèi)似的方式,，把變更文件信息列表進(jìn)行同步,，再按需進(jìn)行上傳與下拉文件。

業(yè)務(wù)上需要考慮一點(diǎn),，即文件對(duì)象需與父對(duì)象保持一致,。

注意，文件同步需在父對(duì)像同步完成后進(jìn)行,；并且,，文件同步的類(lèi)型需與父對(duì)象同步類(lèi)型一致。 如聯(lián)系人本次同步類(lèi)型是205,，則聯(lián)系人頭像同步類(lèi)型也必須是205,。否則，會(huì)導(dǎo)致聯(lián)系人頭像同步時(shí),，解決沖突的合并規(guī)則與父對(duì)象不一致,。

One-Sync協(xié)議

一次同步，即一次交互完成數(shù)據(jù)同步的協(xié)議,，它解決聯(lián)系人分組,，便箋分組，短信快速回復(fù),、郵箱賬號(hào)和瀏覽器書(shū)簽等小數(shù)據(jù)同步的場(chǎng)景,。

數(shù)據(jù)模型設(shè)計(jì)為{key,value}的結(jié)構(gòu)。key存儲(chǔ)業(yè)務(wù)的唯一值,，如分組名稱(chēng),；value以JSON格式存儲(chǔ)多個(gè)附屬值,，如郵箱賬號(hào)的賬號(hào)類(lèi)型，賬號(hào)名稱(chēng)等,。

一般而言,，數(shù)據(jù)變更有增刪改（N、U,、D）三個(gè)類(lèi)型,。對(duì)于key變更的操作，One-Sync里把U分解為N,、D兩個(gè)操作,。而對(duì)于key不變，value變化的變更操作仍為U,。

One-Sync只有一個(gè)同步點(diǎn),，由服務(wù)端同步點(diǎn)ServerAnchor。

在一次請(qǐng)求中,，客戶端會(huì)上傳SyncType,、ServerAnchor和變更數(shù)據(jù)；服務(wù)端則把ClientData和ServerData進(jìn)行比對(duì)后存儲(chǔ),，然后把比對(duì)后的SyncType、變更數(shù)據(jù)和New_ServerAnchor返回客戶端,。

One-Sync同樣支持200,、201、203,、205同步類(lèi)型,。以客戶端發(fā)起205同步為例（服務(wù)端刷新同步），邏輯如下：

1. 客戶端請(qǐng)求205的同步,，不提交本地?cái)?shù)據(jù)

2. 服務(wù)端丟棄客戶端提交的數(shù)據(jù),，返回服務(wù)端的所有數(shù)據(jù)

3. 客戶端接收數(shù)據(jù)成功，數(shù)據(jù)處理成功,；然后清除本地舊數(shù)據(jù),，保證本地?cái)?shù)據(jù)與服務(wù)端一致；本次同步結(jié)束,，結(jié)果為成功,，下次會(huì)進(jìn)行200快同步

4. 客戶端接收數(shù)據(jù)失敗，或接收成功后數(shù)據(jù)處理失??；則不清除本地舊數(shù)據(jù)；本次同步結(jié)束,，結(jié)果為失??；下次仍進(jìn)行205同步

同步失敗處理機(jī)制

同步涉及到客戶端、服務(wù)端邏輯,，實(shí)際邏輯中會(huì)有失敗的場(chǎng)景,，我們?cè)O(shè)計(jì)了失敗處理的機(jī)制。

1. 在Submitdata階段,，服務(wù)端處理完客戶端數(shù)據(jù),，會(huì)返回每條的結(jié)果數(shù)據(jù)Result給客戶端，標(biāo)記成功或失敗

2. 在Getdata階段,，客戶端處理完服務(wù)端數(shù)據(jù)后,，也會(huì)提交每條Result數(shù)據(jù)給服務(wù)端，標(biāo)記成功或失敗

3. 只要有一條數(shù)據(jù)標(biāo)記為失敗,，當(dāng)次同步即被認(rèn)為失敗

4. 下次同步會(huì)使用上次的同步點(diǎn)（如何不重復(fù)傳輸數(shù)據(jù),，請(qǐng)看Semi-Sync協(xié)議）

服務(wù)架構(gòu)

分析云同步的業(yè)務(wù)場(chǎng)景，具有下面的特性：

云同步的服務(wù)端服務(wù)能力,，和用戶數(shù)成正比關(guān)系,。魅族云同步隨著用戶規(guī)模的增長(zhǎng)，經(jīng)過(guò)幾次的重構(gòu),、線上運(yùn)行,、探索與沉淀，逐步形成了當(dāng)前平臺(tái)的架構(gòu),。

接口規(guī)范

我們規(guī)范了接口的固有參數(shù),，擴(kuò)展參數(shù)，統(tǒng)一返回格式,，可精確到代碼行的錯(cuò)誤碼,，匹配錯(cuò)誤碼的信息。

如userid,、imei,、sn為固有參數(shù)；像apk版本,，系統(tǒng)固件為擴(kuò)展參數(shù),，部分接口不需要。

返回格式例子如下：

{
'code':10001
'message':'參數(shù)不合法'
'value':''
}

其中code為錯(cuò)誤碼,，200為成功,，其他為錯(cuò)誤。value是成功時(shí)返回的數(shù)據(jù),，建議使用JSON格式傳遞,。

message是code對(duì)應(yīng)的錯(cuò)誤信息，它與code共同放在資源文件,。在返回時(shí)由一個(gè)MessageHandler截停,，自動(dòng)填上code對(duì)應(yīng)的message,，不需要人工維護(hù)。

模塊化+單元化

通過(guò)業(yè)務(wù)規(guī)整,，抽象出了聯(lián)系人模塊,、短信模塊 、通話記錄模塊,、小業(yè)務(wù)模塊,、文件同步模塊。

聯(lián)系人,、短信,、通話記錄是使用頻次和數(shù)據(jù)量最大的3個(gè)項(xiàng)，故此獨(dú)立成模塊,。

文件同步,，與結(jié)構(gòu)化數(shù)據(jù)分離，進(jìn)行IO等有針對(duì)性的性能調(diào)優(yōu),。

我們?cè)谝粋€(gè)IDC里劃分了多個(gè)服務(wù)單元（建議不多于5個(gè)）,，每個(gè)單元包括服務(wù)模塊和存儲(chǔ)，一個(gè)單元服務(wù)只服務(wù)合理的用戶數(shù),。這樣易于控制規(guī)模,，分拆風(fēng)險(xiǎn)，維護(hù)遷移和容災(zāi),。

海量數(shù)據(jù)+路由組件

云同步的數(shù)據(jù)是海量的,，DB記錄數(shù)可能達(dá)到百億級(jí)、千億級(jí),，單個(gè)數(shù)據(jù)庫(kù)解決不了云同步的業(yè)務(wù)場(chǎng)景。

我們按用戶標(biāo)識(shí)（Userid）進(jìn)行水平拆分,，設(shè)計(jì)出多個(gè)數(shù)據(jù)庫(kù),；配備一個(gè)Userid到DB的路由規(guī)則。

單實(shí)例DB服務(wù)器上部署多個(gè)數(shù)據(jù)庫(kù),，建議10-30個(gè),，既降低運(yùn)維成本，又提高資源利用率,。

橫向擴(kuò)容時(shí),，更新路由規(guī)則即可平滑完成。

該DB集群,，由一個(gè)路由組件（SyncRouter）來(lái)管理,。它包括Userid到DB、Userid到Unit,、Userid到Redis,、Userid到文件系統(tǒng)的多個(gè)路由功能,。它具有透明訪問(wèn)、業(yè)務(wù)低耦合,、DB連接池自管理等特點(diǎn),。

我們采用RDB存取對(duì)用戶常用的熱數(shù)據(jù)，而用NoSQL存取冷備數(shù)據(jù),。例如聯(lián)系人有個(gè)時(shí)光機(jī)的備份功能,，我們就采用HBase來(lái)實(shí)現(xiàn)存儲(chǔ)。

多機(jī)房部署

我們做多機(jī)房部署的目的有三,，一是用戶就近訪問(wèn),，二是流量調(diào)度，三是異地容災(zāi),。

看如下云同步的架構(gòu)圖,，以3個(gè)IDC為例。

部署了多IDC,，設(shè)計(jì)好路由規(guī)則,，由路由組件提供Userid到IDC的路由功能。

IDC間的用戶數(shù)據(jù)分開(kāi),，不共享,，做好異地容災(zāi)，如把IDC_1的數(shù)據(jù)備份到IDC_2,。而在IDC_1出現(xiàn)故障無(wú)法提供服務(wù)時(shí),，通過(guò)GSLB分流，把該用戶群分發(fā)到IDC_2里進(jìn)行服務(wù),。

路由DB采用單點(diǎn)寫(xiě)保證一致性,。所有IDC通過(guò)專(zhuān)線訪問(wèn)主IDC，操作主路由DB,；主IDC通過(guò)MQ通知其他IDC,，進(jìn)行數(shù)據(jù)更新，保持?jǐn)?shù)據(jù)一致,。

手機(jī)端根據(jù)Useric和域名,，訪問(wèn)GSLB的分發(fā)服務(wù)，獲取到用戶相應(yīng)的同步服務(wù)IP,，實(shí)現(xiàn)流量調(diào)度目的,。并且，手機(jī)端都通過(guò)IP訪問(wèn)同步服務(wù),，不使用域名,，有效避免DNS劫持問(wèn)題。

GSLB根據(jù)IP所在區(qū)域和所屬線路,，在最優(yōu)的IDC落地,，并返回業(yè)務(wù)的最優(yōu)IP（GSLB詳見(jiàn)魅族另一篇博文,，不再贅述）。

理論上,，上述的方案僅適應(yīng)于有客戶端的Http,、Https請(qǐng)求，不適合瀏覽器訪問(wèn),。 為此,，我們做了一個(gè)擴(kuò)展，支持瀏覽器按GSLB的規(guī)則進(jìn)行調(diào)度,。

1. 把業(yè)務(wù)分為總域名,、多個(gè)子域名（匹配多個(gè)IDC）

2. 業(yè)務(wù)層嵌入一個(gè)GSLB模塊，根據(jù)設(shè)定規(guī)則進(jìn)分發(fā)到目標(biāo)子域名

流量?jī)?yōu)化

流量?jī)?yōu)化一方面是采用gzip或deflate進(jìn)行壓縮傳輸,，一方面是讓原始數(shù)據(jù)盡可能的小,。

魅族云同步第一階段采用XML為交換格式；第二階段上線了MZSync項(xiàng)目,，采用JSON為交換格式,。

我們?cè)诳紤]數(shù)據(jù)格式時(shí)，選出傳統(tǒng)JSON,、精簡(jiǎn)JSON和Protobuf三種格式,，進(jìn)行對(duì)比。

精簡(jiǎn)JSON,，是指變量名為少量字符,，不輸出空值變量的JSON格式。

Protobuf本質(zhì)上是對(duì)變量進(jìn)行排序,，不需要傳變量名,。

精簡(jiǎn)JSON和Protobuf的設(shè)計(jì)原理，有點(diǎn)相似,，前者簡(jiǎn)化變量名,，后者不傳變量名。

最后,，我們選擇了精簡(jiǎn)JSON格式，與傳統(tǒng)JSON相比,，能減少40%-60%的流量,，接近Protobuf的值。

參考圖如下（使用多維度抽樣數(shù)據(jù),，進(jìn)行實(shí)測(cè)計(jì)算得到）,。

以上，便是在業(yè)務(wù)的實(shí)踐,、發(fā)展中,，總結(jié)的同步協(xié)議,，架構(gòu)部署和數(shù)據(jù)處理心得。

其中,，MZ_SyncML和Semi-sync描述了云同步的核心解決方案,，F(xiàn)ile-Sync和One-Sync描述了云同步的業(yè)務(wù)解決方案；而One-Sync的設(shè)計(jì)思想較為通用,，適用場(chǎng)景不局限于云同步,。

多機(jī)房部署、GSLB和路由組件,，構(gòu)成了魅族云同步的核心架構(gòu),，也保證了高可用；而精簡(jiǎn)JSON并非新技術(shù),，我們描述了一種數(shù)據(jù)交換的思路,。歡迎大家討論交流。