分布式数据库集群中间件------分布式系统特性_MySQL

上一节我们通过原始村落村民的例子来说明分布式系统中的三个要素的概念。本节，我将介绍分布式系统中应该解决的几个特性。

CAP

1. Consistency（一致性）

2. Availability（可用性）

3. Partition tolarance （分区容错性）

一致性是说，需要两个或者多个节点共同完成一个业务逻辑，这个业务逻辑不可以将中间状态存储成永久的状态。换句话说，这个业务逻辑应该要么在每个节点都成功，要么在每个节点都不成功。举个例子，媒婆想促成一对姻缘，就先要到男女双方家里去做工作。只要双方有一家不同意这门亲事，整件事情就需要都作废。如果都同意这门亲事，媒婆的才能够成功的促成这个姻缘。假设，男方家里同意了，但是媒婆还没有问过女方，媒婆一定不会告诉男方说，”你现在就布置新房吧“，而是会说“我再去女方家里问问这个事”。等到了女方家里问这个事，若是女方家里同意，则媒婆就会让双方准备结婚。如果女方不同意，那么媒婆就还需要到男方家里把这个事说了，放弃这门婚事。

可用性是说，不管遇到了什么样的状况，当我发送给你一条消息，你是否能够给我回复一条，不管是成功或者失败。这就像你给别人写信，若是收信人有个好习惯，每一封信件都回复给你，你就会觉得这样的人很靠谱，系统也是一样。

分区容错性是说，系统能够继续工作，即使是数据丢失或者是部分失败。每个节点都有属于自己的元数据信息或者集群的需要持久化的信息，但是系统是存在风险的，每一个节点都可能会因为特殊的情形而造成数据的丢失，那么当某一个节点数据丢失，集群能否正确的将数据恢复，并且正常提供服务就是分区容错性。（这里要有一个思考，那就是如果有两个节点同时出错呢，如果有三个呢，如果有n个呢）。

曾经有外国大牛证明过，说过上述三者不能同时兼备，怎么取舍，怎么权衡是我们需要重视的。

以下为翻译文章，主要讲述CAP之间的组合以及适宜的场景

http://robertgreiner.com/2014/08/cap-theorem-revisited/

Consistency：读请求能够保证返回最新的数据。

Availability：一个没有挂掉的节点能够在有限的时间内返回一个合理的结果。

Partition Tolerance：当节点之间的网络分裂，系统依然能够提供服务。（The system will continue to function when network partitions occur）

在进一步解释之前，我们需要将一件事情先说明。面向对象编程！=网络编程。在编程的时候，我们假设的共享内存的几个程序，很可能在网络不稳定的情况下被分割成一个或者多个区域，也就是这几个程序可能数据不一致。在分布式计算中，最不应该的事情是认为网络是可靠的。网络绝不是可靠的。网络经常的会不可用，拥塞。网络问题经常在你不经意之间就会出错。由于网络的不稳定性，在分布式系统中你必须要分区可容错。下面就介绍在分区分裂的情况下，你的选择是更加偏向Availability还是更加偏向Consistency。

CP：Consistency/Partition Tolerance- 在等待一个节点返回信息的时候，有可能会出错。系统当然可以返回错误，也可以不返回错误，到另外一个副本工作。这时候需要根据业务逻辑来判断，是需要选择Availability还是Consistency。如果系统一定需要显示的数据需要是最新的已经提交的数据，那么就选择Consistency模式。这时，就需要报错而不是切换到副本。如下所示：

AP：Availability/Partition Tolerance - 在这种模式下，你返回的最新的数据很可能对于用户来说也是陈旧的，选择Availability而不是Consistency取决于你的业务需求，你的业务需要是更加注重于稳定，能够容忍少量的不一致。系统希望的是运行，而不是一味的报错。如下图所示：