zoukankan      html  css  js  c++  java
  • 分布式数据库数据从属与客户端与服务器的数据同步

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

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

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

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

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

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

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

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

    无线通信,有两个重要的特点:
    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个版本后,你可以研究一下,整个演进的过程。哪个能参数被删除了,哪些是一分为二的,哪些合并了,哪些,是你删除了又加上,然后又删除了的。

    这种情况,有没有?肯定有。

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

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

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

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

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

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

  • 相关阅读:
    What's New In Python 3.X
    CSS Transform Style
    Build Laravel Blog PigJian by PHP7 and Nginx on Ubuntu
    常见算法之2---排序数组中和为给定值的两个数字
    常见算法之1---先序遍历二叉树
    常见算法之0---冒泡排序
    UVa 341
    UVa 558
    UVa 11747
    UVa 11631
  • 原文地址:https://www.cnblogs.com/syncnavigator/p/10193529.html
Copyright © 2011-2022 走看看