分布式系统设计系列 -- 基本原理及高可用策略

其实，分布式系统说白了，就是很多机器组成的集群，靠彼此之间的网络通信，担当的角色可能不同，共同完成同一个事情的系统。如果按”实体“来划分的话，就是如下这几种：

1、 节点 -- 系统中按照协议完成计算工作的一个逻辑实体，可能是执行某些工作的进程或机器

2、 网络 -- 系统的数据传输通道，用来彼此通信。通信是具有方向性的。

3、 存储 -- 系统中持久化数据的数据库或者文件存储。

如图

众所周知，在unix/linux/mac(类Unix)环境下，两个机器通信，最常用的就是通过socket连接对方。传输数据的话，无非就是调用write()这个系统调用，把一段内存缓冲区发出去。但是可以进一步想一下，write()之后能确认对方收到了这些数据吗？

答案肯定是不能，原因就是发送数据需要走内核->网卡->链路->对端网卡->内核，这一路径太长了，所以只能是异步操作。write()把数据写入内核缓冲区之后就返回到应用层了，具体后面何时发送、怎么发送、TCP怎么做滑动窗口、流控都是tcp/ip协议栈内核的事情了。

所以在应用层，能确认对方受到了消息只能是对方应用返回数据，逻辑确认了这次发送才认为是成功的。 这就却别与单系统编程，大部分系统调用、库调用只要返回了就说明已经确认完成了。

教科书上明确写明了互联网是不可靠的，TCP实现了可靠传输。何来“不可靠”呢？先来看一下网络交互的例子，有A、B两个节点，之间通过TCP连接，现在A、B都想确认自己发出的任何一条消息都能被对方接收并反馈，于是开始了如下操作：

A->B发送数据，然后A需要等待B收到数据的确认，B收到数据后发送确认消息给A，然后B需要等待A收到数据的确认，A收到B的数据确认消息后再次发送确认消息给B，然后A又去需要等待B收到的确认。。。 死循环了！！

在单系统编程中，我们对系统状态是非常可控的。比如函数调用、逻辑运算，要么成功，要么失败，因为这些操作被框在一个机器内部，cpu/总线/内存都是可以快速得到反馈的。开发者可以针对这两个状态很明确的做出程序上的判断和后续的操作。

而在分布式的网络环境下，这就变得微妙了。比如一次rpc、http调用，可能成功、失败，还有可能是“超时”，这就比前者的状态多了一个不可控因素，导致后面的代码不是很容易做出判断。试想一下，用A用支付宝向B转了一大笔钱，当他按下“确认”后，界面上有个圈在转啊转，然后显示请求超时了，然后A就抓狂了，不知道到底钱转没转过去，开始确认自己的账户、确认B的账户、打电话找客服等等。

所以分布式环境下， 我们的其实要时时刻刻考虑面对这种不可控的“第三状态”设计开发，这也是挑战之一 。

早些时候，国外的大牛已经证明 了CAP三者是不能兼得 ，很多实践也证明了。

本人就不挑战权威了，感兴趣的同学可以自己Google。本人以自己的观点总结了一下：

一致性

描述当前所有节点存储数据的统一模型，分为强一致性和弱一致性：

强一致性描述了所有节点的数据高度一致，无论从哪个节点读取，都是一样的 。无需担心同一时刻会获得不同的数据。是级别最高的，实现的代价比较高

如图：

弱一致性又分为单调一致性和最终一致性：

1、 单调一致性强调数据是按照时间的新旧，单调向最新的数据靠近，不会回退 ，如：

数据存在三个版本v1->v2->v3，获取只能向v3靠近(如取到的是v2，就不可能再次获得v1)

2、 最终一致性强调数据经过一个时间窗口之后，只要多尝试几次，最终的状态是一致的 ，是最新的数据

如图：

强一致性的场景，就好像交易系统，存取钱的+/-操作必须是马上一致的，否则会令很多人误解。

弱一致性的场景，大部分就像web互联网的模式，比如发了一条微博，改了某些配置，可能不会马上生效，但刷新几次后就可以看到了，其实弱一致性就是在系统上通过业务可接受的方式换取了一些系统的低复杂度和可用性。

  可用性

    保证系统的正常可运行性，在请求方看来，只要发送了一个请求，就可以得到恢复无论成功还是失败（不会超时）!

