从Paxos到Zookeeper（一）

前言

       随着计算器系统规模变得越来越大，计算机系统正在经历一场前所未有的从集中式到分布式架构的变革，相信有过分布式开发经验的都能明白其痛点--分布式一致性。Zookeeper的出现帮助很多系统在一定程度上解决了这个难点，使用也非常简单，作为分布式一致性问题的工业解决方案，paxos是理论算法，其中zab，raft和众多开源算法是对paxos的工业级实现。这本书是本人很早就想看的书了，在刚开始使用zookeeper时就听过这一句话：Zookeeper的强大在于Paxos，而Paxos算法的难理解与算法的知名度一样令人敬仰，接下来这段时间我们一起从浅到深的学习一下Paxos以及在Zookeeper中的应用。

1、从ACID到CAP/BASE

      首先还是介绍一些基础的理论知识，从理论的角度来理解所谓分布式的最大痛点。

1.1 ACID

      ACID即事务的特性，每次面试都会问的，这里就只做简单介绍了，即原子性（Atomicity）、一致性（Consistency）、隔离性(Isolation)和持久性(Durability)，其中，事务的隔离级别：读未提交（允许脏读）、读已提交（允许不可重复读）、可重复读（允许幻读）和串行化，从隔离级别回头看看为什么需要事务，这里不仅仅是指狭义的数据库事务，包括系统中任何一系列的对数据进行访问以及更新的操作。一方面，在并发访问时，事务可以在各个应用程序之间提供一个隔离方法，防止相互干扰；第二，事务为数据库操作序列提供一个从失败恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。

1.2 CAP和BASE

     随着分布式计算的发展，事务在分布式计算领域中也得到了广泛的应用。在单机数据库中，我们很容易能够实现一套满足ACID特性的事务处理系统，现在各大框架对事务的支持也十分健壮，但是在分布式数据库中，数据分散在不同的机器上，如何对这些数据进行分布式的事务处理具有非常大的挑战，这也是前面所说的分布式的最大痛点---分布式数据一致性！

      为什么会出现不一致的问题呢？这是分布式系统的特点，带来优势也同时带来劣势，为了性能以及可用性，分布式系统都会有多个节点存储数据，不同的数据节点之间由于网络延时等原因很容易产生数据不一致的情况。复制机制的目的是为了保证数据的一致性。但是数据复制面临的主要难题也是如何保证多个副本之间的数据一致性。
对分布式数据一致性简单的解释就是：当对集群中一个副本数据进行更新的同时，必须确保能够同步更新到其他副本，否则不同副本之间的数据将不再一致。举个例子来说就是：当客户端C1将系统中的一个值K由V1更新为V2，但是客户端C2读的是另一个还没有同步更新的副本，K的值依然是V1,这就导致了数据的不一致性。其中，常见的就是主从数据库之间的复制延时问题，这是传统的ACID模型无法保障的，于是便有了CAP和BASE。

      CAP

        CAP即一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求，但是这个理论在提出的同时，也证明了这三项最多同时满足两项。

• 一