老实说，眼下市面上很多产品，的确是不成熟的产品。

用过一些，给人蛋痛的感觉。

导言

分布还是集总

今天我们来探讨一个非常重要的问题。
每一个程序猿都有其思想，我的思想之中的一个，就是分布式。

分布式，面对的一个问题，就数据的同步。

比方说。我们人类是分布式的，我们每一个细胞都在无时无刻与其他细脑交换数据。

而现实世界。我们的设计是什么样子？一般都是集总式。

首先来说，这样的方式，与现实世界并不一致。所以。带来的最严重的一个影响就是效率的问题。

自己这些年，一直在无线通信领域。

无线通信。有两个重要的特点：

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。也须要有这个功能。

去年维护物流的时想，开发了一个复杂的功能。须要修改很多表。把原有的数据进行处理后导入，后来。不得不开发了一个非常复杂的升级脚本来实现。

事实证明是明智的——手工升级，一个星期也能都升不上去。有了脚本，仅仅需几分钟。