前言一年前我对Zookeeper做了一些相关的总结，现在我们重新捡起来，把一些前因后果说清楚。1.分布式系统与Zookeeper的关系1.1中心化服务我们先从服务部署架构的开发说起。其实无非就是集中式和分布式。集中意味着我用一台机器处理所有事情。分布式是多台服务器共同完成的。所以一开始，我们一般都是从一台服务器开始，部署我们的服务。然后是一些老套路。在Tomcat上部署Web应用，并开放8080端口提供服务，然后再开放一个它需要的数据库服务。提供端口3306。它的优点是结构、部署、项目架构都比较简单。然后根据业务的发展进行扩充。扩展也可以分为两种方式，一种是横向扩展，一种是纵向扩展。既然一台服务器搞不定，要么提高这台服务器的性能，要么多用几台服务器一起用。不过想想也不是个人会乖乖安排服务器的。这台机器一挂，就全部挂了。而且，主机的采购，以及研发和维护人员，都需要大量资金。这里给大家扩展一下“摩尔定律”。简单来说，我花了两倍的钱，却买不到两倍的性能。但是横向扩展就不一样了。一个人打不过，几个人一起打得过？1.2GototheIOEcampaign，阿里巴巴的口号。具体来说就是IBM小型机、Oracle数据库、EMC的高端存储，有兴趣的也可以了解一下。因为当时面临的问题是，如果企业需要增加单机的处理能力，成本会很高，性价比会极低。我也整天怕这个怕那个，一宕了整个服务就停了。渐渐地，国内多家企业联手响应，发行量开始上涨。1.3分布式服务分布式系统有其具体的定义：分布式系统是硬件或软件组件分布在不同网络计算机上，仅通过消息传递相互通信和协调的系统。所以它是一堆计算机联合起来对外提供服务，但是对于用户来说，它看起来就像一台机器在做这些事情。有很多特点，大致有以下5种：Distribution：意思是多台计算机放在不同的位置Peer：集群中的多个工作节点都是同一个东西，做着同样的工作。而且还有副本并发的概念：多台机器同时操作一条数据，可能会造成数据不一致。全局时钟：多台主机上的事件顺序会影响结果，这在分布式场景下也是一个很复杂的问题。一种故障：节点宕机，网络不好...突发事件1.4分布式场景中经常遇到的几个问题通信异常：其实是网络问题，导致多节点状态数据不一致网络隔离：这个其实就是内部各个子网正常，但是整个系统的网络不正常。导致本地数据不一致的问题节点宕机分布式三种状态：成功、失败、超时。这三种状态会导致各种问题。请求发送和结果响应都可能丢失，无法判断消息是否发送/处理成功可以通过恢复状态解决来恢复数据。异常处理原则：任何在设计阶段考虑的异常情况，必须假定在实际运行中会发生1.5衡量分布式系统的性能标准性能：主要是吞吐量、响应延迟、并发度。系统在某一时刻能够处理的数据总量通常用系统每秒处理的数据总量来衡量，而响应延迟是指完成某项功能所需要的时间。并发能力是同时完成某项功能的能力，通常用QPSAvailability衡量：面对各种异常，正确提供服务的能力。比如我们常说的5个9，就是一年之内停机时间只有5分钟。六个九是31秒。可扩展性：指通过扩大机器规模来提高系统性能的效果。一致性：文案管理，但这些标准在一方面过高，会导致另一方面变差。比如我们要实现高可用，可能需要多副本，但是在多副本的状态下，很难做到数据的一致性。那么高吞吐量下就很难做到低延迟，需要根据自己的业务场景来考虑。1.6一致性扩展强一致性：写操作完成后，读操作必须能够读到最新的数据，这在分布式场景下是很难做到的，比如Paxos算法、Quorum机制、ZAB协议。的。弱一致性：不承诺写入的值可以立即读取，也不承诺数据多久会达到一致性，但会尽量保证一定的时间级别（比如XX小时，XX分钟，XX秒稍后），数据可以达到一致的状态。它还有一个特例叫最终一致性，就是尽可能快的保证数据的一致性。但是这个到底有多快，并没有一个准确的定义。就像女票想吃炸鸡，你点了外卖，可是美团骑手，你饿了吗？骑手说不准什么时候送，只能说尽快送。这就是它的意思。因为最终一致性太弱，我们还有一些特殊情况会出现读写一致性。意味着用户在阅读自己编写的结果时，总能在第一时间看到自己更新的内容。这就像微信的朋友圈一样，微信肯定会让我们看到我们发的东西，但是朋友，你发了之后能不能马上看到，那就不好说了。还有一些单调的阅读一致性，因果一致性就不解释了，有兴趣的朋友可以自行搜索。总而言之，为了保证系统的高可用，防止单点故障带来的问题，让分布在不同节点上的副本能够正常为用户提供服务，我们的Zookeeper应运而生。可以帮助我们解决这个分布式系统中的数据一致性问题。要解决这个问题，我们需要了解分布式事务、分布式共识算法、Quorum机制、CAP和BASE理论。接下来我们慢慢展开两个。分布式事务transaction：用于单机存储系统中，保证存储系统数据状态的一致性。读起来有点费口舌吗？成功或完全失败，没有中间状态。狭义上说，就是数据库做的操作。功能也很简单，就是大家熟悉的ACID。分布式系统中的每个节点只知道自己的操作是否成功，而不知道其他节点发生了什么，这可能导致每个节点的状态不一致。因此，为了实现跨多个节点的ACID，同时保证交易的进行，需要引入一个协调器，然后每个参与交易的节点就称为参与者。典型的例程是2PC和3PC。接下来我们慢慢展开2.1什么是2PC？交易参与过程中会产生多个角色。这个我们先理解一下，协调者负责事务的发起，参与者负责事务的执行。假设上面有三个角色，分别是一个协调者和两个参与者。这时候我们需要A和B执行一个事务，要求这个事务要么同时成功，要么同时失败。2PCPhase1:Executingthetransaction此时，协调者首先会发出命令，要求参与者A和B都执行事务，但是如果不commit，更详细的说，会产生redo和undo日志。锁定资源并执行事务。但是执行完之后，直接向coordinator汇报，问，我可以提交吗？这个应该是日常写Java经常遇到的，就是之前写了很多操作，但是最后肯定会写一个Conn.commit()这样的东西，这个叫做executebutnotcommit2PCPhase2：提交事务当协调器收到第一阶段所有事务参与者（图中A、B）的反馈时简单理解为告诉协调器前面第一阶段执行成功），然后发送命令给所有参与者提交交易。如果再详细一点，就是协调者收到反馈，所有参与者都可以提交响应，然后通知参与者提交，否则回滚，所以2PC也叫两阶段提交，其实就是如此简单，分为两步，一步执行，一步提交。2PC的缺点4：性能从整个过程可以看出，明显产生了同步阻塞，每个需要操作数据库的节点都会占用数据库的资源。只有当协调器收到所有节点就绪的反馈时，事务协调器才会通知提交或回滚，参与者在执行提交或回滚操作后释放资源。2PC的四大劣势：单点故障我们刚刚知道，协调器是这个事务的核心。如果此时协调器发生故障宕机，就会造成通知无法传达给参与者的问题。例如，如果无法接收到提交或回滚，则整个事务将停止。2PC的四大缺点：数据不一致协调器会在第二阶段发送commit或rollback。但是，这并不能保证每个节点都能正常收到这条命令，所以可能会出现参与者A收到命令并提交交易，而参与者B没有收到的情况。所以网络波动是永恒的原因，你永远无法逃避这个因素。2PC的4个缺点：没有容错机制。协调器在发出提交指令之前需要收到所有节点的反馈。如果没有收到任何参与者的响应，协调器就会等待，只要有一个A节点宕机就会导致整个事务失败并回滚。2.2什么是3PC？在2PC的前提下进行了改进，将2PC中的准备阶段拆分为三个阶段：cancommit、precommit、docommit。并且引入了超时机制。一旦事务参与者在指定时间内没有收到协调器的提交或回滚命令，就会自动在本地提交，解决协调器的单点故障问题。在3PC的第一阶段，cancommit协调器首先询问：嘿，你们能做到吗？参与者根据自己的实际情况回答是或否。在3PC预提交的第二阶段，如果参与者都返回同意，协调器将向所有参与者发送预提交请求并进入准备阶段。这里的准备阶段其实就是让参与者锁定资源等待指令，然后就是事务的执行，此时和2PC一样，执行但不提交。然后等待协调员的指示。如果这时候等不及指令，过一段时间再本地提交，但是这样也会有缺点。比如协调器成功给参与者1和参与者2都发送了回滚，然后3刚好没有收到，那么3会自动提交，所以超时机制不能完全保证数据的一致性。3.分布式一致性算法3.1Paxos算法高并发（三）---Zookeeper集群搭建与leader选举如果需要了解更多，建议跳转到那篇文章。Paxos算法是LesileLamport提出的一种基于消息传递的高容错共识算法。是不是觉得很绕？没什么，我们只要知道在分布式系统中不可避免的会出现进程被kill，Message延迟，重复，丢失……一系列的问题，Paxos算法就是在这些异常情况下依然保证数据一致性的东西。那么这和Zookeeper有什么关系呢？Zookeeper有ZAB协议，但是ZAB协议底层封装了Paxos算法。3.2Paxos中的角色及与Zookeeper集群的关系Proposer：顾名思义，就是发起提案的人。接受者：他们可以投票并接受或否决提案。Learner：如果提案被半数以上的Acceptors接受，就知道这个提案被映射到Zookeeper集群，分别是leader、follower和observer。他们有点像主席、人大代表和全国人民之间的关系。就是这样的感觉。与之前的2PC、3PC相比，只需要一半的pass就可以提交。所以这种属于弱一致性，2PC和3PC属于强一致性3.3Raft算法请点此链接，相信你很快就能掌握。http://thesecretlivesofdata.com/raft/让我在这里稍微解释一下。这是PPT的形式。让我告诉你什么是Raft。这很容易理解。这里跳过前面的一些内容，直接进入这里提到的Ben话题，Raft是一种实现分布式共识算法的协议，这里假设一个节点有3种不同的状态。第一个是跟随者状态（无线线路）。第二个是候选状态（虚线）。第三个是领导者。state（实线）记住leader是从candidates中选出来的candidates。首先，我们一上来，所有节点都是follower状态。接下来，所有的follower节点都在寻找leader。当他们找不到时，他们会自发成为候选人发起投票（问别人是否同意我成为领导者），我找不到什么？那么肯定是领导挂了。这时候它会发送一个提案给其他节点投票，然后其他节点也会给它反馈，当它收到超过半数节点的反馈时，它自然会成为领导者。之后写入数据的请求会直接发送给leader，leader再广播给其他follower。这时，只要超过半数的节点返回正反馈，写入数据的事务就会被执行，然后leader向他们发送commit命令，事务执行成功。3.4ZAB协议内容高并发从无到有（四）---Zookeeper的分布式队列。多个节点写入成功）功能。主要是保证在leaderserver上提交的事务最终被所有server提交，保证只在leaderserver上提交的事务被丢弃。3.5QuorumNWR机制QuorumNWR：Quorum机制是分布式场景中常用的保证数据安全，分布式环境下实现最终一致性的一种投票算法。该算法的主要原理来自鸽巢原理。它最大的优点是不仅可以实现强一致性，还可以自定义一致性级别。鸽巢原理，又称狄利克雷抽屉原理、鸽巢原理。一种简单的表达方式是：如果有n个笼子和n+1只鸽子，所有的鸽子都关在鸽笼里，那么至少一个笼子里至少有2只鸽子。另一种是：如果有n个笼子和kn+1只鸽子，所有的鸽子都关在笼子里，那么至少一个笼子里至少有k+1只鸽子。为什么要从抽屉原理说起呢？首先，这个大家都很熟悉，也很容易理解。其次，它与Quorum机制有相似之处。抽屉原理，2个抽屉每个最多放2个苹果，现在3个苹果不管怎么放，其中一个抽屉肯定有2个苹果。然后我们改变抽屉的原理，2个抽屉中的一个放2个红苹果，另一个抽屉放2个青苹果，我们拿出3个苹果，不管怎么拿至少1个红苹果，这样也很可以理解简单。我们将红苹果视为更新后的有效数据，将青苹果视为未更新的无效数据。可以看出，我们可以在不更新所有数据（不是所有红苹果）的情况下获得有效数据。当然，我们需要读多份（取出多个苹果）。回到QuorumNWR机制，NWR到底指的是什么？N：复制节点数，即一条数据保存的副本数。W：写操作成功的节点数，即每次写入数据时成功写入的副本数。W必须小于或等于N。R：一次读操作获取最新版本数据所需的最小节点数，即每次读成功至少需要读取的副本数。总结：这三个因素决定了可用性、一致性和分区容忍度。只要保证（W+R>N），就可以读取到最新的数据，数据一致性级别可以根据读写副本数的约束完全一致！分以下三种情况进行讨论：前提，当N已经固定。W=1，R=N，WriteOnceReadAll在分布式环境下写一份，所以如果要读取最新的数据，必须读取所有节点，然后取最新版本的值。写操作是高效的，但读操作是低效的。一致性高，分区容错性差，可用性低R=1，W=N，ReadOnlyWriteAll在分布式环境下，所有节点在读取前必须同步，所以只要读取任意一个节点，就能读取到最新的数据。读操作是高效的，但是写操作是低效的。分区容错性好，一致性差，实现难度大，可用性高W=Q，R=Q其中Q=N/2+1可以简单理解为写了一半以上的节点，还有更多超过一半的节点被读取，实现了读写性能的平衡。适用于一般应用，读写性能平衡。比如N=3，W=2，R=2，分区容错、可用性、一致性是平衡的。而ZooKeeper就是这样设计的。需要补充的是，Zookeeper并不要求客户端读取超过一半的节点，所以它允许客户端读取到不是最新同步的数据，但可能性比较小。没有同步数据的节点其实很有可能连接不上client，因为不管是网络问题还是机器问题，如果leader过去不能发送数据，client肯定连接不上给它。如果客户端刚好??在同步数据的过程中发起访问，有解决办法，大家自己摸索。3.6CAP理论CAP理论：2000年7月首次提出，CAP理论告诉我们分布式系统不可能同时满足C、A、P三个要求C：一致性、强一致性、多数据在a分布式环境副本一致A:Availability，高可用性，系统提供的服务必须始终可用，对于用户的每次操作请求，总是能够在限定的时间内返回结果P:PartitionTolerance分区容错，分布式系统遇到任何网络分区故障时，仍然需要保证对外提供满足一致性和可用性的服务。由于分布式系统不能同时满足C、A、P这三个要求，所以我们要根据自己的需要来选择。弃P：最简单的极端做法是放在一个节点上，也就是只有一个数据副本，所有的读写操作都集中在一台服务器上，存在单点故障问题。放弃P也意味着放弃系统的可扩展性，所以一般情况下，分布式系统会保证P会放弃A：一旦系统遇到网络分区或其他故障，服务需要等待一段时间，而服务将在等待时间内恢复。无法正常对外提供服务，即服务不可用。放弃C：其实放弃一致性是指放弃数据的强一致性，同时保留最终一致性。数据同步需要多长时间取决于存储系统的设计。CAP只能从32中选择。因为在分布式系统中，容错P是肯定需要的，所以此时只有两种情况。网络问题导致错误返回或阻塞等待。前者牺牲一致性，后者牺牲可用性。比如HBase是为了数据的一致性，而Cassandra是为了可用性。经验总结：不要把精力浪费在设计一个同时满足CAP的分布式系统上。分区容错往往是分布式系统必须面对和解决的问题。因此，我们应该重点关注如何根据业务特点在A和C之间找到平衡点。对于单机软件，因为不考虑P，所以一定是CA类型。比如MySQL分布式软件，因为必须考虑P，所以如果不能考虑A和C，只能tradeoffA和C，比如HBase，Redis等。保证服务基本可用，并且数据终于一致了。因此，BASE理论诞生了。3.7BASE理论在大多数情况下，我们并不一定需要强一致性。一些业务可以容忍一定程度的延迟一致性。因此，为了兼顾效率，最终一致性理论BASE应运而生，由eBay的架构师提出。BASE理论全称：全称：BasiclyAvailable（基本可用）、Softstate（软状态）和Eventuallyconsistent（最终一致性）三个词组的缩写。其核心思想是：即使无法实现强一致性，各个应用也可以根据自己的业务特点采用合适的方法使系统达到最终一致性。总之一句话，做事不要走极端。BASE是CAP理论中权衡C和A的结果。不是强一致性，而是最终一致性。不高可用，但基本可用。BasicallyAvailable：基本可用是指当分布式系统出现故障时，允许失去部分可用性，即保证核心可用。比如淘宝双11，为保障系统稳定，正常下单，其他边缘服务可以暂时无法使用。目前允许一些非核心服务的停机。SoftState（软状态）：软状态是指让系统存在于一种中间状态，而中间状态不会影响系统的整体可用性。在分布式存储中，一条数据一般至少有3个副本，不同节点之间允许副本同步的延迟就是软状态的体现。通俗地说：不同节点同步数据时允许有延迟，数据同步延迟时存在的中间状态不会影响系统的整体性能。EventuallyConsistent（最终一致性）：最终一致性是指系统中的所有数据副本经过一定时间后，最终可以达到一致的状态。与弱一致性和强一致性相反，最终一致性是弱一致性的特例，它需要最终一致性而不是实时强一致性。最后，我们提到了集中式和分布式服务部署架构的优势。分析设计分布式系统中遇到的各种问题：数据一致性问题。2PC和3PC是实现的大致思路，但还是有不足之处。PaxosRaftZAB即使存在分布式网络通信异常等棘手问题，上述算法也可以实现共识议会QuorumNWR机制：R+W>N===>少数服从多数一致性和可用性的冲突问题，CAPandBASE：分布式系统必须满足P，只能在C和A之间进行交易。大部分系统都是BASE系统（基本可用+最终一致）