分区容忍性

  在系统某些节点或网络有异常的情况下，系统依旧可以继续服务。

    这通常是有负载均衡和副本来支撑的。例如计算模块异常可通过负载均衡引流到其他平行节点，存储模块通过其他几点上的副本来对外提供服务。

  扩展性

    扩展性是融合在CAP里面的特性，我觉得此处可以单独讲一下。扩展性直接影响了分布式系统的好坏，系统开发初期不可能把系统的容量、峰值都考虑到，后期肯定牵扯到扩容，而如何做到快而不太影响业务的扩容策略，也是需要考虑的。(后面在介绍数据分布时会着重讨论这个问题)

  心跳顾名思义，就是以固定的频率向其他节点汇报当前节点状态的方式。收到心跳，一般可以认为一个节点和现在的网络拓扑是良好的。当然，心跳汇报时，一般也会携带一些附加的状态、元数据信息，以便管理。如下图：

  但心跳不是万能的，收到心跳可以确认ok，但是收不到心跳却不能确认节点不存在或者挂掉了，因为可能是网络原因倒是链路不通但是节点依旧在工作。

  所以切记 ，”心跳“只能告诉你正常的状态是ok，它不能发现节点是否真的死亡，有可能还在继续服务。(后面会介绍一种可靠的方式 -- Lease机制)

  系统模型这方面，无非就是两种：

  中心节点，例如mysql的MSS单主双从、MongDB Master、HDFS NameNode、MapReduce JobTracker等，有1个或几个节点充当整个系统的核心元数据及节点管理工作，其他节点都和中心节点交互。这种方式的好处显而易见， 数据和管理高度统一集中在一个地方，容易聚合，就像领导者一样，其他人都服从就好。简单可行。

但是缺点是模块高度集中，容易形成性能瓶颈，并且如果出现异常，就像群龙无首一样。

  基本的理论和策略简单介绍这么多，后面本人会从工程的角度，细化说一下”数据分布“、"副本控制"和"高可用协议"

  在分布式系统中，无论是计算还是存储，处理的对象都是数据，数据不存在于一台机器或进程中，这就牵扯到如何多机均匀分发数据的问题，此小结主要讨论"哈希取模"，”一致性哈希“，”范围表划分“，”数据块划分“

    哈希方式是最常见的数据分布方式，实现方式是通过可以描述记录的业务的id或key(比如用户 id)，通过Hash函数的计算求余。余数作为处理该数据的服务器索引编号处理。如图：

    这样的好处是只需要通过计算就可以映射出数据和处理节点的关系，不需要存储映射。难点就是如果id分布不均匀可能出现计算、存储倾斜的问题，在某个节点上分布过重。并且当处理节点宕机时，这种”硬哈希“的方式会直接导致部分数据异常，还有扩容非常困难，原来的映射关系全部发生变更。

  一致性哈希 -- Consistent Hash 是使用一个哈希函数计算数据或数据特征的哈希值，令该哈希函数的输出值域为一个封闭的环，最大值+1=最小值。将节点随机分布到这个环上，每个节点负责处理从自己开始顺

  时针至下一个节点的全部哈希值域上的数据，如图：

################################################3

  有些时候业务的数据id或key分布不是很均匀，并且读写也会呈现聚集的方式。比如某些id的数据量特别大，这时候可以将数据按Group划分，从业务角度划分比如id为0~10000，已知8000以上的id可能访问量特别大，那么分布可以划分为[[0~8000],[8000~9000],[9000~1000]]。将小访问量的聚集在一起。

  这样可以根据真实场景按需划分，缺点是由于这些信息不能通过计算获取，需要引入一个模块存储这些映射信息。这就增加了模块依赖，可能会有性能和可用性的额外代价。

  许多文件系统经常采用类似设计，将数据按固定块大小(比如HDFS的64MB)，将数据分为一个个大小固定的块，然后这些块均匀的分布在各个节点，这种做法也需要外部节点来存储映射关系。

  由于与具体的数据内容无关，按数据量分布数据的方式一般没有数据倾斜的问题，数据总是被均匀切分并分布到集群中。当集群需要重新负载均衡时，只需通过迁移数据块即可完成。

  如图：

  大概说了一下数据分布的具体实施，后面根据这些分布，看看工程中各个节点间如何相互配合、管理，一起对外服务。

