通过zookeeper浅谈一致性算法

CAP定理介绍

CAP 定理指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

通俗来说：

一致性（C）：当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态。

可用性（A）：对于用户的每一个请求，系统总是可以在有限的时间内对用户做出响应。

分区容错性（P）：分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一致性或可用性的服务。

对于分布式系统来说，网络🛜环境是相对不可控制的，出现网络分区是不可避免的。网络分区的出现很可能就会带来脑裂问题（例如：机房之间的网络通信出现故障），这就会导致集群分裂成两个或多个，它们都认为只有自己没有崩溃，都可以独立运行。对于zk这分布式协调系统来说，数据的一致性是基本的要求，它需要保证在任何时刻访问都能得到一致性的数据结果，所以分区容错性是需要保证的。zk默认是通过“过半机制”防止脑裂的。

不难发现，一致性和可用性是不能同时保证的。原因：数据同步是需要时间的，在同步的期间，若允许client访问，则client从不同节点读取到的数据就可能是不同的（牺牲了一致性保证了可用性）。若不允许client访问，则client在同步期间无法获取服务，但是在同步后无论访问哪个节点读取的数据都会是一样的（牺牲了可用性从而保证一致性）。

网络分区是指在分布式系统中，由于网络故障、节点故障等原因，导致集群中的节点被分割成多个独立的子集，每个子集之间无法进行通信的现象。网络分区会导致分布式系统的可用性和一致性受到影响，因此需要采取一定的措施来避免或解决网络分区问题。

BASE 理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的。

BASE 理论的核心思想是：即使无法做到强一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

1.基本可用：分布式系统出现不可预知故障的时候，允许损失部分可用性。体现在：响应时间上的损失 和 功能上的损失（服务降级）。

2.软状态：允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的整体可用性。例如允许zk之间的数据同步存在一定的数据延迟。

3.最终一致性：强调所有的数据副本在经过一段时间后，最终能够达到一个一致性的状态。

从zk的角度谈cp

在zk集群中，leader节点宕机后，整个集群会有一段时间是不能被访问的，后面又可以访问了。在这段不可访问的时间内，zk集群是在做leader选举，期间是不接受客户端的读写操作的。也可以这么理解在leader选举期间，zk集群是处于瘫痪期间的，同步完毕后读取到的数据是一致性的数据。满足了一致性，牺牲了一定的可用性。

分布式一致性

通俗来说，分布式事务是将多个操作组成一个事务来完成，并且这多个操作要么一起成功，要么一起失败。这个很有名的一个处理分布式事务的组件就是阿里的seats。一般分布式一致性是由分布式事务实现的，需要保证客户端从分布式系统中的每一个server节点获取的数据，在某一段时间是可以保证是一致的（最终一致性）。

2PC算法：每一个server对本地事务的确认，需要经历两个阶段，prepare阶段和commit阶段。在MySQL中通过2pc保证Redo和Binlog的保持一致。1）当事务提交时InnoDB存储引擎进行prepare操作，将数据写入到binglog日志中。2）InnoDB存储引擎将事务写入到Redo Log文件中。在seata的事务模式中XA，AT，TCC都是2PC的。

3PC算法：在2PC的基础上新增一个Accept阶段（提交指令阶段）。该阶段主要是事务协调者（TC）向资源管理者（RM）发送accept指令，RM收到指令后判断是否可以完成自己的事物并且将判断结果给TC。

Paxos算法：该算法要解决的问题是在分布式系统中如何就某个决议达成一致。ZAB（Zookeeper Atomic Broadcast）协议是Paxos算法的一种工业实现。在zookeeper中使用一个单一主进程来接收并处理客户端的所有请求（写请求）,当数据发生变更，ZAB采用原子广播协议，以事务提案 Proposal 的形式广播到所有的副本进程上并且为每一个事务分配一个全局递增的编号Xid. 客户端连接到一个z k集群后，如果是读请求,那么当前节点就会根据自己保存的数据对其进行相应数据返回。如果是写请求并且不是leader节点，那么当前节点就会首先将请求转发给leader节点，leader节点以提案的方式广播该写操作，只有超过过半的节点同意该写操作该写请求才会被提交，然后leader广播给所有的follower节点，通知它们同步数据。