分布式数据库数据从属与客户端与服务器的数据同步

老实说，目前市面上许多产品，的确是不成熟的产品。

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

导言

分布还是集总

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

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

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

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

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

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

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

1. 无线带宽有限，所以这些带宽就成为重要的国家资源，所以无线通信的费用，很高。

2. 无线通信，信号不稳定。

当然，wifi是另一回事，但不是哪里都可以用wifi接入。至少现在是这样（当然，wifi的存在，也是一个莫大的讽剌：国际电联占用了那么多带宽，可真正传的数据，可能根本不如开放给Wi-Fi的那么一点可怜的带宽。国际电联，有时真是应当反思）。

基于这两点，一个手机电的客户端应用程序，一定要在本地存数据。如果不能做到这样，其本上就是个垃圾产品。浪费生命的产品。

举个例子，比如腾讯新闻，其实这是一个实时性很强的产品，但腾讯，还是非常负责地实现了全面的离线和缓存功能。这是对用户的负责。

用户没有道理，在等你的软件在后台同步数据。这是在浪费用户 的生命。

同步与版本兼容

但是同步并不是件简单的工作，事实上，相当复杂，而且是检查一个架构师的架构是否合理的关键要点。

网上有许多讨论同步的帖子。但都不是很理想。

同步，作为一个架构人员，你首先要考虑同式的方式。进而思考版本兼容的问题。

什么叫版本兼容？这么说吧，你去理发，看一个理发师水平怎么看？过一个星期再看他给你理的发的效果，那才是真水平。

版本兼容，事实上，是真正能体现一个复杂软件的灵魂之处。

特别是对数据的兼容。

我为什么总是把这四个字放在嘴边？因为这不止是我缺的，更是我们整个民族所缺的。我们五千年文化的特点是什么？每300年大扫除一次！每个朝代的书，都被下个朝代烧光。所以，我们总是在原地踏步。

然后，美其名日：新的版本完全抛弃了旧版本的弊端。

我告诉你，这样的软件，送我也不要——缺少一个程序员的其本良知。

同样，一个公司，你怎么看他强不强？你就看他的产品升级的时候，是怎么处理用户数据的。

比如，目前我维护的任务之一就是Pre-E公司的windchill ，PDM系统，不论你告诉我这是一家多么强大的公司，当我听说，它的新版本不能从旧版本平兼容升级，需要完全重做，我就知道，这是个不能买的软件——windchill团队，也是个不怎么负责的团队——也可能是能力问题。

那么，版本兼容、分布式、数据、同步，它们之间的联系是什么？

真的思考过的人，你自然会理解。、

你精心设计的CS系统（比如OA，流程平台，CRM，物流，等等），现在数据库结构变了。

问题是，你的客户端那里，有一个本地数据库，存在属于他的数据。

那么，这两个数据库之间，如何处理？

当然，最简单的办法就是通知所有用户：你的数据不能用了，请重新同步。

这是一种浪费。对服务器的压力，也会增加很多。

事实上，我了解过的许多系统，服务器的压力，就是因为服务器承担了本不需要在服务端完成的工作。

现在的手机、PC运算能力，完全是一个小型服务器。

有时的确搞不懂，人们为什么无节制地在服务端搞来搞去，而不是从分布式的思想上下功夫——其实这也是一种民主暴政：搞服务端看起来很专业，很有型，工资自然高。

浪费所以总是有道理。

但，错误，总会有人来纠正的。

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

好了，我们来探讨，数据同步的一些细节。

数据同步，由几部分构成。

1. 信息的从属。这可能是最先需要思考的。

有属于个人的，有属于团队的，有公共的，有属于BI团队的，还有属于管理人员，或是财务这种专业团队的。

所以，第一步，需要明确界面哪些需要同步每个个体的终端（User Equment）上.

2. 信息的唯一描述。

有了从属，每一条信息，需要一个唯一ID。

以解决当一条信息发生改变时的记录。服务端与客户端，都需要此项工作。

3. 数据结构的描述，与版本。

为实现版本兼容，每个对象（或表，或树）需要有描述（类似人类的DNA，类似数据库的Schema）,这些描述体系，相对而言，需要固定的模式。

比如，数据库，一定是非业务、非对象、非表的模式来存储。比如，可以用OID + value的方式来存储。

4. 数据的同步，需要两步，第一步是检查数据结构是否有改变，第二步才是数据的同步。

5. 注意这里软件的版本升级，与数据描述的演进，是两回事。

6. 另一个要选择的问题，何时同步，同步多少数据。比如，当用户用到一个功能时，再同步，还是用户每登上，就进行一次全同步。

这里，需要与具体的情况结合来考虑。最好是两种功能，都实现，不同的情况下，使用不同的同步方式。

7. 实时上报。当两个用户在进行协同时，最好需要有实时上报的功能。这里看以看出，为什么，信息的从属，和信息的唯一描述，是这同步体系的基础。

8.容错，当体系出现问题时，有机缺能避免掉入升级陷阱。

9.区分wifi与电信网络的接入情况。当用户使用的是wifi时，可以在后台自动进行全同步。

如果能实现这些，其本上就比较理想了。

平滑升级，为什么如此重要？

几个方面。

一个是版本的回溯。

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

好比我们早晨醒来第一件事是什么？回忆。不错，可能你没有意识到。

我们中国人学的英语为什么都是哑巴英语？一方面，我们没有注意到语言的核心是动词，另一方面，也是根本原因，是因为我们没有形成英语记忆。

这是母语与后天习成语言的本质差别。

版本回溯的重要，类似于此。

比如说，你的软件升级20个版本后，你可以研究一下，整个演进的过程。哪个能参数被删除了，哪些是一分为二的，哪些合并了，哪些，是你删除了又加上，然后又删除了的。

这种情况，有没有？肯定有。

如果这个团队，就你一个人，这无所谓了。

但，如果在巨大的团队，很可能有人在偷懒，也有可能是糊涂（但更可能是管理问题）。

这么说吧，大团队，有意和无意的这种走转圈路的情况，层出不穷。早晨又听研发的同事在讨论，十年前的问题。相信，再过一百年，也会再出。

现在你懂了，这个版本兼容有多重要了吧？及使不考虑客户端、服务器，也需要有这个功能。

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

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