paxos很多人都听说过了，这是唯一一个被认可的在工程中证实的强一致性、高可用的去中心化分布式协议。

虽然论文里提到的概念比较复杂，但基本流程不难理解。本人能力有限，这里只简单的阐述一下基本原理：

Paxos 协议中，有三类角色：

Proposer：Proposer 可以有多个，Proposer 提出议案，此处定义为value。不同的 Proposer 可以提出不同的甚至矛盾的 value，例如某个 Proposer 提议“将变量a设置为x1” ，另一个 Proposer 提议“将变量a设置为x2” ，但对同一轮 Paxos过程，最多只有一个 value 被批准。

Acceptor： 批准者。 Acceptor 有 N 个， Proposer 提出的 value 必须获得超过半数(N/2+1)的 Acceptor批准后才能通过。Acceptor 之间对等独立。

Learner：学习者。Learner 学习被批准的 value。所谓学习就是通过读取各个 Proposer 对 value的选择结果， 如果某个 value 被超过半数 Proposer 通过， 则 Learner 学习到了这个 value。从而学习者需要至少读取 N/2+1 个 Accpetor，至多读取 N 个 Acceptor 的结果后，能学习到一个通过的 value。

paxos在开源界里比较好的实现就是zookeeper(类似Google chubby)，zookeeper牺牲了分区容忍性，在一半节点宕机情况下，zookeeper就不可用了。可以提供中心化配置管理下发、分布式锁、选主等消息队列等功能。其中前两者依靠了Lease机制来实现节点存活感知和网络异常检测。

Lease英文含义是”租期“、”承诺“。在分布式环境中，此机制描述为：

Lease 是由授权者授予的在一段时间内的承诺。授权者一旦发出 lease，则无论接受方是否收到，也无论后续接收方处于何种状态，只要 lease 不过期，授权者一定遵守承诺，按承诺的时间、内容执行。接收方在有效期内可以使用颁发者的承诺，只要 lease 过期，接

收方放弃授权，不再继续执行，要重新申请Lease。

如图：

Lease用法举例1：

现有一个类似DNS服务的系统，数据的规律是改动很少，大量的读操作。客户端从服务端获取数据，如果每次都去服务器查询，则量比较大。可以把数据缓存在本地，当数据有变动的时候重新拉取。现在服务器以lease的形式，把数据和lease一同推送给客户端，在lease中存放承诺该数据的不变的时间，然后客户端就可以一直放心的使用这些数据(因为这些数据在服务器不会发生变更) 。如果有客户端修改了数据，则把这些数据推送给服务器，服务器会阻塞一直到已发布的所有lease都已经超时用完，然后后面发送数据和lease时，更新现在的数据 。

这里有个优化可以做，当服务器收到数据更新需要等所有已经下发的lease超时的这段时间，可以直接发送让数据和lease失效的指令到客户端，减小服务器等待时间，如果不是所有的lease都失效成功，则退化为前面的等待方案(概率小)。

Lease用法举例2：

现有一个系统，有三个角色，选主模块Manager，唯一的Master，和其他salver节点。slaver都向Maganer注册自己，并由manager选出唯一的Master节点并告知其他slaver节点。当网络出现异常时，可能是Master和Manager之间的链路断了，Master认为Master已经死掉了，则会再选出一个Master，但是原来的Master对其他网络链路可能都还是正常的，原来的Master认为自己还是主节点，继续服务。这时候系统中就出现了”双主“，俗称”脑裂“。

解决这个问题的方式可以通过Lease，来规定节点可以当Master的时间，如果没有可用的Lease，则自动退化为Slaver。 如果出现”双主“，原Master会因为Lease到期而放弃当Master，退化为Slaver，恢复了一个Master的情况。