老實說，眼下市面上很多產品，的確是不成熟的產品。

用過一些，給人蛋痛的感覺。

導言

分布還是集總

今天我們來探討一個非常重要的問題。
每一個程序猿都有其思想，我的思想之中的一個，就是分布式。

分布式，面對的一個問題，就數據的同步。

比方說。我們人類是分布式的，我們每一個細胞都在無時無刻與其他細腦交換數據。

而現實世界。我們的設計是什麽樣子？一般都是集總式。

首先來說，這樣的方式，與現實世界並不一致。所以。帶來的最嚴重的一個影響就是效率的問題。

自己這些年，一直在無線通信領域。

無線通信。有兩個重要的特點：

1. 無線帶寬有限，所以這些帶寬就成為重要的國家資源，所以無線通信的費用，非常高。

2. 無線通信，信號不穩定。

當然，wifi是還有一回事。但不是哪裏都能夠用wifi接入。至少如今是這樣（當然。wifi的存在，也是一個莫大的諷剌：國際電聯占用了那麽多帶寬，可真正傳的數據，可能根本不如開放給Wi-Fi的那麽一點可憐的帶寬。國際電聯。有時真是應當反思）。

基於這兩點，一個手機電的client應用程序，一定要在本地存數據。假設不能做到這樣，其本上就是個垃圾產品。浪費生命的產品。

舉個樣例。比方騰訊新聞，事實上這是一個實時性非常強的產品，但騰訊，還是非常負責地實現了全面的離線和緩存功能。這是對用戶的負責。

用戶沒有道理，在等你的軟件在後臺同步數據。這是在浪費用戶 的生命。

同步與版本號兼容

可是同步並非件簡單的工作，其實，相當復雜。並且是檢查一個架構師的架構是否合理的關鍵要點。

網上有很多討論同步的帖子。但都不是非常理想。

同步，作為一個架構人員。你首先要考慮同式的方式。進而思考版本號兼容的問題。

什麽叫版本號兼容？這麽說吧，你去理發。看一個理發師水平怎麽看？過一個星期再看他給你理的發的效果，那才是真水平。

版本號兼容，其實。是真正能體現一個復雜軟件的靈魂之處。

特別是對數據的兼容。

我為什麽總是把這四個字放在嘴邊？由於這不止是我缺的，更是我們整個民族所缺的。我們五千年文化的特點是什麽？每300年大掃除一次！每一個朝代的書，都被下個朝代燒光。

所以，我們總是在原地踏步。

然後，美其名日：新的版本號全然拋棄了舊版本號的弊端。

我告訴你，這種軟件，送我也不要——缺少一個程序猿的其本良知。

相同。一個公司，你怎麽看他強不強？你就看他的產品升級的時候，是怎麽處理用戶數據的。

比方，眼下我維護的任務之中的一個就是Pre-E公司的windchill ，PDM系統，不論你告訴我這是一家多麽強大的公司，當我聽說，它的新版本號不能從舊版本號平兼容升級，須要全然重做。我就知道，這是個不能買的軟件——windchill團隊，也是個不怎麽負責的團隊——也可能是能力問題。

那麽。版本號兼容、分布式、數據、同步，它們之間的聯系是什麽？

真的思考過的人，你自然會理解。、

你精心設計的CS系統（比方OA，流程平臺，CRM，物流，等等）。如今數據庫結構變了。

問題是，你的client那裏。有一個本地數據庫，存在屬於他的數據。

那麽，這兩個數據庫之間。怎樣處理？

當然，最簡單的辦法就是通知全部用戶：你的數據不能用了。請又一次同步。

這是一種浪費。對server的壓力。也會添加非常多。

其實。我了解過的很多系統。server的壓力，就是由於server承擔了本不須要在服務端完畢的工作。

如今的手機、PC運算能力。全然是一個小型server。

有時的確搞不懂。人們為什麽無克制地在服務端搞來搞去，而不是從分布式的思想上下功夫——事實上這也是一種民主暴政：搞服務端看起來非常專業，非常有型，工資自然高。

浪費所以總是有道理。

但。錯誤，總會有人來糾正的。

------------------------------------------

好了，我們來探討，數據同步的一些細節。

數據同步，由幾部分構成。

1. 信息的從屬。這可能是最先須要思考的。

有屬於個人的，有屬於團隊的，有公共的，有屬於BI團隊的。還有屬於管理人員。或是財務這樣的專業團隊的。

所以，第一步，須要明白界面哪些須要同步每一個個體的終端（User Equment）上.

2. 信息的唯一描寫敘述。

有了從屬，每一條信息，須要一個唯一ID。

以解決當一條信息發生改變時的記錄。服務端與client。都須要此項工作。

3. 數據結構的描寫敘述，與版本號。

為實現版本號兼容，每一個對象（或表。或樹）須要有描寫敘述（類似人類的DNA。類似數據庫的Schema）,這些描寫敘述體系，相對而言，須要固定的模式。

比方，數據庫，一定是非業務、非對象、非表的模式來存儲。

比方，能夠用OID + value的方式來存儲。

4. 數據的同步，須要兩步，第一步是檢查數據結構是否有改變，第二步才是數據的同步。

5. 註意這裏軟件的版本號升級，與數據描寫敘述的演進。是兩回事。

6. 還有一個要選擇的問題，何時同步。同步多少數據。比方。當用戶用到一個功能時，再同步，還是用戶每登上，就進行一次全同步。

這裏。須要與詳細的情況結合來考慮。最好是兩種功能，都實現。不同的情況下。使用不同的同步方式。

7. 實時上報。當兩個用戶在進行協同一時候，最好須要有實時上報的功能。這裏看以看出，為什麽，信息的從屬，和信息的唯一描寫敘述。是這同步體系的基礎。

8.容錯，當體系出現故障時，有機缺能避免掉入升級陷阱。

9.區分wifi與電信網絡的接入情況。當用戶使用的是wifi時。能夠在後臺自己主動進行全同步。

假設能實現這些。其本上就比較理想了。

平滑升級，為什麽如此重要？

幾個方面。

一個是版本號的回溯。

版本號回溯的重要性是什麽呢？

好比我們早晨醒來第一件事是什麽？回顧。

不錯，可能你沒有意識到。

我們中國人學的英語為什麽都是啞巴英語？一方面，我們沒有註意到語言的核心是動詞，還有一方面，也是根本原因。是由於我們沒有形成英語記憶。

這是母語與後天習成語言的本質區別。

版本號回溯的重要，類似於此。

比方說，你的軟件升級20個版本號後。你能夠研究一下，整個演進的過程。

哪個能參數被刪除了，哪些是一分為二的。哪些合並了。哪些，是你刪除了又加上，然後又刪除了的。

這樣的情況，有沒有？肯定有。

假設這個團隊，就你一個人。這無所謂了。

但，假設在巨大的團隊，非常可能有人在偷懶，也有可能是糊塗（但更可能是管理問題）。

這麽說吧，大團隊，有意和無意的這樣的走轉圈路的情況，層出不窮。早晨又聽研發的同事在討論。十年前的問題。相信，再過一百年，也會再出。

如今你懂了，這個版本號兼容有多重要了吧？及使不考慮client、server。也須要有這個功能。

去年維護物流的時想，開發了一個復雜的功能。須要修改很多表。把原有的數據進行處理後導入，後來。不得不開發了一個非常復雜的升級腳本來實現。

事實證明是明智的——手工升級，一個星期也能都升不上去。有了腳本，僅僅需幾分鐘。

分布式數據庫數據從屬與client與server的數據同步