分布式原理与实战（四） 以FDB为例之同步化

分布式中最为重要的一个工作就是同步化，分布式是对于多台机器的。那么同步化一定是一个重要的问题，我们先在就以问题结合我们的项目详细谈谈分布式的同步化问题。

谈到同步化问题，我们就必须从时钟上谈起，分布式系统中，是没有“全局时钟”这个概念的，或许我们就不应该假设有“同步时钟”这个东西存在。那我们如何讨论同步化问题呢？其实早在计算机出现之前，我们人类就考虑过时钟同步的问题。

“闰秒”这就是一个非常经典的例子。我们先说下何为闰秒。

闰秒，是指为保持协调世界时接近于世界时时刻，由国际计量局统一规定在年底或年中（也可能在季末）对协调世界时增加或减少1秒的调整。由于地球自转的不均匀性和长期变慢性（主要由潮汐摩擦引起的），会使世界时（民用时）和原子时之间相差超过到±0.9秒时，就把世界时向前拨1秒（负闰秒，最后一分钟为59秒）或向后拨1秒（正闰秒，最后一分钟为61秒）； 闰秒一般加在公历年末或公历六月末。
目前，全球已经进行了26次闰秒。
最近一次闰秒于北京时间2015年7月1日7时59分59秒（时钟显示07:59:60）出现。
下一次闰秒将于北京时间2017年1月1日7时59分59秒（时钟显示07:59:60）出现。

简单来说其实就是，我们造出的原子钟其实是“精确”的，但是地球的自转其实在一直的变慢，这就很麻烦，因为迟早有一天可能我们的时钟显示都中午12点了，但是太阳还没有照常升起，不符合我们人类的时间认知了，其实宇宙空间本就是一个超超超大型离散系统，本身宇宙也是没有全局时钟的。

接着我们来考察几个系统的时间控制。

GPS系统，这个系统时没有考虑闰秒的，所以美国人会定期调整时间。

网络时间协议：NTP

NTP是网络时间协议(Network Time Protocol)，它是用来同步网络中各个计算机的时间的协议。
在计算机的世界里，时间非常地重要，例如对于火箭发射这种科研活动，对时间的统一性和准确性要求就非常地高，是按照A这台计算机的时间，还是按照B这台计算机的时间？NTP就是用来解决这个问题的，NTP（Network Time Protocol，网络时间协议）是用来使网络中的各个计算机时间同步的一种协议。它的用途是把计算机的时钟同步到世界协调时UTC，其精度在局域网内可达0.1ms，在互联网上绝大多数的地方其精度可以达到1-50ms。
它可以使计算机对其服务器或时钟源（如石英钟，GPS等等）进行时间同步，它可以提供高精准度的时间校正，而且可以使用加密确认的方式来防止病毒的协议攻击。

逻辑时钟：

著名的逻辑时钟算法就是Lamport 算法。逻辑时钟只是为了确定相应的事件的执行顺序，是逻辑上的确定。逻辑时钟是（松耦合）分布式系统的特性，要求的是系统节点进展之间的相对一致性（同步）。 只有相关的系统（进程）才需要有逻辑时钟同步，同步的目的是维持事件的顺序性。除时间的基本特性（一维）外，逻辑时钟与标准时钟（物理时钟）之间没有通用意义上的明确的关系。

逻辑时钟同步的算法是有意义并且可行的，只要有以下三方面的理由：
（1）如果两个进程之间不存在相互作用，它们的同步没有意义；
（2）时钟同步不需要绝对同步，不需要所有进程在时间上完全一致，而是它们在事件的发生顺序要完全一致；
（3）逻辑时钟只关心事件的发生顺序，而不关心是否与物理时间接近。

其中包括几个基础的核心算法，这里不再赘述，他们分别是全序多播，向量时钟，强制因果有序通信。都是很简单的算法，有兴趣的自己查查就行。

现在我们来谈论下互斥问题，这里仅仅讨论几个简单的互斥问题。

1.集中式算法

选择一个主协调者，所有的资源访问请求都必须经过主协调者裁定。非常简单，但是这种算法最大的问题也很显而易见，故障点绝对的集中，如果协调者完蛋，系统就会完蛋。并且不容易区分消息的失效和失败。更何况，这也比将变成性能瓶颈。

2.非集中式算法

非集中式算法是通过把共享资源分配N次，然后采用投票的方式决策，当有一个请求需要获取资源时，直接发送请求，只要这个资源能够获取 > n/2 或者我们定一个标准，那么这个请求就是可以被允许的。但是不利的一点是，当有节点下线后，它会忘记之前投票情况，这就很麻烦，并且很难恢复，当节点数目增加一定会伴随风险增加。

3.分布式算法

分布式算法有点像下推自动机，前提是系统内所有的事情都是逻辑合理的，然后需要请求发送消息，各个进程比较自己所接受到的消息，做出合理的选择，但是这样的算法，比集中式算法，更慢，更复杂，更加的花费更高。这只是一个方向罢了，先阶段还需要创建更多的优秀算法。

4.令牌环算法

当环初始化时，进程0得到一个令牌token。该令牌绕着环运行，用点对点发送消息的方式把它从进程k传递到进程k+1(以环大小为模)。进程从它邻近的进程得到令牌后，检查自己是否要进入临界区。如果自己要进入临界区，那么它就进入临界区，做它要做的工作，然后离开临界区。在该进程退出临界区后，它沿着环继续传递令牌。不允许使用同一个令牌进入另一个临界区。如果一个进程得到了邻近进程传来的令牌，但是它并不想进入临界区，那么它只是将令牌沿环往下传递。

优点：不会发生饿死现象，那么最差的情况是等待其他所有进程都进入这个临界区然后再从中退出后它再进去。
缺点：如果令牌丢失了，那么它必须重新生成令牌，检测令牌丢失是很困难的；如果有进程崩溃，该算法也会出现麻烦，但是恢复起来比其他算法容易。

四种算法的比较：

进入前的延时                          失败可能

集中式：                        2                                              协作者崩溃

非集中式：                    2m                                           会发生饥饿，效率低

分布式：                       2(n-1)                                       任何进程崩溃

令牌环：                        0~n-1                                       令牌环丢失

关于FDB以及提同步化的几个问题。

我们现在来看看我们的FDB 是如何做的，关于同步化问题。

首先为我们自上而下考虑下我们的项目到底有多少需要考虑同步化的问题与地方。

第一模块：分布式链接处理模块，这个模块我们使用了DHT的方法，并不牵扯同步化的问题。

第二模块：数据库数据处理模块，这里需要同步，一个是和MYSQL数据库交互持久化的模块，这里可以通过定时刷新，或者干脆强一致性的方式解决。这里的同步还限制在本机上不难处理。

第三模块：主备之间的同步，这是我们最需要考虑的事情，我们现在采用的是三节点的高可用模型，但是并没有使用主从模型做读写分离。

总体来说，数据的同步化好解决，但是数据属性的同步化需要考虑。

 

查看原文：http://zmrlinux.com/2016/09/24/%e5%88%86%e5%b8%83%e5%bc%8f%e5%8e%9f%e7%90%86%e4%b8%8e%e5%ae%9e%e6%88%98%ef%bc%88%e5%9b%9b%ef%bc%89-%e4%bb%a5fdb%e4%b8%ba%e4%be%8b%e4%b9%8b%e5%90%8c%e6%ad%a5%e5%8c%96/