一、前言

　　Paxos在分布式系统中地位是不容置疑的，现代分布式系统的实现基本都直接或者间接依赖于Paxos算法。不过Paxos算法有着固有的缺陷：原始的BasicPaxos原理还是比较容易理解的，整个算法无非被分为Prepare和Accept两个阶段，但是要把这种算法工程化实现，各个节点的角色是对等的，系统的效率(可用性)将会非常的低，所以常用的也就是MultiPaxos变体版本以提高性能，这也就隐含的包含了leader的概念了，然后MultiPaxos还允许一个提交窗口，窗口中允许发起多个提案，但是这种情况下考虑到服务器随时可能崩溃的情况，算法将会变得极端复杂。Lamport爷爷就此也是简明说了几句不清不楚的优化，没有具体的实现细节，算是挖了一个巨坑吧。所以说了解BasicPaxos只是一个皮毛，将其推送到工程化可不是件容易的事情。
　　Raft算法是斯坦福两位博士生提出的分布式一致性系统，从其论文的题目《In Search of an Understandable Consensus Algorithm》可以看出，作者以Paxos过于复杂为出发点，力求得到一个正常智商的大学生都能看懂，且工程上也容易实现的分布式系统一致性算法为目标。Raft算法借鉴了Paxos的原理，但最大不同是显式强化了Leader这个角色(虽然很多Paxos算法的实现也会产生Leader角色，但这不是Paxos算法本身所必须的)，并添加了各种约束条件(比如日志的连续性)，让算法更加容易理解和实现。虽然吾等草根屁民尚且不能从理论上审视这个算法的正确性，不过短短时间内美国很多著名大学分布式教学都将Raft算法列入教学课程，且基于Raft协议的项目也越来越多，这些事实已经足以证明一切了。
　　学习Raft算法，一篇普通论文和一篇博士学位论文算是不得不读的经典，而前者网上发现了翻译好的中文版本，简单对比了一下原文，发现翻译的质量还是挺高的，很值得参考，但有些原理中文理解困难的话可以对比英文方便理解。作为正规论文，按照论文八股需求难免有些啰嗦拖沓，本文就是按照前面论文阅读摘抄一些重点要点出来，而后面那篇两百多页的博士论文，后面可以慢慢评鉴一下作为补充吧，当然最好的方式还是——一言不合就读代码，毕竟作者说就两千多行！
　　还有，论文对状态机的描述比较的好，算是归纳了分布式系统的本质——复制状态机的基础是通过复制日志来实现的：当每个副本的初始状态相同，只要保证各个副本得到的日志都是顺序且一致的，那么按照相同的顺序执行这些日志中的指令，所有副本必然可以进行相同的状态转移得到相同的结果。所以分布式系统解决的根本问题，就是一致性问题，具体就是日志一致性问题，在这个基础上，上层就可以方便实现分布式日志、分布式数据库(bin log)、分布式存储等具体业务了。

二、Raft算法

2.1 Raft算法基础

　　Raft算法保证和Paxos算法具有相同的安全性，当集群中绝大多数服务器是正常的，则集群即可以正常工作，比如5个节点的集群，允许2个节点的失效。Raft算共有三种角色、需要处理三个问题，三个角色分别是Leader、Candidate、Follower，三个问题是Leader选举、日志复制和安全性，三个问题将会在后面详细阐述。
　　任何服务器只能处于上述三种角色中的一种，正常工作的集群具有一个Leader，剩余的节点都是Fellower，系统保证任何时候至多只有一个Leader，也有可能在选举的过程中尚未产生Leader，而在选举新Leader的时候会产生Candidate这个角色。

　　a. Leader
　　Raft算法强化了一个领导者(Leader)的角色。一旦被选举成为Leader，就会发送空的AppendEntries RPC作为心跳给所有其他服务器，并且这个心跳会在一定空余时间后不停的发送，这样可以阻止选取超时而阻止其他服务器重新发起选举操作；
　　Leader负责接收客户端的请求(如果客户端和Fellower联系，那么这个请求会被重新定向给Leader)，然后附加entry到本地日志存储中，并负责把日志安全地复制到其他服务器上面，entry被用于Leader本地状态机后给客户端发送响应；
　　对于任何一个Fellower，如果已存储的日志比较旧，还会向Leader不断减小nextIndex要求发送之前的日志条目；
　　如果日志被安全地复制到了大多数节点上面，则增加提交索引号commitIndex，表明日志已经被安全复制；
　　b. Follower
　　通常的服务器角色状态，只响应来自Candidate和Leader的请求；
　　如果在选举超时到达后还没收到Leader的心跳消息，或者是候选人发起投票请求，则自己变成Candidate；
　　c. Candidate
　　当转变成Candidate后就立即开始选举过程——增加当前term、给自己投票、重置选举超时定时器、发送RequestVote给所有的服务器；
　　如果在超时之前收到绝大多数服务器的投票，就成为Leader；当一个节点收到RequestVote RPC的时候，如果请求投票节点的term不比自己旧，其日志也不比自己少，则投票给他；
　　如果收到来自新Leader的AppendEntries RPC，则退变成Fellower；
　　如果选举过程超时，则再次发起新一轮选举；

　　Raft中使用term表示Leader的任期，使用连续递增的整数来标记区分，在Raft中充当了逻辑时钟的作用，很多操作和记录会打上这个“逻辑时间戳”；每个服务器存储自己的term，服务器之间通信也会交换各自当前term，通过比较term可以确定哪些信息已经过期；当Candidate或Leader发现自己的term过期之后，会立即退变成Fellower的角色；如果服务器收到包含过期term的请求，就会直接拒绝这个请求返回false。
　　Raft算法中节点之间的通信使用RPC的方式，主要包括RequestVote、AppendEntries以及InstallSnapshot三种，RPC可以并行的被发起，而当没有及时收到响应的时候会进行重试，同时RPC只需要在绝大多数快速的节点上完成就可以了，少部分比较慢的节点不会影响到系统的整体性能。 　　

2.2 Leader选举

　　很显然以Leader为中心可以大大简化系统的设计和实现，但是分布式系统中任何一个服务器都可能随时崩溃不可用，那么必须使用选举机制来解决Leader出错导致的单点故障。
　　Raft中Leader地位的维持和心跳机制密切相关。集群中所有服务器默认都是Fellower的角色，如果Fellower在一段时间中没有收到任何消息(无论是正常消息还是心跳消息)，就会触发选举超时，从而认为系统中没有可用的领导者，进而开始进行选举。选举开始的时候，Fellower会增加当前term并切换为Candidate角色，然后并行向集群中所有其他服务器节点发送RequestVote RPC来给自己投票，候选人等待直到三种情况之一发生：
　　a. 该Candidate赢得该次选举成为新Leader
　　当某个Candidate从集群中绝大多数服务器获得针对该term的选票，则其赢得该次选举成为Leader，因为按照先来先得的原则，每个服务器最多会对一个term投出一张选票，获得绝大多数选票确保了至多只有一个候选人赢得该次选举。
　　一旦Candidate成为Leader，就会向其他服务器发送心跳消息维护自己Leader的地位，并且阻止产生新的Leader。
　　b. 其他服务器成为新Leader
　　Candidate在收集选票的时候，很可能收到其他服务器发送的声明自己是Leader的AppendEntries RPC消息，此时如果收到的AppendEntries RPC的term不小于该Candidate当前的term，则Candidate承认发送该AppendEntries RPC的服务器的Leader合法地位，自己退化为Fellower角色。否则会拒绝这个RPC并维持自己Candidate的角色。
　　c. 一段时间后没有任何Candidate胜出
　　一般出现在多个Fellower变成Candidate，然后同时发出RequestVote RPC请求，导致选票被瓜分后，没有任何一个Candidate获得绝大多数选票。此时Candidate会增加term并开始新一轮的Leader选举。
　　通常情况下这种选票瓜分的恶性竞争会持续下去。Raft采用随机选举超时的机制来减少这种情况的发生，选举超时设置为某个固定时间区域中的随机值(比如150-300ms)，这样当现有Leader挂掉之后，通常也只有一个Fellower会首先超时，然后迅速切换为Candidate、发出RequestVote RPC并赢得选举，然后快速发送心跳包；同时在发生选票瓜分的情况下，每次在Candidate开始新一轮的选举时候，会重置一个随机的选举超时时间。通过这机制，发生选票瓜分的几率被大大降低了。

2.3 日志复制

　　一旦Leader的角色被确定，就可以接受客户端的请求并提供服务了。客户端的每一个请求都包含状态机的执行指令，Leader负责刚其作为一个entry追加到自己本地日志中，然后并行的向其他服务器发送附含执行指令的AppendEntries RPC，使其他服务器都复制这个日志entry。当该条日志被安全的复制后(即通过AppendEntries RPC调用的结果得知，该日志被安全地复制到绝大多数服务器上面了)，Leader会应用这条日志到自己的状态机中，并将执行的结果返回给客户端。如果(少部分)Fellower崩溃或者运行缓慢，或者因为网络等问题，即使Leader已经回复了客户端，Leader仍然会不断的重试AppendEntries RPC直到所有的Fellower都最终存储了所有的日志条目。
　　在Raft算法中，日志是有序序号标记的entry组成的，每个entry包含该创建时候的term、状态机需要执行的指令、在所有日志中的位置索引组成。Raft保证当日志条目被复制到绝大多数服务器上面的时候，该日志entry就会被提交，即更新commitIndex，Raft算法同时也保证所有已提交的日志都是持久化的并且最终会被所有的可用状态机执行。

　　Leader跟踪了最大将会被提交日志entry的索引，并且该索引值会被包含在未来所有的AppendEntries RPC中(包含附加日志内容为空的心跳包)，这可以方便的让其他服务器知道Leader的提交位置，一旦Fellower知道一条日志已经被提交，就会按照日志的顺序将其应用到本地的状态机中去执行。
　　和Paxos不同的是，Raft的日志约束为连续的、中间不允许有空洞，而且相同索引的日志在各个服务器上面指令完全相同，这样的设计可以减少很多不必要的麻烦，具体来说：
　　(1) 如果在不同服务器的日志中拥有相同的索引和Term，那么他们存储了相同的指令；
　　(2) 如果不同服务器中两个日志具有相同的索引和Term，那么他们之前所有的日志条目也都全部相同。
　　对于上面第二点，通过每次RPC简单一致性检查就可以确保。每当Leader发送AppendEntries RPC的时候，会包含新entry紧接之前条目的索引位置和term附加在里面，当Fellower接收到的时候会进行一致性检查，如果发现索引及term指定的日志找不到，就会拒绝接收该AppendEntries RPC请求。这种一致性通过强制Fellower复制Leader日志的方式来解决，领导者对每一个Fellower都维护了一个nextIndex，表示下一个需要发送给Fellower日志条目的索引位置，Leader通过不断减少nextIndex后退的方式尝试最终会找到和Fellower日志不一致位置开始的地方，然后从这个地方开始Leader将自己的日志同步给Fellower就可以了。不过这种大规模的日志不一致性通常在服务器接连崩溃的情况下更容易产生，当新选出了Leader之后，该Leader也会强制所有服务器的nextIndex为自己本地最后一条日志索引值+1，这样在后续正常发送AppendEntries RPC请求后，所有的Fellower就会自动进行本地日志一致性检查并在必要情况下进行同步操作了。
　　通过这种方式，只需Leader向Fellower单方面同步日志就可以完成，而且只需要Leader正常发送AppendEntries RPC请求，Fellower自己进行一致性检查，Leader得到失败的反馈信息后，再同Fellower进行不断交互以使得两者日志最终趋于一致，而且这种操作不会影响到其他的Fellower，因而也不会影响到系统整体的性能。

2.4 安全性

　　上面的内容都比较的理想化，但是在现实环境中Leader、Fellower各个服务器随时都可能崩溃不可用，如果没有额外的约束整个系统的工作是不安全的，比如当只有少量日志的Fellower被选取成了新Leader的情况。
　　简单来说，此处就是要实现即使发生了Leader重新选取，也要让任何新Leader对于给定的term，都必须有前任Leader所有已经被提交的日志条目，那么上面的机制就仍然可以正常工作。

2.4.1 增加选举限制

　　如果任何的Fellower都可以成为新人Leader，那么这个新Leader很有可能缺失前Leader的部分提交日志，很多一致性算法确实是这样的，然后通过某些方法识别出新Leader缺失日志，并在选举阶段或者成为新Leader之后快速的将这些缺失日志补齐，这些方法实现起来比较复杂。Raft算法通过很简单的限制解决了这个问题：在RequestVote RPC 中包含了Candidate的日志信息，然后投票人会拒绝掉那些日志没有自己新的请求。
　　上面的这条约束肯定是有效的：对于一个被提交的日志，那么这个日志肯定是被大多数服务器所见而被存储的，而一个Candidate要想成为Leader就必须和集群中的大多数服务器所通信，这样一来新Leader肯定会遇到至少一个记录着最新提交日志的服务器。再加上上面的限制条件，那么一个新当选的Leader至少会和大多数的服务器节点一样新，其肯定持有了所有已经提交了的日志条目。

2.4.2 提交前term内的日志条目

　　在Raft算法中，当一个日志被安全的复制到绝大多数的机器上面，即AppendEntries RPC在绝大多数服务器正确返回了，那么这个日志就是被提交了，然后Leader会更新commitIndex。
　　这里书中描述的比较复杂，其实本质就是通过上面的选举机制和提交限制，让Raft算法是安全的，即使是针对前term的日志：如果日志被复制到绝大多数服务器上面，那么含有较少日志的S5服务器就不会被选举成Leader，也就不会发生描述的entry-2日志即使被复制到绝大多数服务器上面，也最终被覆盖的情况；而当含有被复制的绝大多数日志entry-2的服务器被选为新节点的时候，提交entry-4也会让前面的entry-2被隐式提交。

2.4.3 Candidate和Fellower崩溃

　　Candidate和Fellower崩溃的情况处理要简单的多。如果这类角色崩溃了，那么后续发送给他们的 RequestVote和AppendEntries的所有RCP都会失败，Raft算法中处理这类失败就是简单的无限重试的方式。
　　如果这些服务器重新可用，那么这些RPC就会成功返回。如果一个服务器完成了一个RPC，但是在响应Leader前崩溃了，那么当他再次可用的时候还会收到相同的RPC请求，此时接收服务器负责检查，比如如果收到了已经包含该条日志的RPC请求，可以直接忽略这个请求，确保对系统是无害的。

三、集群成员变更

　　集群成员的变更和成员的宕机与重启不同，因为前者会修改成员个数进而影响到Leader的选取和决议过程，因为在分布式系统这对于majority这个集群中成员大多数的概念是极为重要的。
　　在集群中成员变更的NEW配置不可能立即在所有成员中生效，所以必须采用两阶段的方式来保证安全性，传统方式是将集群暂停工作，让其不再接受新客户的请求，更新配置完成后在让集群继续正常运行。
　　Raft中集群成员的变更是全自动的，通过产生一个“共同一致状态”来过渡传播NEW配置，并且做到在集群成员变更过程中仍然支持客户端请求，依靠在临界状态下达成一致的操作(针对选取和提交)需要分别在新旧两种配置上都获得绝大多数服务器投票才可以。成员变更请求在日志中以特殊的configuration entry来存储和通信，主要通过C-old,new和C-new这两个特殊日志entry来实现。
　　在Leader接收到成员变更请求后，会创建C-old,new日志entry，然后Leader会首先将其添加到自己本地日志中，并通过之前描述的普通日志复制提交流程，确保在OLD、NEW两个配置下的在绝大多数服务器上复制成功并提交；接下来Leader会创建一个C-new并在NEW配置下的绝大多数机器上复制成功并提交，创建C-new之后NEW配置就可以单独做出决议了。此外，这里还有一个关键性的约定——所有的服务器一旦存储了C-old,new日志条目后(实际就是见到NEW配置后)，就总是会用NEW配置而无论这个配置日志条目是否已经被提交，通过这种方式实现NEW配置在集群成员中快速传播。一旦C-old,new被提交后，OLD和NEW配置都不能单方面的产生决议(只能在新旧两个配置下都完成绝大多数投票)以保证安全，直到NEW配置下的C-new日志条目被产生，NEW配置就可以单独决议了。

　　至于在C-old,new提交和C-new创建之间为什么会有间隙，原文没有说清楚。其实也很容易理解：在C-old,new日志entry的创建和提交之间，Leader还可能有其他新的决议发起(比如客户端请求)，按照日志顺序一旦C-old,new被提交，那么集群中绝大多数主机都更新成NEW配置了，但是在NEW配置传播的过程中，为了保证安全在这个期间产生的所有日志都必须在新老配置中都得到绝大多数投票才允许真正被提交。至于C-new的产生，是为了表明Leader承诺从这个时候起所有的日志都不再会发给OLD配置主机，所以这个点之后NEW配置就可以独立工作了，由于Raft序列化日志的特性，一旦这个C-new日志条目被提交，集群配置中被删除的服务器就可以安全下线了。
　　新加入的机器日志都是空白的，起始阶段都在进行日志追赶(catch up)，Raft算法为了减少可能的性能损耗，对新加入的机器都是以旁观者的状态一直追赶旧日志而不会追加新日志参与投票，只有到了追赶日志和Leader对齐了，再参与新日志追加投票以行使正常集群成员的职能。还有NEW配置可能会把现任Leader删除掉，那么当C-new被提交后，该Leader将会卸任并退化成Fellower的角色，此时在NEW配置下会发生新Leader的选举，选举得到的新Leader一定是NEW配置下的主机，而在这之前由于一致性状态的约束，如果发生Leader选举那么选出来只可能是OLD配置中的服务器，因为一致性状态选举操作必须在新旧配置中都得到绝大多数选票才行。

四、日志压缩

　　日志会随着系统的不断运行会无限制的增长，这会给存储带来压力，几乎所有的分布式系统(Chubby、ZooKeeper)都采用快照的方式进行日志压缩，做完快照之后快照会在稳定持久存储中保存，而快照之前的日志和快照就可以丢弃掉。
　　Raft算法中快照所需保存的数据有：快照点时候状态机的状态信息；最后被快照所取代的日志条目在日志中的索引值；上面被取代条目所属的任期term，此外为了支持成员更新，快照还会将当前最新的成员配置写入上面描述的那个日志索引中。
　　Raft采用让服务器独立创建快照，而不是只让Leader负责创建快照，主要考虑到在所有服务器本地已经具有了创建快照所需的全部信息，而且本地创建快照代替Leader创建快照，就免除了Leader要向各个节点传输快照的额外任务、带宽和性能损耗，而且在Leader负责客户端响应、发送RPC的任务外如果还需维护快照的任务，其角色就会更加复杂。
　　在Raft中快照都是各个服务器独立创建的，但是有时候需要Leader向其他服务器发送快照，比如某些服务器跟随的速度缓慢，或者新加入集群的服务器，此时需要向Leader同步日志的时候，如果Leader创建了快照并将之前的日志都删除掉了，那么此时就必须通过快照的方式发送了。
　　Raft中采用一个额外的InstallSpanshot RPC的调用来实现日志传输，虽然名曰快照，其实也就算是一个特殊的日志entry。当接收到快照的时候，通常情况下快照会包含接受者中没有的信息，即快照代表的日志entry会比接受者当前本地含有的日志要新，此时接收者会丢弃掉自己所有的日志，并在指定位置写入该快照作为最新状态；如果因为网络或其他因素，接收者含有比快照更新的日志，那么接收者负责把快照位置之前的数据全部删除，同时比快照新的数据需要保留下来。

五、Client交互

　　Client只向Leader发送请求，当Client开始的时候会随机向集群中的任何一个服务器发送请求，如果Client挑中的恰巧不是Leader，那么该服务器会拒绝Client的请求，并将其最近获得的Leader信息(包括通信用的IP:Port)返回给Client，接下来Client根据这个信息直接向Leader重新发送请求；如果此时Leader恰巧崩溃了，那么Client的请求就会超时出错，Client会再次重新随机挑选服务器再次发送请求。
　　Raft算法要求Client的请求是线性化语义的，即每次请求会被立即执行，在请求和响应中只会被执行一次(也就是RESTful中的等幂性，同一个请求发起一次或者多次，最终的效果是相同的)，而要确保这个效果的方式是客户端负责对每条指令都赋予一个唯一的序列号，然后状态机跟踪每条指令最新序列号和其响应结果，如果后面收到一条指令具有相同的序列号但是该序列号已经被执行了，那么就直接返回结果而不重新执行该指令。
　　对于只读操作可以直接处理而不需要记录日志，但是会有读取脏数据的风险。在Leader稳定运行的时态，Leader肯定知道当前已经提交的entry，但是在新Leader选取刚上任的时候，虽然肯定是含有最完整的日志信息的，但是还不知道提交到哪条entry了(可以参看上面提交前term日志条目的情况)，所以在新Leader上任的时候会发起一个no-op的entry来刷新得到最新commit信息。然后，Leader在响应只读请求的时候，需要向绝大多数服务器发送一个心跳信息，确保当前自己还是合法的Leader。

总结

　　如果在工程化的水平上考虑，Raft算法的确比MultiPaxos要简单容易的多，而且对比PhxPaxos中做出的诸如Master选举与心跳、Master负责所有客户端请求(允许普通节点响应脏数据除外)、日志压缩与快照等等操作，在这里看来也是那么的熟悉，只不过Raft对于整个分布式的设计和实现要更清晰、更系统，而不会让人感觉是在MultiPaxos的基础上缝缝补补拼凑出来的一个怪物吧。
　　眼观这么多论文，大家对Paxos的工程化实现，感觉都是相互借鉴啊，哈哈！

参考

• In Search of an Understandable Consensus Algorithm
• raft.github.io
• 找一种易于理解的一致性算法（扩展版）
• CONSENSUS: BRIDGING THEORY AND PRACTICE
• Raft: A Consensus Algorithm for Replicated Logs

　至此，Paxos、Raft、ZAB代表着分布式系统中最常见的一致性协议都有所了解，但是除了PaxSql之外，对于分布式系统一致性原理的实际应用还处于一脸懵逼的状态中。此处于是主要借着《从Paxos到Zookeeper:分布式一致性原理与实践》中的案例，依靠ZooKeeper分布式系统组建，对分布式系统的使用情境做一个简单的了解。毕竟嘛，我又不是做学术的，了解原理后不知道现实有什么用处又有啥意义…
　　ZooKeeper扮演者分布式系统的管理和协调框架的作用，通过前面对ZAB和ZooKeeper的了解，ZooKeeper通过ZNode数据模型和序列号、持久和临时节点分类，以及Watcher事件通知机制，可以快速构建分布式应用的核心功能，看看Apache旗下那么多基于ZooKeeper的分布式项目就可晓而知了。ZooKeeper的集群达到3台就可以正常工作了，但是工业上通常认为至少达到5台才是合适的，一方面机器增多集群的可靠性增加了，再次集群工作过程中常常会有机器下线维护的情况，这样在一台机器下线的时候集群还可以容易一台机器宕机而不停止服务。

　　再次说明，个人没什么分布式系统的经验，这些都是查阅资料摘抄得来，如果错误尽请指正，被我误导概不负责！

一、数据发布/订阅(配置中心) - Publish/Subscribe
　　发布/订阅模式不仅仅会出现在这里，通常消息队列的设计中会更加常用到这种模式。发布/订阅模式功能可以分为这几种模式：
　　(1). Push模式是服务器主动将数据更新发送给所有订阅的客户端，优点是实时性好，但是服务端的工作比较繁重，常常需要记录各个客户端的状态信息，甚至要考虑消费者的消费能力实现流量控制工作；
　　(2). Pull模式则是由客户端主动发起请求来获取最新数据，通常采用定时机制轮训拉取的方式进行，所以实时性较差，但好处是实现简单；
　　(3). 还有就是结合两者进行推拉相结合的方式，客户端向服务端注册自己关心的主题，一旦主题数据有所更新，服务端会向对应订阅的客户端发送事件通知，客户端接收到事件通知后主动向服务器拉取最新的数据。
　　在系统开发中通常会遇到机器列表信息、运行时开关配置、数据库配置等信息，这些数据的特点是数据规模比较小、数据内容在运行时候常常发生动态变更、相同的数据在多个机器中共享。在单机的情况下，可以通过共享内存，或者统一配置文件(可以使用文件系统的特性监测文件变更iNotify)来满足这个需求，但是如果配置需要跨主机，尤其机器规模大且成员会发生变动的情况下共享这些动态信息就较为困难。
　　基于ZooKeeper的配置中心方案可以这样设计：首先运行一个ZooKeeper服务器集群，然后在其上面创建周知路径的ZNode；专用的配置管理程序可以修改ZNode上的配置信息，作为用户更新配置的操作接口；关心这些配置的分布式应用启动时候主动获取配置信息一次，然后对ZNode注册Watcher监听，那么当ZNode的数据内容发生变化后，ZooKeeper就可以将这个变更通知发送给所有的客户端，客户端得知这个变更通知后就可以请求获取最新数据。通过这种手段，就可以实现配置信息的集中式管理和动态更新部署的功能了。

二、负载均衡 - Load Balance
　　负载均衡在前面的Nginx中也介绍过了，Nginx支持3层和7层软件负载均衡，对用户看来这实际上是实现的基于服务端的负载均衡操作。其实负载均衡还可以在客户端实现，之前介绍的memcached的负载均衡基本都是在客户端通过一致性hash原理实现的。
　　通过ZooKeeper实现的负载均衡也是通过客户端来实现的：ZooKeeper创建一个周知路径的ZNode，其数据内容包含了可以提供服务的服务器地址信息，接收服务的客户端在该ZNode上注册Watcher以侦听它的改变。在工作的时候客户端获取提供服务的服务器列表，在接收到修改事前之前可以缓存该列表提高性能，然后服务调用者可以采用自己某种特定负载均衡算法(比如Round Robin、HASH、响应时间、最少连接等算法)选取机器获取服务。
　　为了使用方便，服务机器列表的配置可以采用全自动的方式，这也涉及到机器健康度检测问题。可以设计一个健康度探测服务端，并负责更新ZNode中的机器列表：健康度探测服务端可以同机器中的列表建立TCP长连接，健康度探测服务端采用Ping-Pong心跳监测的方式进行健康度监测；也可以机器每隔一定的时间向这个健康度探测服务端发送数据包，如果健康度探测在某个超时时间后仍未收到某机器的数据包，就认定其不可用而将其从机器列表中进行删除。(呃，后面想想，每个服务端机器把自己作为临时ZNode创建在某个路径下，这样的侦测操作不是更加的方便？和集群管理重了)

三、命名服务 - Name Service
　　命名服务其实是指明了一种映射关系，在分布式开发中有很多的资源需要命名，比如主机地址，RPC服务列表等，客户端根据名字可以获取资源的实体、服务地址和提供者等信息。
　　ZooKeeper提供了方便的API，可以轻松的创建全局唯一的path，这个path就可以作为名称使用，所以ZooKeeper的Name Service是开箱即用的。而且ZNode支持SEQUENTIAL属性，通过创建顺序节点的手法就可以创建具有相同名字但带顺序后缀的这样很具有规则性的名字，这样的命名服务显然在保证命名唯一性的同时更具有解释意义。

四、分布式协调/通知 - Coordinator
　　得益于ZooKeeper特有的Watcher注册和异步通知的机制，可以实现分布式环境下不同机器，甚至是不同系统之间的通知和协调工作，以应对于数据变更的实时快速处理，这是和观察者类似的工作模式。而且通过ZooKeepr作为一个事件的中介者，也起到了业务之间解除耦合的效果。

五、集群管理 - Management
　　用于对集群中的机器进行监控的情况，主要包括对集群运行状态的收集，以及对集群和集群成员进行操作和控制。
　　传统的运维都是基于Agent的分布式集群管理模式，通过在集群成员上部署该类服务软件，该软件负责主动向集群控制中心汇报机器的状态信息。这种方式虽然直接，但是具有着固有的缺陷：很难实现跟业务相关的细化监控，通常都是对CPU、负载等通用信息进行监测；如果整个集群环境一致还可以，否则就必须面对集群中的异构成员进行兼容和适配的问题。
　　如果运行一个ZooKeeper集群，不仅通过临时节点在会话结束后会自动消失的特性，可以快速侦测机器的上下线，而且可以通过创建特定的ZNode，集群中的机器就可以向控制中心报告更多主机相关甚至业务相关的信息，而且这一切操作都极为便利，只需要在业务端和控制中心进行适配就可以了。

六、Master选举 - Election
　　可以应用于那些只需要一个主节点做特殊的工作，其他节点做普通的工作或者候命作为冗余节点的情况，比如数据库的读写分离可以让Master处理所有的写任务，而剩余的读请求由其他机器负载均衡完成，借此提供整个数据库性能；类似的Master可以单独处理一些复杂的逻辑或者计算，而将计算结果同步共享给集群中的其他主机使用，以此减少重复劳动提高资源利用率。
　　传统情况下的选主可以使用数据库唯一性索引简单实现，在此约束下所有的机器创建同一条记录时候只能有一个机器成功，那么可以让这个独一无二的机器作为Master，但是这种方法只是解决了竞争冲突问题，无法解决Master单点故障后整个系统不可用的问题，即不能实现高效快速的动态Master选举功能。
　　对此，ZooKeeper的强一致性可以天然解决Master选举的问题(注意这里的选主是客户端的Master，和ZAB协议中的Leader没有关系)：首先ZooKeeper保证在多个客户端请求创建同一路径描述的ZNode的情况下，只会有一个客户端的请求成功；其次创建ZNode可以是临时ZNode，那么一旦创建这个临时ZNode的Master挂掉后会导致会话结束，这个临时ZNode就会自动消失；在之前竞争Master失败的客户端，可以注册该ZNode的Watcher侦听，一旦接收到节点的变更事件，就表示Master不可用了，此时大家就可以即刻再次发起Master选举操作了，以实现了一种高可用的automatic fail-over机制，满足了机器在线率有较高要求的应用场景。
　　除了上面的方式，各个主机还可以通过创建临时顺序ZNode的方式，每个主机会具有不同的后缀，一旦当前的Master宕机之后自动轮训下一个可用机器，而下线的机器也可以随时再次上线创建新序列号的临时顺序节点。

七、分布式锁 - Lock
　　主要用来进行分布式系统之间的访问资源的同步手段。在使用中分布式锁可以支持这些服务：保持独占、共享使用和时序访问。虽然关系数据库在更新的时候，数据库系统会根据隔离等级自动使用行锁、表锁机制保证数据的完整性，但是数据库通常都是大型系统的性能瓶颈之所在，所以如果使用分布式锁可以起到一定的协调作用，那么可以期待增加系统的运行效率。
　　保持独占，就是当多个客户端试图获取这把锁的时候，只能有一个可以成功获得该锁，跟上面的Master选举比较类似，当多个竞争者同时尝试创建某个path(例如”_locknode_/guid-lock-“)的ZNode时候，ZooKeeper的一致性能够保证只有一个客户端成功，创建成功的客户端也就拥有了这把互斥锁，此时其他客户端可以在这个ZNode上面注册Watcher侦听，以便得到锁变更(如持锁客户端宕机、主动解锁)的情况采取接下来的操作。
　　共享使用类似于读写锁的功能，多个读锁可以同时对一个事务可见，但是读锁和写锁以及写锁和写锁之间是互斥的。锁的名字按照类似”/share_lock/[Host]-R/W-SN”的形式创建临时顺序节点，在创建锁的同时读取/share_lock节点下的所有子节点，并注册对/share_lock/节点的Watcher侦听，然后依据读写所的兼容法则检查比自己序号小的节点看是否可以满足当前操作请求，如果不满足就执行等待。当持有锁的节点崩溃或者释放锁之后，所有处于等待状态的节点就都得到了通知，实际中这会产生一个“惊群效应”，所以可以在上面注册/share_lock/的Watcher事件进行细化，只注册比自己小的那个子节点的Watcher侦听就可以了，以避免不必要的唤醒。
　　时序访问的方式，则是在这个时候每个请求锁的客户端都可以创建临时顺序ZNode的子节点，他们维系着一个带有序列号的后缀，同时添加对锁节点(或者像上面类似优化，只注册序列号比自己小的那个子节点)的Watcher侦听，这样前面的客户端释放锁之后，后面的客户端会得到事件通知，然后按照一定顺序接下来的一个客户端获得锁。该模式能够保证每个客户端都具有访问的机会，但是其是按照创建临时顺序子节点的顺序按次序依次访问的。

八、分布式队列 - Queue
　　说到分布式队列，目前已有相当多的成熟消息中间件了。在ZooKeeper的基础上，可以方便地创建先进先出队列，以及对数据进行聚集之后再统一安排处理的Barrier的工作模式。
　　先入先出之FIFO队列算是最常见使用的数据模型了，类似于一个生产者-消费者的工作模型。生产者会创建顺序ZNode，这些顺序ZNode的后缀表明了创建的顺序，消费者获得这些顺序ZNode后挑出序列号最小的进行消费，就简单的实现了FIFO的数据类型。
　　对于另外一种Barrier(叫做屏障)工作模式，是需要把数据集聚之后再做统一处理，通常在大规模并行计算的场景上会使用到。这种队列实现也很简单，就是在创建顺序ZNode的时候记录队列当前已经拥有的事务数目，如果达到了Barrier的数目，就表示条件就绪了于是创建类似“/synchronizing/start”的ZNode，而等待处理的消费者之前就侦听该ZNode是否被创建，如果侦测到一旦创建了就表明事务的数目满足需求了，于是可以启动处理工作。

小结
　　其实，通过上面的查看，基于ZooKeeper实现特定需要的分布式应用是比较方便的，而且更可贵的是，上面的应用都是反反复复基于ZooKeeper的那几条性质实现的！ZooKeeper真是个好东西！

本文完！

参考

• 从Paxos到Zookeeper:分布式一致性原理与实践
• ZooKeeper fundamentals, deployment, and applications
• ZooKeeper Recipes and Solutions
• ZooKeeper典型应用场
• 分布式服务框架 Zookeeper – 管理分布式环境中的数据
• NGINX and ZooKeeper, Dynamic Load Balancing and Deployments
• ZooKeeper典型使用场景一览

选举(election)是分布式系统实践中常见的问题，通过打破节点间的对等关系，选得的leader(或叫master、coordinator)有助于实现事务原子性、提升决议效率。 多数派(quorum)的思路帮助我们在网络分化的情况下达成决议一致性，在leader选举的场景下帮助我们选出唯一leader。租约(lease)在一定期限内给予节点特定权利，也可以用于实现leader选举。

下面我们就来学习分布式系统理论中的选举、多数派和租约。

选举(electioin)

一致性问题(consistency)是独立的节点间如何达成决议的问题，选出大家都认可的leader本质上也是一致性问题，因而如何应对宕机恢复、网络分化等在leader选举中也需要考量。

Bully算法^[1]是最常见的选举算法，其要求每个节点对应一个序号，序号最高的节点为leader。leader宕机后次高序号的节点被重选为leader，过程如下：

(a). 节点4发现leader不可达，向序号比自己高的节点发起重新选举，重新选举消息中带上自己的序号

(b)(c). 节点5、6接收到重选信息后进行序号比较，发现自身的序号更大，向节点4返回OK消息并各自向更高序号节点发起重新选举

(d). 节点5收到节点6的OK消息，而节点6经过超时时间后收不到更高序号节点的OK消息，则认为自己是leader

(e). 节点6把自己成为leader的信息广播到所有节点

回顾《分布式系统理论基础 - 一致性、2PC和3PC》就可以看到，Bully算法中有2PC的身影，都具有提议(propose)和收集反馈(vote)的过程。

在一致性算法Paxos、ZAB^[2]、Raft^[3]中，为提升决议效率均有节点充当leader的角色。ZAB、Raft中描述了具体的leader选举实现，与Bully算法类似ZAB中使用zxid标识节点，具有最大zxid的节点表示其所具备的事务(transaction)最新、被选为leader。

多数派(quorum)

在网络分化的场景下以上Bully算法会遇到一个问题，被分隔的节点都认为自己具有最大的序号、将产生多个leader，这时候就需要引入多数派(quorum)^[4]。多数派的思路在分布式系统中很常见，其确保网络分化情况下决议唯一。

多数派的原理说起来很简单，假如节点总数为2f+1，则一项决议得到多于 f 节点赞成则获得通过。leader选举中，网络分化场景下只有具备多数派节点的部分才可能选出leader，这避免了多leader的产生。

多数派的思路还被应用于副本(replica)管理，根据业务实际读写比例调整写副本数V_w、读副本数V_r，用以在可靠性和性能方面取得平衡^[5]。

租约(lease)

选举中很重要的一个问题，以上尚未提到：怎么判断leader不可用、什么时候应该发起重新选举？最先可能想到会通过心跳(heart beat)判别leader状态是否正常，但在网络拥塞或瞬断的情况下，这容易导致出现双主。

租约(lease)是解决该问题的常用方法，其最初提出时用于解决分布式缓存一致性问题^[6]，后面在分布式锁^[7]等很多方面都有应用。

租约的原理同样不复杂，中心思想是每次租约时长内只有一个节点获得租约、到期后必须重新颁发租约。假设我们有租约颁发节点Z，节点0、1和2竞选leader，租约过程如下：

(a). 节点0、1、2在Z上注册自己，Z根据一定的规则(例如先到先得)颁发租约给节点，该租约同时对应一个有效时长；这里假设节点0获得租约、成为leader

(b). leader宕机时，只有租约到期(timeout)后才重新发起选举，这里节点1获得租约、成为leader

租约机制确保了一个时刻最多只有一个leader，避免只使用心跳机制产生双主的问题。在实践应用中，zookeeper、ectd可用于租约颁发。

小结

在分布式系统理论和实践中，常见leader、quorum和lease的身影。分布式系统内不一定事事协商、事事民主，leader的存在有助于提升决议效率。

本文以leader选举作为例子引入和讲述quorum、lease，当然quorum和lease是两种思想，并不限于leader选举应用。

最后提一个有趣的问题与大家思考，leader选举的本质是一致性问题，Paxos、Raft和ZAB等解决一致性问题的协议和算法本身又需要或依赖于leader，怎么理解这个看似“蛋生鸡、鸡生蛋”的问题？^[8]

[1] Elections in a Distributed Computing System, Hector Garcia-Molina, 1982

[2] ZooKeeper’s atomic broadcast protocol: Theory and practice, Andre Medeiros, 2012

[3] In Search of an Understandable Consensus Algorithm, Diego Ongaro and John Ousterhout, 2013

[4] A quorum-based commit protocol, Dale Skeen, 1982

[5] Weighted Voting for Replicated Data, David K. Gifford, 1979

[6] Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency, Cary G. Gray and David R. Cheriton, 1989

[7] The Chubby lock service for loosely-coupled distributed systems, Mike Burrows, 2006

[8] Why is Paxos leader election not done using Paxos?

引言

狭义的分布式系统指由网络连接的计算机系统，每个节点独立地承担计算或存储任务，节点间通过网络协同工作。广义的分布式系统是一个相对的概念，正如Leslie Lamport所说^[1]：

What is a distributed systeme. Distribution is in the eye of the beholder.
To the user sitting at the keyboard, his IBM personal computer is a nondistributed system. 
To a flea crawling around on the circuit board, or to the engineer who designed it, it's very much a distributed system.

 一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。

一致性(consensus)

何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见，比如牌友怎么商定几点在哪打几圈麻将：

《赌圣》，1990

假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：

1. 全认同(agreement): 所有N个节点都认同一个结果
2. 值合法(validity): 该结果必须由N个节点中的节点提出
3. 可结束(termination): 决议过程在一定时间内结束，不会无休止地进行下去

有人可能会说，决定什么时候在哪搓搓麻将，4个人商量一下就ok，这不很简单吗？

但就这样看似简单的事情，分布式系统实现起来并不轻松，因为它面临着这些问题：

• 消息传递异步无序(asynchronous): 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序(synchronous)
• 节点宕机(fail-stop): 节点持续宕机，不会恢复
• 节点宕机恢复(fail-recover): 节点宕机一段时间后恢复，在分布式系统中最常见
• 网络分化(network partition): 网络链路出现问题，将N个节点隔离成多个部分
• 拜占庭将军问题(byzantine failure)^[2]: 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息

假设现实场景中也存在这样的问题，我们看看结果会怎样：

我: 老王，今晚7点老地方，搓够48圈不见不散！ …… （第二天凌晨3点） 隔壁老王: 没问题！       // 消息延迟 我: …… ---------------------------------------------- 我: 小张，今晚7点老地方，搓够48圈不见不散！ 小张: No ……                            （两小时后……） 小张: No problem！                     // 宕机节点恢复 我: …… ----------------------------------------------- 我: 老李头，今晚7点老地方，搓够48圈不见不散！ 老李: 必须的，大保健走起！               // 拜占庭将军
（这是要打麻将呢？还是要大保健？还是一边打麻将一边大保健……）

还能不能一起愉快地玩耍...

我们把以上所列的问题称为系统模型(system model)，讨论分布式系统理论和工程实践的时候，必先划定模型。例如有以下两种模型：

1. 异步环境(asynchronous)下，节点宕机(fail-stop)
2. 异步环境(asynchronous)下，节点宕机恢复(fail-recover)、网络分化(network partition)

2比1多了节点恢复、网络分化的考量，因而对这两种模型的理论研究和工程解决方案必定是不同的，在还没有明晰所要解决的问题前谈解决方案都是一本正经地耍流氓。

一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统24*7无间断对外服务。FLP定理(FLP impossibility)^[3][4] 已经证明在一个收窄的模型中(异步环境并只存在节点宕机)，不能同时满足 safety 和 liveness。

FLP定理是分布式系统理论中的基础理论，正如物理学中的能量守恒定律彻底否定了永动机的存在，FLP定理否定了同时满足safety 和 liveness 的一致性协议的存在。

《怦然心动 (Flipped)》，2010

工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。

2PC

2PC(tow phase commit)两阶段提交^[5]顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：

2PC, phase one

在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。

2PC, phase two

在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。

在异步环境(asynchronous)并且没有节点宕机(fail-stop)的模型下，2PC可以满足全认同、值合法、可结束，是解决一致性问题的一种协议。但如果再加上节点宕机(fail-recover)的考虑，2PC是否还能解决一致性问题呢？

coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来，我们把新增的这一角色叫协调者备份(coordinator watchdog)。coordinator宕机一定时间后，watchdog接替原coordinator工作，通过问询(query) 各participant的状态，决定阶段2是提交还是中止。这也要求 coordinator/participant 记录(logging)历史状态，以备coordinator宕机后watchdog对participant查询、coordinator宕机恢复后重新找回状态。

从coordinator接收到一次事务请求、发起提议到事务完成，经过2PC协议后增加了2次RTT(propose+commit)，带来的时延(latency)增加相对较少。

3PC

3PC(three phase commit)即三阶段提交^[6][7]，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？

在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到participant宕机恢复。这引出两个疑问：

1. 能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
2. 当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态

相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：

图片截取自wikipedia

coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。

participant如果在不同阶段宕机，我们来看看3PC如何应对：

• 阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
• 阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
• 阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务

因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。

小结

以上介绍了分布式系统理论中的部分基础知识，阐述了一致性(consensus)的定义和实现一致性所要面临的问题，最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。

阅读前人对分布式系统的各项理论研究，其中有严谨地推理、证明，有一种数学的美；观现实中的分布式系统实现，是综合各种因素下妥协的结果。

[1] Solved Problems, Unsolved Problems and Problems in Concurrency, Leslie Lamport, 1983

[2] The Byzantine Generals Problem, Leslie Lamport,Robert Shostak and Marshall Pease, 1982

[3] Impossibility of Distributed Consensus with One Faulty Process, Fischer, Lynch and Patterson, 1985

[4] FLP Impossibility的证明, Daniel Wu, 2015

[5] Consensus Protocols: Two-Phase Commit, Henry Robinson, 2008

[6] Consensus Protocols: Three-phase Commit, Henry Robinson, 2008

[7] Three-phase commit protocol, Wikipedia

在谈论数据库架构和数据库优化的时候，我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是，这些朋友所服务的公司业务量正在（或者即将面临）高速增长，技术方面也面临着一些挑战。让人感到担忧的是，他们系统真的就需要“分库分表”了吗？“分库分表”有那么容易实践吗？为此，笔者整理了分库分表中可能遇到的一些问题，并结合以往经验介绍了对应的解决思路和建议。

垂直分表

垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中，如下图所示：

小结

在字段很多的情况下，拆分开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）。某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销，这里不展开，感兴趣的朋友可以自行查阅相关资料进行研究）。

拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。

垂直分库

垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。如下图：

小结

系统层面的“服务化”拆分操作，能够解决业务系统层面的耦合和性能瓶颈，有利于系统的扩展维护。而数据库层面的拆分，道理也是相通的。与服务的“治理”和“降级”机制类似，我们也能对不同业务类型的数据进行“分级”管理、维护、监控、扩展等。

众所周知，数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段。

然后，很多人并没有从根本上搞清楚为什么要拆分，也没有掌握拆分的原则和技巧，只是一味的模仿大厂的做法。导致拆分后遇到很多问题（例如：跨库join，分布式事务等）。

水平分表

水平分表也称为横向分表，比较容易理解，就是将表中不同的数据行按照一定规律分布到不同的数据库表中（这些表保存在同一个数据库中），这样来降低单表数据量，优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分。如下图所示：

小结

水平分表，能够降低单表的数据量，一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中，所以库级别还是会有IO瓶颈。所以，一般不建议采用这种做法。

水平分库分表

水平分库分表与上面讲到的水平分表的思想相同，唯一不同的就是将这些拆分出来的表保存在不同的数据中。这也是很多大型互联网公司所选择的做法。如下图：

某种意义上来讲，有些系统中使用的“冷热数据分离”（将一些使用较少的历史数据迁移到其他的数据库中。而在业务功能上，通常默认只提供热点数据的查询），也是类似的实践。在高并发和海量数据的场景下，分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈。当然，投入的硬件成本也会更高。同时，这也会带来一些复杂的技术问题和挑战（例如：跨分片的复杂查询，跨分片事务等）

分库分表的难点

垂直分库带来的问题和解决思路：

跨库join的问题

在拆分之前，系统中很多列表和详情页所需的数据是可以通过sql join来完成的。而拆分后，数据库可能是分布式在不同实例和不同的主机上，join将变得非常麻烦。而且基于架构规范，性能，安全性等方面考虑，一般是禁止跨库join的。那该怎么办呢？首先要考虑下垂直分库的设计问题，如果可以调整，那就优先调整。如果无法调整的情况，下面笔者将结合以往的实际经验，总结几种常见的解决思路，并分析其适用场景。

跨库Join的几种解决思路

全局表

所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。

字段冗余

这是一种典型的反范式设计，在互联网行业中比较常见，通常是为了性能来避免join查询。

举个电商业务中很简单的场景：

“订单表”中保存“卖家Id”的同时，将卖家的“Name”字段也冗余，这样查询订单详情的时候就不需要再去查询“卖家用户表”。

字段冗余能带来便利，是一种“空间换时间”的体现。但其适用场景也比较有限，比较适合依赖字段较少的情况。最复杂的还是数据一致性问题，这点很难保证，可以借助数据库中的触发器或者在业务代码层面去保证。当然，也需要结合实际业务场景来看一致性的要求。就像上面例子，如果卖家修改了Name之后，是否需要在订单信息中同步更新呢？

数据同步

定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的。

系统层组装

在系统层面，通过调用不同模块的组件或者服务，获取到数据并进行字段拼装。说起来很容易，但实践起来可真没有这么简单，尤其是数据库设计上存在问题但又无法轻易调整的时候。

具体情况通常会比较复杂。下面笔者结合以往实际经验，并通过伪代码方式来描述。

简单的列表查询的情况

伪代码很容易理解，先获取“我的提问列表”数据，然后再根据列表中的UserId去循环调用依赖的用户服务获取到用户的RealName，拼装结果并返回。

有经验的读者一眼就能看出上诉伪代码存在效率问题。循环调用服务，可能会有循环RPC，循环查询数据库…不推荐使用。再看看改进后的：

这种实现方式，看起来要优雅一点，其实就是把循环调用改成一次调用。当然，用户服务的数据库查询中很可能是In查询，效率方面比上一种方式更高。（坊间流传In查询会全表扫描，存在性能问题，传闻不可全信。其实查询优化器都是基本成本估算的，经过测试，在In语句中条件字段有索引的时候，条件较少的情况是会走索引的。这里不细展开说明，感兴趣的朋友请自行测试）。

小结

简单字段组装的情况下，我们只需要先获取“主表”数据，然后再根据关联关系，调用其他模块的组件或服务来获取依赖的其他字段（如例中依赖的用户信息），最后将数据进行组装。

通常，我们都会通过缓存来避免频繁RPC通信和数据库查询的开销。

列表查询带条件过滤的情况

在上述例子中，都是简单的字段组装，而不存在条件过滤。看拆分前的SQL：

这种连接查询并且还带条件过滤的情况，想在代码层面组装数据其实是非常复杂的（尤其是左表和右表都带条件过滤的情况会更复杂），不能像之前例子中那样简单的进行组装了。试想一下，如果像上面那样简单的进行组装，造成的结果就是返回的数据不完整，不准确。 

有如下几种解决思路：

1. 查出所有的问答数据，然后调用用户服务进行拼装数据，再根据过滤字段state字段进行过滤，最后进行排序和分页并返回。

   这种方式能够保证数据的准确性和完整性，但是性能影响非常大，不建议使用。

2. 查询出state字段符合/不符合的UserId，在查询问答数据的时候使用in/not in进行过滤，排序，分页等。过滤出有效的问答数据后，再调用用户服务获取数据进行组装。

   这种方式明显更优雅点。笔者之前在某个项目的特殊场景中就是采用过这种方式实现。

跨库事务（分布式事务）的问题

按业务拆分数据库之后，不可避免的就是“分布式事务”的问题。以往在代码中通过spring注解简单配置就能实现事务的，现在则需要花很大的成本去保证一致性。这里不展开介绍， 
感兴趣的读者可以自行参考《分布式事务一致性解决方案》，链接地址： 
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency

垂直分库总结和实践建议

本篇中主要描述了几种常见的拆分方式，并着重介绍了垂直分库带来的一些问题和解决思路。读者朋友可能还有些问题和疑惑。

1. 我们目前的数据库是否需要进行垂直分库？

根据系统架构和公司实际情况来，如果你们的系统还是个简单的单体应用，并且没有什么访问量和数据量，那就别着急折腾“垂直分库”了，否则没有任何收益，也很难有好结果。

切记，“过度设计”和“过早优化”是很多架构师和技术人员常犯的毛病。

2. 垂直拆分有没有原则或者技巧？

没有什么黄金法则和标准答案。一般是参考系统的业务模块拆分来进行数据库的拆分。比如“用户服务”，对应的可能就是“用户数据库”。但是也不一定严格一一对应。有些情况下，数据库拆分的粒度可能会比系统拆分的粒度更粗。笔者也确实见过有些系统中的某些表原本应该放A库中的，却放在了B库中。有些库和表原本是可以合并的，却单独保存着。还有些表，看起来放在A库中也OK，放在B库中也合理。

如何设计和权衡，这个就看实际情况和架构师/开发人员的水平了。

3. 上面举例的都太简单了，我们的后台报表系统中join的表都有n个了， 
分库后该怎么查？

有很多朋友跟我提过类似的问题。其实互联网的业务系统中，本来就应该尽量避免join的，如果有多个join的，要么是设计不合理，要么是技术选型有误。请自行科普下OLAP和OLTP，报表类的系统在传统BI时代都是通过OLAP数据仓库去实现的（现在则更多是借助离线分析、流式计算等手段实现），而不该向上面描述的那样直接在业务库中执行大量join和统计。

由于篇幅关系，下篇中我们再继续细聊“水平分库分表”相关的话题。 

• 分享到：微博微信FacebookTwitter有道云笔记邮件分享
• 稍后阅读
• 我的阅读清单

最大努力送达型

概念

在分布式数据库的场景下，相信对于该数据库的操作最终一定可以成功，所以通过最大努力反复尝试送达操作。

架构图

适用场景

• 根据主键删除数据。
• 更新记录永久状态，如更新通知送达状态。

使用限制

使用最大努力送达型柔性事务的SQL需要满足幂等性。

• INSERT语句要求必须包含主键，且不能是自增主键。
• UPDATE语句要求幂等，不能是UPDATE xxx SET x=x+1
• DELETE语句无要求。

开发指南

• Sharding-JDBC-transaction完全基于java开发，直接提供jar包，可直接使用maven导入坐标即可使用。
• 为了保证事务不丢失，Sharding-JDBC-transaction需要提供数据库存储事务日志，配置方法可参见事务管理器配置项。
• 由于柔性事务采用异步尝试，需要部署独立的作业和Zookeeper。Sharding-JDBC-transaction采用elastic-job实现的Sharding-JDBC-transaction-async-job，通过简单配置即可启动高可用作业异步送达柔性事务，启动脚本为start.sh。
• 为了便于开发，Sharding-JDBC-transaction提供了基于内存的事务日志存储器和内嵌异步作业。

开发示例

    // 1. 配置SoftTransactionConfiguration     SoftTransactionConfiguration transactionConfig = new SoftTransactionConfiguration(dataSource);     transactionConfig.setXXX();          // 2. 初始化SoftTransactionManager     SoftTransactionManager transactionManager = new SoftTransactionManager(transactionConfig);     transactionManager.init();          // 3. 获取BEDSoftTransaction     BEDSoftTransaction transaction = (BEDSoftTransaction) transactionManager.getTransaction(SoftTransactionType.BestEffortsDelivery);          // 4. 开启事务     transaction.begin(connection);          // 5. 执行JDBC     /*          codes here     */     *      // 6.关闭事务     transaction.end(); 

事务管理器配置项

SoftTransactionConfiguration配置

用于配置事务管理器。

NestedBestEffortsDeliveryJobConfiguration配置 (仅开发环境)

用于配置内嵌的异步作业，仅用于开发环境。生产环境应使用独立部署的作业版本。

独立部署作业指南

• 部署用于存储事务日志的数据库。
• 部署用于异步作业使用的Zookeeper。
• 配置yaml文件,参照示例。
• 下载并解压文件sharding-jdbc-transaction-async-job-$VERSION.tar，通过start.sh脚本启动异步作业。

异步作业yaml文件配置

#目标数据库的数据源. targetDataSource:   ds_0: !!org.apache.commons.dbcp.BasicDataSource     driverClassName: com.mysql.jdbc.Driver     url: jdbc:mysql://localhost:3306/ds_0     username: root     password:   ds_1: !!org.apache.commons.dbcp.BasicDataSource     driverClassName: com.mysql.jdbc.Driver     url: jdbc:mysql://localhost:3306/ds_1     username: root     password:  #事务日志的数据源. transactionLogDataSource:   ds_trans: !!org.apache.commons.dbcp.BasicDataSource     driverClassName: com.mysql.jdbc.Driver     url: jdbc:mysql://localhost:3306/trans_log     username: root     password:  #注册中心配置 zkConfig:   #注册中心的连接地址   connectionString: localhost:2181      #作业的命名空间   namespace: Best-Efforts-Delivery-Job      #注册中心的等待重试的间隔时间的初始值   baseSleepTimeMilliseconds: 1000      #注册中心的等待重试的间隔时间的最大值   maxSleepTimeMilliseconds: 3000      #注册中心的最大重试次数   maxRetries: 3  #作业配置 jobConfig:   #作业名称   name: bestEffortsDeliveryJob      #触发作业的cron表达式   cron: 0/5 * * * * ?      #每次作业获取的事务日志最大数量   transactionLogFetchDataCount: 100      #事务送达的最大尝试次数.   maxDeliveryTryTimes: 3      #执行送达事务的延迟毫秒数,早于此间隔时间的入库事务才会被作业执行   maxDeliveryTryDelayMillis: 60000 

一、前言

　　前面分析了Zookeeper对请求的处理，本篇博文接着分析Zookeeper中如何对底层数据进行存储，数据存储被分为内存数据存储于磁盘数据存储。

二、数据与存储

　　2.1 内存数据

　　Zookeeper的数据模型是树结构，在内存数据库中，存储了整棵树的内容，包括所有的节点路径、节点数据、ACL信息，Zookeeper会定时将这个数据存储到磁盘上。

　　1. DataTree

　　DataTree是内存数据存储的核心，是一个树结构，代表了内存中一份完整的数据。DataTree不包含任何与网络、客户端连接及请求处理相关的业务逻辑，是一个独立的组件。

　　2. DataNode

　　DataNode是数据存储的最小单元，其内部除了保存了结点的数据内容、ACL列表、节点状态之外，还记录了父节点的引用和子节点列表两个属性，其也提供了对子节点列表进行操作的接口。

　　3. ZKDatabase

　　Zookeeper的内存数据库，管理Zookeeper的所有会话、DataTree存储和事务日志。ZKDatabase会定时向磁盘dump快照数据，同时在Zookeeper启动时，会通过磁盘的事务日志和快照文件恢复成一个完整的内存数据库。

　　2.2 事务日志

　　1. 文件存储

　　在配置Zookeeper集群时需要配置dataDir目录，其用来存储事务日志文件。也可以为事务日志单独分配一个文件存储目录:dataLogDir。若配置dataLogDir为/home/admin/zkData/zk_log，那么Zookeeper在运行过程中会在该目录下建立一个名字为version-2的子目录，该目录确定了当前Zookeeper使用的事务日志格式版本号，当下次某个Zookeeper版本对事务日志格式进行变更时，此目录也会变更，即在version-2子目录下会生成一系列文件大小一致(64MB)的文件。

　　2. 日志格式

　　在配置好日志文件目录，启动Zookeeper后，完成如下操作

　　(1) 创建/test_log节点，初始值为v1。

　　(2) 更新/test_log节点的数据为v2。

　　(3) 创建/test_log/c节点，初始值为v1。

　　(4) 删除/test_log/c节点。

　　经过四步操作后，会在/log/version-2/目录下生成一个日志文件，笔者下是log.cec。

　　将Zookeeper下的zookeeper-3.4.6.jar和slf4j-api-1.6.1.jar复制到/log/version-2目录下，使用如下命令打开log.cec文件。

　　java -classpath ./zookeeper-3.4.6.jar:./slf4j-api-1.6.1.jar org.apache.zookeeper.server.LogFormatter log.cec

　　ZooKeeper Transactional Log File with dbid 0 txnlog format version 2 。是文件头信息，主要是事务日志的DBID和日志格式版本号。　　

　　...session 0x159...0xcec createSession 30000。表示客户端会话创建操作。

　　...session 0x159...0xced create '/test_log,... 。表示创建/test_log节点，数据内容为#7631(v1)。

　　...session 0x159...0xcee setData ‘/test_log,...。表示设置了/test_log节点数据，内容为#7632(v2)。

　　...session 0x159...0xcef create ’/test_log/c,...。表示创建节点/test_log/c。

　　...session 0x159...0xcf0 delete '/test_log/c。表示删除节点/test_log/c。

　　3. 日志写入

　　FileTxnLog负责维护事务日志对外的接口，包括事务日志的写入和读取等。Zookeeper的事务日志写入过程大体可以分为如下6个步骤。

　　(1) 确定是否有事务日志可写。当Zookeeper服务器启动完成需要进行第一次事务日志的写入，或是上一次事务日志写满时，都会处于与事务日志文件断开的状态，即Zookeeper服务器没有和任意一个日志文件相关联。因此在进行事务日志写入前，Zookeeper首先会判断FileTxnLog组件是否已经关联上一个可写的事务日志文件。若没有，则会使用该事务操作关联的ZXID作为后缀创建一个事务日志文件，同时构建事务日志的文件头信息，并立即写入这个事务日志文件中去，同时将该文件的文件流放入streamToFlush集合，该集合用来记录当前需要强制进行数据落盘的文件流。

　　(2) 确定事务日志文件是否需要扩容(预分配)。Zookeeper会采用磁盘空间预分配策略。当检测到当前事务日志文件剩余空间不足4096字节时，就会开始进行文件空间扩容，即在现有文件大小上，将文件增加65536KB(64MB)，然后使用"0"填充被扩容的文件空间。

　　(3) 事务序列化。对事务头和事务体的序列化，其中事务体又可分为会话创建事务、节点创建事务、节点删除事务、节点数据更新事务等。

　　(4) 生成Checksum。为保证日志文件的完整性和数据的准确性，Zookeeper在将事务日志写入文件前，会计算生成Checksum。

　　(5) 写入事务日志文件流。将序列化后的事务头、事务体和Checksum写入文件流中，此时并为写入到磁盘上。

　　(6) 事务日志刷入磁盘。由于步骤5中的缓存原因，无法实时地写入磁盘文件中，因此需要将缓存数据强制刷入磁盘。

　　4. 日志截断

　　在Zookeeper运行过程中，可能出现非Leader记录的事务ID比Leader上大，这是非法运行状态。此时，需要保证所有机器必须与该Leader的数据保持同步，即Leader会发送TRUNC命令给该机器，要求进行日志截断，Learner收到该命令后，就会删除所有包含或大于该事务ID的事务日志文件。

　　2.3 snapshot-数据快照

　　数据快照是Zookeeper数据存储中非常核心的运行机制，数据快照用来记录Zookeeper服务器上某一时刻的全量内存数据内容，并将其写入指定的磁盘文件中。

　　1. 文件存储

　　与事务文件类似，Zookeeper快照文件也可以指定特定磁盘目录，通过dataDir属性来配置。若指定dataDir为/home/admin/zkData/zk_data，则在运行过程中会在该目录下创建version-2的目录，该目录确定了当前Zookeeper使用的快照数据格式版本号。在Zookeeper运行时，会生成一系列文件。

　　2. 数据快照

　　FileSnap负责维护快照数据对外的接口，包括快照数据的写入和读取等，将内存数据库写入快照数据文件其实是一个序列化过程。针对客户端的每一次事务操作，Zookeeper都会将他们记录到事务日志中，同时也会将数据变更应用到内存数据库中，Zookeeper在进行若干次事务日志记录后，将内存数据库的全量数据Dump到本地文件中，这就是数据快照。其步骤如下

　　(1) 确定是否需要进行数据快照。每进行一次事务日志记录之后，Zookeeper都会检测当前是否需要进行数据快照，考虑到数据快照对于Zookeeper机器的影响，需要尽量避免Zookeeper集群中的所有机器在同一时刻进行数据快照。采用过半随机策略进行数据快照操作。

　　(2) 切换事务日志文件。表示当前的事务日志已经写满，需要重新创建一个新的事务日志。

　　(3) 创建数据快照异步线程。创建单独的异步线程来进行数据快照以避免影响Zookeeper主流程。

　　(4) 获取全量数据和会话信息。从ZKDatabase中获取到DataTree和会话信息。

　　(5) 生成快照数据文件名。Zookeeper根据当前已经提交的最大ZXID来生成数据快照文件名。

　　(6) 数据序列化。首先序列化文件头信息，然后再对会话信息和DataTree分别进行序列化，同时生成一个Checksum，一并写入快照数据文件中去。

　　2.4 初始化

　　在Zookeeper服务器启动期间，首先会进行数据初始化工作，用于将存储在磁盘上的数据文件加载到Zookeeper服务器内存中。

　　1. 初始化流程

　　Zookeeper的书初始化过程如下图所示

　　数据的初始化工作是从磁盘上加载数据的过程，主要包括了从快照文件中加载快照数据和根据实物日志进行数据修正两个过程。

　　(1) 初始化FileTxnSnapLog。FileTxnSnapLog是Zookeeper事务日志和快照数据访问层，用于衔接上层业务和底层数据存储，底层数据包含了事务日志和快照数据两部分。FileTxnSnapLog中对应FileTxnLog和FileSnap。

　　(2) 初始化ZKDatabase。首先构建DataTree，同时将FileTxnSnapLog交付ZKDatabase，以便内存数据库能够对事务日志和快照数据进行访问。在ZKDatabase初始化时，DataTree也会进行相应的初始化工作，如创建一些默认结点，如/、/zookeeper、/zookeeper/quota三个节点。

　　(3) 创建PlayBackListener。其主要用来接收事务应用过程中的回调，在Zookeeper数据恢复后期，会有事务修正过程，此过程会回调PlayBackListener来进行对应的数据修正。

　　(4) 处理快照文件。此时可以从磁盘中恢复数据了，首先从快照文件开始加载。

　　(5) 获取最新的100个快照文件。更新时间最晚的快照文件包含了最新的全量数据。

　　(6) 解析快照文件。逐个解析快照文件，此时需要进行反序列化，生成DataTree和sessionsWithTimeouts，同时还会校验Checksum及快照文件的正确性。对于100个快找文件，如果正确性校验通过时，通常只会解析最新的那个快照文件。只有最新快照文件不可用时，才会逐个进行解析，直至100个快照文件全部解析完。若将100个快照文件解析完后还是无法成功恢复一个完整的DataTree和sessionWithTimeouts，此时服务器启动失败。

　　(7) 获取最新的ZXID。此时根据快照文件的文件名即可解析出最新的ZXID：zxid_for_snap。该ZXID代表了Zookeeper开始进行数据快照的时刻。

　　(8) 处理事务日志。此时服务器内存中已经有了一份近似全量的数据，现在开始通过事务日志来更新增量数据。

　　(9) 获取所有zxid_for_snap之后提交的事务。此时，已经可以获取快照数据的最新ZXID。只需要从事务日志中获取所有ZXID比步骤7得到的ZXID大的事务操作。

　　(10) 事务应用。获取大于zxid_for_snap的事务后，将其逐个应用到之前基于快照数据文件恢复出来的DataTree和sessionsWithTimeouts。每当有一个事务被应用到内存数据库中后，Zookeeper同时会回调PlayBackListener，将这事务操作记录转换成Proposal，并保存到ZKDatabase的committedLog中，以便Follower进行快速同步。

　　(11) 获取最新的ZXID。待所有的事务都被完整地应用到内存数据库中后，也就基本上完成了数据的初始化过程，此时再次获取ZXID，用来标识上次服务器正常运行时提交的最大事务ID。

　　(12) 校验epoch。epoch标识了当前Leader周期，集群机器相互通信时，会带上这个epoch以确保彼此在同一个Leader周期中。完成数据加载后，Zookeeper会从步骤11中确定ZXID中解析出事务处理的Leader周期：epochOfZxid。同时也会从磁盘的currentEpoch和acceptedEpoch文件中读取上次记录的最新的epoch值，进行校验。

　　2.5 数据同步

　　整个集群完成Leader选举后，Learner会向Leader进行注册，当Learner向Leader完成注册后，就进入数据同步环节，同步过程就是Leader将那些没有在Learner服务器上提交过的事务请求同步给Learner服务器，大体过程如下

　　(1) 获取Learner状态。在注册Learner的最后阶段，Learner服务器会发送给Leader服务器一个ACKEPOCH数据包，Leader会从这个数据包中解析出该Learner的currentEpoch和lastZxid。

　　(2) 数据同步初始化。首先从Zookeeper内存数据库中提取出事务请求对应的提议缓存队列proposals，同时完成peerLastZxid(该Learner最后处理的ZXID)、minCommittedLog(Leader提议缓存队列commitedLog中最小的ZXID)、maxCommittedLog(Leader提议缓存队列commitedLog中的最大ZXID)三个ZXID值的初始化。

　　对于集群数据同步而言，通常分为四类，直接差异化同步(DIFF同步)、先回滚再差异化同步(TRUNC+DIFF同步)、仅回滚同步(TRUNC同步)、全量同步(SNAP同步)，在初始化阶段，Leader会优先以全量同步方式来同步数据。同时，会根据Leader和Learner之间的数据差异情况来决定最终的数据同步方式。

　　· 直接差异化同步(DIFF同步，peerLastZxid介于minCommittedLog和maxCommittedLog之间)。Leader首先向这个Learner发送一个DIFF指令，用于通知Learner进入差异化数据同步阶段，Leader即将把一些Proposal同步给自己，针对每个Proposal，Leader都会通过发送PROPOSAL内容数据包和COMMIT指令数据包来完成，

　　· 先回滚再差异化同步(TRUNC+DIFF同步，Leader已经将事务记录到本地事务日志中，但是没有成功发起Proposal流程)。当Leader发现某个Learner包含了一条自己没有的事务记录，那么就需要该Learner进行事务回滚，回滚到Leader服务器上存在的，同时也是最接近于peerLastZxid的ZXID。

　　· 仅回滚同步(TRUNC同步，peerLastZxid大于maxCommittedLog)。Leader要求Learner回滚到ZXID值为maxCommittedLog对应的事务操作。

　　· 全量同步(SNAP同步，peerLastZxid小于minCommittedLog或peerLastZxid不等于lastProcessedZxid)。Leader无法直接使用提议缓存队列和Learner进行同步，因此只能进行全量同步。Leader将本机的全量内存数据同步给Learner。Leader首先向Learner发送一个SNAP指令，通知Learner即将进行全量同步，随后，Leader会从内存数据库中获取到全量的数据节点和会话超时时间记录器，将他们序列化后传输给Learner。Learner接收到该全量数据后，会对其反序列化后载入到内存数据库中。

三、总结

　　本篇博文主要讲解了Zookeeper的数据与存储，包括内存数据，快照数据，以及如何进行数据的同步等细节，至此，Zookeeper的理论学习部分已经全部完成，之后会进行源码分析，也谢谢各位园友的观看~

一、前言

　　在前面学习了Zookeeper中服务器的三种角色及其之间的通信，接着学习对于客户端的一次请求，Zookeeper是如何进行处理的。

二、请求处理

　　2.1 会话创建请求

　　Zookeeper服务端对于会话创建的处理，大体可以分为请求接收、会话创建、预处理、事务处理、事务应用和会话响应六大环节，其大体流程如

　　1. 请求接收

　　(1) I/O层接收来自客户端的请求。NIOServerCnxn维护每一个客户端连接，客户端与服务器端的所有通信都是由NIOServerCnxn负责，其负责统一接收来自客户端的所有请求，并将请求内容从底层网络I/O中完整地读取出来。

　　(2) 判断是否是客户端会话创建请求。每个会话对应一个NIOServerCnxn实体，对于每个请求，Zookeeper都会检查当前NIOServerCnxn实体是否已经被初始化，如果尚未被初始化，那么就可以确定该客户端一定是会话创建请求。

　　(3) 反序列化ConnectRequest请求。一旦确定客户端请求是否是会话创建请求，那么服务端就可以对其进行反序列化，并生成一个ConnectRequest载体。

　　(4) 判断是否是ReadOnly客户端。如果当前Zookeeper服务器是以ReadOnly模式启动，那么所有来自非ReadOnly型客户端的请求将无法被处理。因此，服务端需要先检查是否是ReadOnly客户端，并以此来决定是否接受该会话创建请求。

　　(5) 检查客户端ZXID。正常情况下，在一个Zookeeper集群中，服务端的ZXID必定大于客户端的ZXID，因此若发现客户端的ZXID大于服务端ZXID，那么服务端不接受该客户端的会话创建请求。

　　(6) 协商sessionTimeout。在客户端向服务器发送超时时间后，服务器会根据自己的超时时间限制最终确定该会话超时时间，这个过程就是sessionTimeout协商过程。

　　(7) 判断是否需要重新激活创建会话。服务端根据客户端请求中是否包含sessionID来判断该客户端是否需要重新创建会话，若客户单请求中包含sessionID，那么就认为该客户端正在进行会话重连，这种情况下，服务端只需要重新打开这个会话，否则需要重新创建。

　　2. 会话创建

　　(1) 为客户端生成sessionID。在为客户端创建会话之前，服务端首先会为每个客户端分配一个sessionID，服务端为客户端分配的sessionID是全局唯一的。

　　(2) 注册会话。向SessionTracker中注册会话，SessionTracker中维护了sessionsWithTimeout和sessionsById，在会话创建初期，会将客户端会话的相关信息保存到这两个数据结构中。

　　(3) 激活会话。激活会话涉及Zookeeper会话管理的分桶策略，其核心是为会话安排一个区块，以便会话清理程序能够快速高效地进行会话清理。

　　(4) 生成会话密码。服务端在创建一个客户端会话时，会同时为客户端生成一个会话密码，连同sessionID一同发给客户端，作为会话在集群中不同机器间转移的凭证。

　　3. 预处理

　　(1) 将请求交给PrepRequestProcessor处理器处理。在提交给第一个请求处理器之前，Zookeeper会根据该请求所属的会话，进行一次激活会话操作，以确保当前会话处于激活状态，完成会话激活后，则提交请求至处理器。

　　(2) 创建请求事务头。对于事务请求，Zookeeper会为其创建请求事务头，服务端后续的请求处理器都是基于该请求头来识别当前请求是否是事务请求，请求事务头包含了一个事务请求最基本的一些信息，包括sessionID、ZXID（事务请求对应的事务ZXID）、CXID（客户端的操作序列）和请求类型（如create、delete、setData、createSession等）等。

　　(3) 创建请求事务体。由于此时是会话创建请求，其事务体是CreateSessionTxn。

　　(4) 注册于激活会话。处理由非Leader服务器转发过来的会话创建请求。

　　4. 事务处理

　　(1) 将请求交给ProposalRequestProcessor处理器。与提议相关的处理器，从ProposalRequestProcessor开始，请求的处理将会进入三个子处理流程，分别是Sync流程、Proposal流程、Commit流程。

　　Sync流程

　　使用SyncRequestProcessor处理器记录事务日志，针对每个事务请求，都会通过事务日志的形式将其记录，完成日志记录后，每个Follower都会向Leader发送ACK消息，表明自身完成了事务日志的记录，以便Leader统计每个事务请求的投票情况。

　　Proposal流程

　　每个事务请求都需要集群中过半机器投票认可才能被真正应用到内存数据库中，这个投票与统计过程就是Proposal流程。

　　　　· 发起投票。若当前请求是事务请求，Leader会发起一轮事务投票，在发起事务投票之前，会检查当前服务端的ZXID是否可用。

　　　　· 生成提议Proposal。若ZXID可用，Zookeeper会将已创建的请求头和事务体以及ZXID和请求本身序列化到Proposal对象中，此Proposal对象就是一个提议。

　　　　· 广播提议。Leader以ZXID作为标识，将该提议放入投票箱outstandingProposals中，同时将该提议广播给所有Follower。

　　　　· 收集投票。Follower接收到Leader提议后，进入Sync流程进行日志记录，记录完成后，发送ACK消息至Leader服务器，Leader根据这些ACK消息来统计每个提议的投票情况，当一个提议获得半数以上投票时，就认为该提议通过，进入Commit阶段。

　　　　· 将请求放入toBeApplied队列中。

　　　　· 广播Commit消息。Leader向Follower和Observer发送COMMIT消息。向Observer发送INFORM消息，向Leader发送ZXID。

　　Commit流程

　　　　· 将请求交付CommitProcessor。CommitProcessor收到请求后，将其放入queuedRequests队列中。

　　　　· 处理queuedRequest队列请求。CommitProcessor中单独的线程处理queuedRequests队列中的请求。

　　　　· 标记nextPending。若从queuedRequests中取出的是事务请求，则需要在集群中进行投票处理，同时将nextPending标记位当前请求。

　　　　· 等待Proposal投票。在进行Commit流程的同时，Leader会生成Proposal并广播给所有Follower服务器，此时，Commit流程等待，直到投票结束。

　　　　· 投票通过。若提议获得过半机器认可，则进入请求提交阶段，该请求会被放入commitedRequests队列中，同时唤醒Commit流程。

　　　　· 提交请求。若commitedRequests队列中存在可以提交的请求，那么Commit流程则开始提交请求，将请求放入toProcess队列中，然后交付下一个请求处理器：FinalRequestProcessor。

　　5. 事务应用

　　(1) 交付给FinalRequestProcessor处理器。FinalRequestProcessor处理器检查outstandingChanges队列中请求的有效性，若发现这些请求已经落后于当前正在处理的请求，那么直接从outstandingChanges队列中移除。

　　(2) 事务应用。之前的请求处理仅仅将事务请求记录到了事务日志中，而内存数据库中的状态尚未改变，因此，需要将事务变更应用到内存数据库。

　　(3) 将事务请求放入队列commitProposal。完成事务应用后，则将该请求放入commitProposal队列中，commitProposal用来保存最近被提交的事务请求，以便集群间机器进行数据的快速同步。

　　6. 会话响应

　　(1) 统计处理。Zookeeper计算请求在服务端处理所花费的时间，统计客户端连接的基本信息，如lastZxid(最新的ZXID)、lastOp(最后一次和服务端的操作)、lastLatency(最后一次请求处理所花费的时间)等。

　　(2) 创建响应ConnectResponse。会话创建成功后的响应，包含了当前客户端和服务端之间的通信协议版本号、会话超时时间、sessionID和会话密码。

　　(3) 序列化ConnectResponse。

　　(4) I/O层发送响应给客户端。

　　2.2 SetData请求

　　服务端对于SetData请求大致可以分为四步，预处理、事务处理、事务应用、请求响应。

　　1. 预处理

　　(1) I/O层接收来自客户端的请求。

　　(2) 判断是否是客户端"会话创建"请求。对于SetData请求，按照正常事务请求进行处理。

　　(3) 将请求交给PrepRequestProcessor处理器进行处理。

　　(4) 创建请求事务头。

　　(5) 会话检查。检查该会话是否有效。

　　(6) 反序列化请求，并创建ChangeRecord记录。反序列化并生成特定的SetDataRequest请求，请求中包含了数据节点路径path、更新的内容data和期望的数据节点版本version。同时根据请求对应的path，Zookeeper生成一个ChangeRecord记录，并放入outstandingChanges队列中。

　　(7) ACL检查。检查客户端是否具有数据更新的权限。

　　(8) 数据版本检查。通过version属性来实现乐观锁机制的写入校验。

　　(9) 创建请求事务体SetDataTxn。

　　(10) 保存事务操作到outstandingChanges队列中。

　　2. 事务处理

　　对于事务请求，服务端都会发起事务处理流程。所有事务请求都是由ProposalRequestProcessor处理器处理，通过Sync、Proposal、Commit三个子流程相互协作完成。

　　3. 事务应用

　　(1) 交付给FinalRequestProcessor处理器。

　　(2) 事务应用。将请求事务头和事务体直接交给内存数据库ZKDatabase进行事务应用，同时返回ProcessTxnResult对象，包含了数据节点内容更新后的stat。

　　(3) 将事务请求放入commitProposal队列。

　　4. 请求响应

　　(1) 创建响应体SetDataResponse。其包含了当前数据节点的最新状态stat。

　　(2) 创建响应头。包含当前响应对应的事务ZXID和请求处理是否成功的标识。

　　(3) 序列化响应。

　　(4) I/O层发送响应给客户端。

　　2.3 GetData请求

　　服务端对于GetData请求的处理，大致分为三步，预处理、非事务处理、请求响应。

　　1. 预处理

　　(1) I/O层接收来自客户端的请求。

　　(2) 判断是否是客户端"会话创建"请求。

　　(3) 将请求交给PrepRequestProcessor处理器进行处理。

　　(4) 会话检查。

　　2. 非事务处理

　　(1) 反序列化GetDataRequest请求。

　　(2) 获取数据节点。

　　(3) ACL检查。

　　(4) 获取数据内容和stat，注册Watcher。

　　3. 请求响应

　　(1) 创建响应体GetDataResponse。响应体包含当前数据节点的内容和状态stat。

　　(2) 创建响应头。

　　(3) 统计处理。

　　(4) 序列化响应。

　　(5) I/O层发送响应给客户端。

三、总结

　　本篇博文讲解了Zookeeper服务端对于客户端不同请求的处理的具体流程，可能从文字上看步骤会显得相对枯燥，但是会为之后的源码分析打下很好的基础，谢谢各位园友的观看~

一、前言

　　前面学习了Zookeeper服务端的相关细节，其中对于集群启动而言，很重要的一部分就是Leader选举，接着就开始深入学习Leader选举。

二、Leader选举

　　2.1 Leader选举概述

　　Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

　　(1) 服务器初始化启动。

　　(2) 服务器运行期间无法和Leader保持连接。

　　下面就两种情况进行分析讲解。

　　1. 服务器启动时期的Leader选举

　　若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二胎服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

　　(1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

　　(2) 接受来自各个服务的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

　　(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下

　　　　· 优先检查ZXID。ZXID比较大的服务器优先作为Leader。

　　　　· 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

　　对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

　　(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

　　(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

　　2. 服务器运行时期的Leader选举

　　在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下

　　(1) 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。

　　(2) 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为123，Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。

　　(3) 接收来自各个服务器的投票。与启动时过程相同。

　　(4) 处理投票。与启动时过程相同，此时，Server1将会成为Leader。

　　(5) 统计投票。与启动时过程相同。

　　(6) 改变服务器的状态。与启动时过程相同。

　　2.2 Leader选举算法分析

　　在3.4.0后的Zookeeper的版本只保留了TCP版本的FastLeaderElection选举算法。当一台机器进入Leader选举时，当前集群可能会处于以下两种状态

　　　　· 集群中已经存在Leader。

　　　　· 集群中不存在Leader。

　　对于集群中已经存在Leader而言，此种情况一般都是某台机器启动得较晚，在其启动之前，集群已经在正常工作，对这种情况，该机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器而言，仅仅需要和Leader机器建立起连接，并进行状态同步即可。而在集群中不存在Leader情况下则会相对复杂，其步骤如下

　　(1) 第一次投票。无论哪种导致进行Leader选举，集群的所有机器都处于试图选举出一个Leader的状态，即LOOKING状态，LOOKING机器会向所有其他机器发送消息，该消息称为投票。投票中包含了SID（服务器的唯一标识）和ZXID（事务ID），(SID, ZXID)形式来标识一次投票信息。假定Zookeeper由5台机器组成，SID分别为1、2、3、4、5，ZXID分别为9、9、9、8、8，并且此时SID为2的机器是Leader机器，某一时刻，1、2所在机器出现故障，因此集群开始进行Leader选举。在第一次投票时，每台机器都会将自己作为投票对象，于是SID为3、4、5的机器投票情况分别为(3, 9)，(4, 8)， (5, 8)。

　　(2) 变更投票。每台机器发出投票后，也会收到其他机器的投票，每台机器会根据一定规则来处理收到的其他机器的投票，并以此来决定是否需要变更自己的投票，这个规则也是整个Leader选举算法的核心所在，其中术语描述如下

　　　　· vote_sid：接收到的投票中所推举Leader服务器的SID。

　　　　· vote_zxid：接收到的投票中所推举Leader服务器的ZXID。

　　　　· self_sid：当前服务器自己的SID。

　　　　· self_zxid：当前服务器自己的ZXID。

　　每次对收到的投票的处理，都是对(vote_sid, vote_zxid)和(self_sid, self_zxid)对比的过程。

　　　　规则一：如果vote_zxid大于self_zxid，就认可当前收到的投票，并再次将该投票发送出去。

　　　　规则二：如果vote_zxid小于self_zxid，那么坚持自己的投票，不做任何变更。

　　　　规则三：如果vote_zxid等于self_zxid，那么就对比两者的SID，如果vote_sid大于self_sid，那么就认可当前收到的投票，并再次将该投票发送出去。

　　　　规则四：如果vote_zxid等于self_zxid，并且vote_sid小于self_sid，那么坚持自己的投票，不做任何变更。

　　结合上面规则，给出下面的集群变更过程。

　　(3) 确定Leader。经过第二轮投票后，集群中的每台机器都会再次接收到其他机器的投票，然后开始统计投票，如果一台机器收到了超过半数的相同投票，那么这个投票对应的SID机器即为Leader。此时Server3将成为Leader。

　　由上面规则可知，通常那台服务器上的数据越新（ZXID会越大），其成为Leader的可能性越大，也就越能够保证数据的恢复。如果ZXID相同，则SID越大机会越大。

　　2.3 Leader选举实现细节

　　1. 服务器状态

　　服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。

　　LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。

　　FOLLOWING：跟随者状态。表明当前服务器角色是Follower。

　　LEADING：领导者状态。表明当前服务器角色是Leader。

　　OBSERVING：观察者状态。表明当前服务器角色是Observer。

　　2. 投票数据结构

　　每个投票中包含了两个最基本的信息，所推举服务器的SID和ZXID，投票（Vote）在Zookeeper中包含字段如下

　　id：被推举的Leader的SID。

　　zxid：被推举的Leader事务ID。

　　electionEpoch：逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作。

　　peerEpoch：被推举的Leader的epoch。

　　state：当前服务器的状态。

　　3. QuorumCnxManager：网络I/O

　　每台服务器在启动的过程中，会启动一个QuorumPeerManager，负责各台服务器之间的底层Leader选举过程中的网络通信。

　　(1) 消息队列。QuorumCnxManager内部维护了一系列的队列，用来保存接收到的、待发送的消息以及消息的发送器，除接收队列以外，其他队列都按照SID分组形成队列集合，如一个集群中除了自身还有3台机器，那么就会为这3台机器分别创建一个发送队列，互不干扰。

　　　　· recvQueue：消息接收队列，用于存放那些从其他服务器接收到的消息。

　　　　· queueSendMap：消息发送队列，用于保存那些待发送的消息，按照SID进行分组。

　　　　· senderWorkerMap：发送器集合，每个SenderWorker消息发送器，都对应一台远程Zookeeper服务器，负责消息的发送，也按照SID进行分组。

　　　　· lastMessageSent：最近发送过的消息，为每个SID保留最近发送过的一个消息。

　　(2) 建立连接。为了能够相互投票，Zookeeper集群中的所有机器都需要两两建立起网络连接。QuorumCnxManager在启动时会创建一个ServerSocket来监听Leader选举的通信端口(默认为3888)。开启监听后，Zookeeper能够不断地接收到来自其他服务器的创建连接请求，在接收到其他服务器的TCP连接请求时，会进行处理。为了避免两台机器之间重复地创建TCP连接，Zookeeper只允许SID大的服务器主动和其他机器建立连接，否则断开连接。在接收到创建连接请求后，服务器通过对比自己和远程服务器的SID值来判断是否接收连接请求，如果当前服务器发现自己的SID更大，那么会断开当前连接，然后自己主动和远程服务器建立连接。一旦连接建立，就会根据远程服务器的SID来创建相应的消息发送器SendWorker和消息接收器RecvWorker，并启动。

　　(3) 消息接收与发送。消息接收：由消息接收器RecvWorker负责，由于Zookeeper为每个远程服务器都分配一个单独的RecvWorker，因此，每个RecvWorker只需要不断地从这个TCP连接中读取消息，并将其保存到recvQueue队列中。消息发送：由于Zookeeper为每个远程服务器都分配一个单独的SendWorker，因此，每个SendWorker只需要不断地从对应的消息发送队列中获取出一个消息发送即可，同时将这个消息放入lastMessageSent中。在SendWorker中，一旦Zookeeper发现针对当前服务器的消息发送队列为空，那么此时需要从lastMessageSent中取出一个最近发送过的消息来进行再次发送，这是为了解决接收方在消息接收前或者接收到消息后服务器挂了，导致消息尚未被正确处理。同时，Zookeeper能够保证接收方在处理消息时，会对重复消息进行正确的处理。

　　4. FastLeaderElection：选举算法核心

　　· 外部投票：特指其他服务器发来的投票。

　　· 内部投票：服务器自身当前的投票。

　　· 选举轮次：Zookeeper服务器Leader选举的轮次，即logicalclock。

　　· PK：对内部投票和外部投票进行对比来确定是否需要变更内部投票。

　　(1) 选票管理

　　· sendqueue：选票发送队列，用于保存待发送的选票。

　　· recvqueue：选票接收队列，用于保存接收到的外部投票。

　　· WorkerReceiver：选票接收器。其会不断地从QuorumCnxManager中获取其他服务器发来的选举消息，并将其转换成一个选票，然后保存到recvqueue中，在选票接收过程中，如果发现该外部选票的选举轮次小于当前服务器的，那么忽略该外部投票，同时立即发送自己的内部投票。

　　· WokerSender：选票发送器，不断地从sendqueue中获取待发送的选票，并将其传递到底层QuorumCnxManager中。

　　(2) 算法核心

　　上图展示了FastLeaderElection模块是如何与底层网络I/O进行交互的。Leader选举的基本流程如下

　　1. 自增选举轮次。Zookeeper规定所有有效的投票都必须在同一轮次中，在开始新一轮投票时，会首先对logicalclock进行自增操作。

　　2. 初始化选票。在开始进行新一轮投票之前，每个服务器都会初始化自身的选票，并且在初始化阶段，每台服务器都会将自己推举为Leader。

　　3. 发送初始化选票。完成选票的初始化后，服务器就会发起第一次投票。Zookeeper会将刚刚初始化好的选票放入sendqueue中，由发送器WorkerSender负责发送出去。

　　4. 接收外部投票。每台服务器会不断地从recvqueue队列中获取外部选票。如果服务器发现无法获取到任何外部投票，那么就会立即确认自己是否和集群中其他服务器保持着有效的连接，如果没有连接，则马上建立连接，如果已经建立了连接，则再次发送自己当前的内部投票。

　　5. 判断选举轮次。在发送完初始化选票之后，接着开始处理外部投票。在处理外部投票时，会根据选举轮次来进行不同的处理。

　　　　· 外部投票的选举轮次大于内部投票。若服务器自身的选举轮次落后于该外部投票对应服务器的选举轮次，那么就会立即更新自己的选举轮次(logicalclock)，并且清空所有已经收到的投票，然后使用初始化的投票来进行PK以确定是否变更内部投票。最终再将内部投票发送出去。

　　　　· 外部投票的选举轮次小于内部投票。若服务器接收的外选票的选举轮次落后于自身的选举轮次，那么Zookeeper就会直接忽略该外部投票，不做任何处理，并返回步骤4。

　　　　· 外部投票的选举轮次等于内部投票。此时可以开始进行选票PK。

　　6. 选票PK。在进行选票PK时，符合任意一个条件就需要变更投票。

　　　　· 若外部投票中推举的Leader服务器的选举轮次大于内部投票，那么需要变更投票。

　　　　· 若选举轮次一致，那么就对比两者的ZXID，若外部投票的ZXID大，那么需要变更投票。

　　　　· 若两者的ZXID一致，那么就对比两者的SID，若外部投票的SID大，那么就需要变更投票。

　　7. 变更投票。经过PK后，若确定了外部投票优于内部投票，那么就变更投票，即使用外部投票的选票信息来覆盖内部投票，变更完成后，再次将这个变更后的内部投票发送出去。

　　8. 选票归档。无论是否变更了投票，都会将刚刚收到的那份外部投票放入选票集合recvset中进行归档。recvset用于记录当前服务器在本轮次的Leader选举中收到的所有外部投票（按照服务队的SID区别，如{(1, vote1), (2, vote2)...}）。

　　9. 统计投票。完成选票归档后，就可以开始统计投票，统计投票是为了统计集群中是否已经有过半的服务器认可了当前的内部投票，如果确定已经有过半服务器认可了该投票，则终止投票。否则返回步骤4。

　　10. 更新服务器状态。若已经确定可以终止投票，那么就开始更新服务器状态，服务器首选判断当前被过半服务器认可的投票所对应的Leader服务器是否是自己，若是自己，则将自己的服务器状态更新为LEADING，若不是，则根据具体情况来确定自己是FOLLOWING或是OBSERVING。

　　以上10个步骤就是FastLeaderElection的核心，其中步骤4-9会经过几轮循环，直到有Leader选举产生。

三、总结

　　经过本篇博文的学习，了解了Leader选举的具体细节，这对于之后的代码分析会打下很好的基础。也谢谢各位园友的观看~

一、前言

　　前一篇已经详细的讲解了Zookeeper的Leader选举过程，下面接着学习Zookeeper中服务器的各个角色及其细节。

二、服务器角色

　　2.1 Leader

　　Leader服务器是Zookeeper集群工作的核心，其主要工作如下

　　(1) 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。

　　(2) 集群内部各服务器的调度者。

　　1. 请求处理链

　　使用责任链来处理每个客户端的请求时Zookeeper的特色，Leader服务器的请求处理链如下

　　(1) PrepRequestProcessor。请求预处理器。在Zookeeper中，那些会改变服务器状态的请求称为事务请求（创建节点、更新数据、删除节点、创建会话等），PrepRequestProcessor能够识别出当前客户端请求是否是事务请求。对于事务请求，PrepRequestProcessor处理器会对其进行一系列预处理，如创建请求事务头、事务体、会话检查、ACL检查和版本检查等。

　　(2) ProposalRequestProcessor。事务投票处理器。Leader服务器事务处理流程的发起者，对于非事务性请求，ProposalRequestProcessor会直接将请求转发到CommitProcessor处理器，不再做任何处理，而对于事务性请求，处理将请求转发到CommitProcessor外，还会根据请求类型创建对应的Proposal提议，并发送给所有的Follower服务器来发起一次集群内的事务投票。同时，ProposalRequestProcessor还会将事务请求交付给SyncRequestProcessor进行事务日志的记录。

　　(2) SyncRequestProcessor。事务日志记录处理器。用来将事务请求记录到事务日志文件中，同时会触发Zookeeper进行数据快照。

　　(3) AckRequestProcessor。负责在SyncRequestProcessor完成事务日志记录后，向Proposal的投票收集器发送ACK反馈，以通知投票收集器当前服务器已经完成了对该Proposal的事务日志记录。

　　(4) CommitProcessor。事务提交处理器。对于非事务请求，该处理器会直接将其交付给下一级处理器处理；对于事务请求，其会等待集群内针对Proposal的投票直到该Proposal可被提交，利用CommitProcessor，每个服务器都可以很好地控制对事务请求的顺序处理。

　　(5) ToBeCommitProcessor。该处理器有一个toBeApplied队列，用来存储那些已经被CommitProcessor处理过的可被提交的Proposal。其会将这些请求交付给FinalRequestProcessor处理器处理，待其处理完后，再将其从toBeApplied队列中移除。

　　(6) FinalRequestProcessor。用来进行客户端请求返回之前的操作，包括创建客户端请求的响应，针对事务请求，该处理还会负责将事务应用到内存数据库中去。

　　2. LearnerHandler

　　为了保证整个集群内部的实时通信，同时为了确保可以控制所有的Follower/Observer服务器，Leader服务器会与每个Follower/Observer服务器建立一个TCP长连接。同时也会为每个Follower/Observer服务器创建一个名为LearnerHandler的实体。LearnerHandler是Learner服务器的管理者，主要负责Follower/Observer服务器和Leader服务器之间的一系列网络通信，包括数据同步、请求转发和Proposal提议的投票等。Leader服务器中保存了所有Follower/Observer对应的LearnerHandler。

　　2.2 Follower

　　Follower是Zookeeper集群的跟随者，其主要工作如下

　　(1) 处理客户端非事务性请求（读取数据），转发事务请求给Leader服务器。

　　(2) 参与事务请求Proposal的投票。

　　(3) 参与Leader选举投票。

　　Follower也采用了责任链模式组装的请求处理链来处理每一个客户端请求，由于不需要对事务请求的投票处理，因此Follower的请求处理链会相对简单，其处理链如下

　　(1) FollowerRequestProcessor。其用作识别当前请求是否是事务请求，若是，那么Follower就会将该请求转发给Leader服务器，Leader服务器是在接收到这个事务请求后，就会将其提交到请求处理链，按照正常事务请求进行处理。

　　(2) SendAckRequestProcessor。其承担了事务日志记录反馈的角色，在完成事务日志记录后，会向Leader服务器发送ACK消息以表明自身完成了事务日志的记录工作。

　　2.3 Observer

　　Observer充当观察者角色，观察Zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器进行处理。Observer不会参与任何形式的投票，包括事务请求Proposal的投票和Leader选举投票。其处理链如下

　　2.4 集群间消息通信

　　Zookeeper的消息类型大体分为数据同步型、服务器初始化型、请求处理型和会话管理型。

　　(1) 数据同步型。指在Learner和Leader服务器进行数据同步时，网络通信所用到的消息，通常有DIFF、TRUNC、SNAP、UPTODATE。

　　(2) 服务器初始化型。指在整个集群或是某些新机器初始化时，Leader和Learner之间相互通信所使用的消息类型，常见的有OBSERVERINFO、FOLLOWERINFO、LEADERINFO、ACKEPOCH和NEWLEADER五种。

　　(3) 请求处理型。指在进行清理时，Leader和Learner服务器之间互相通信所使用的消息，常见的有REQUEST、PROPOSAL、ACK、COMMIT、INFORM和SYNC六种。

　　(4) 会话管理型。指Zookeeper在进行会话管理时和Learner服务器之间互相通信所使用的消息，常见的有PING和REVALIDATE两种。

三、总结

　　经过本篇博文的讲解，明白了服务器的各种角色及其作用，以及集群间如何进行通信。谢谢各位园友的观看~

一、前言

　　前面已经了解了Zookeeper会话相关知识点，接着来学习Zookeeper服务端相关细节。

二、服务端

　　服务端整体架构如下

　　Zookeeper服务器的启动，大致可以分为以下五个步骤

　　1. 配置文件解析。

　　2. 初始化数据管理器。

　　3. 初始化网络I/O管理器。

　　4. 数据恢复。

　　5. 对外服务。

　　2.1 单机版服务器启动

　　单机版服务器的启动其流程图如下

　　上图的过程可以分为预启动和初始化过程。

　　1. 预启动

　　　　1. 统一由QuorumPeerMain作为启动类。无论单机或集群，在zkServer.cmd和zkServer.sh中都配置了QuorumPeerMain作为启动入口类。

　　　　2. 解析配置文件zoo.cfg。zoo.cfg配置运行时的基本参数，如tickTime、dataDir、clientPort等参数。

　　　　3. 创建并启动历史文件清理器DatadirCleanupManager。对事务日志和快照数据文件进行定时清理。

　　　　4. 判断当前是集群模式还是单机模式启动。若是单机模式，则委托给ZooKeeperServerMain进行启动。

　　　　5. 再次进行配置文件zoo.cfg的解析。

　　　　6. 创建服务器实例ZooKeeperServer。Zookeeper服务器首先会进行服务器实例的创建，然后对该服务器实例进行初始化，包括连接器、内存数据库、请求处理器等组件的初始化。

　　2. 初始化

　　　　1. 创建服务器统计器ServerStats。ServerStats是Zookeeper服务器运行时的统计器。

　　　　2. 创建Zookeeper数据管理器FileTxnSnapLog。FileTxnSnapLog是Zookeeper上层服务器和底层数据存储之间的对接层，提供了一系列操作数据文件的接口，如事务日志文件和快照数据文件。Zookeeper根据zoo.cfg文件中解析出的快照数据目录dataDir和事务日志目录dataLogDir来创建FileTxnSnapLog。

　　　　3. 设置服务器tickTime和会话超时时间限制。

　　　　4. 创建ServerCnxnFactory。通过配置系统属性zookeper.serverCnxnFactory来指定使用Zookeeper自己实现的NIO还是使用Netty框架作为Zookeeper服务端网络连接工厂。

　　　　5. 初始化ServerCnxnFactory。Zookeeper会初始化Thread作为ServerCnxnFactory的主线程，然后再初始化NIO服务器。

　　　　6. 启动ServerCnxnFactory主线程。进入Thread的run方法，此时服务端还不能处理客户端请求。

　　　　7. 恢复本地数据。启动时，需要从本地快照数据文件和事务日志文件进行数据恢复。

　　　　8. 创建并启动会话管理器。Zookeeper会创建会话管理器SessionTracker进行会话管理。

　　　　9. 初始化Zookeeper的请求处理链。Zookeeper请求处理方式为责任链模式的实现。会有多个请求处理器依次处理一个客户端请求，在服务器启动时，会将这些请求处理器串联成一个请求处理链。

　　　　10. 注册JMX服务。Zookeeper会将服务器运行时的一些信息以JMX的方式暴露给外部。

　　　　11. 注册Zookeeper服务器实例。将Zookeeper服务器实例注册给ServerCnxnFactory，之后Zookeeper就可以对外提供服务。

　　至此，单机版的Zookeeper服务器启动完毕。

　　2.2 集群服务器启动

　　单机和集群服务器的启动在很多地方是一致的，其流程图如下

　　上图的过程可以分为预启动、初始化、Leader选举、Leader与Follower启动期交互过程、Leader与Follower启动等过程。

　　1. 预启动

　　　　1. 统一由QuorumPeerMain作为启动类。

　　　　2. 解析配置文件zoo.cfg。

　　　　3. 创建并启动历史文件清理器DatadirCleanupFactory。

　　　　4. 判断当前是集群模式还是单机模式的启动。在集群模式中，在zoo.cfg文件中配置了多个服务器地址，可以选择集群启动。

　　2. 初始化

　　　　1. 创建ServerCnxnFactory。

　　　　2. 初始化ServerCnxnFactory。

　　　　3. 创建Zookeeper数据管理器FileTxnSnapLog。

　　　　4. 创建QuorumPeer实例。Quorum是集群模式下特有的对象，是Zookeeper服务器实例（ZooKeeperServer）的托管者，QuorumPeer代表了集群中的一台机器，在运行期间，QuorumPeer会不断检测当前服务器实例的运行状态，同时根据情况发起Leader选举。

　　　　5. 创建内存数据库ZKDatabase。ZKDatabase负责管理ZooKeeper的所有会话记录以及DataTree和事务日志的存储。

　　　　6. 初始化QuorumPeer。将核心组件如FileTxnSnapLog、ServerCnxnFactory、ZKDatabase注册到QuorumPeer中，同时配置QuorumPeer的参数，如服务器列表地址、Leader选举算法和会话超时时间限制等。

　　　　7. 恢复本地数据。

　　　　8. 启动ServerCnxnFactory主线程。

　　3. Leader选举

　　　　1. 初始化Leader选举。集群模式特有，Zookeeper首先会根据自身的服务器ID（SID）、最新的ZXID（lastLoggedZxid）和当前的服务器epoch（currentEpoch）来生成一个初始化投票，在初始化过程中，每个服务器都会给自己投票。然后，根据zoo.cfg的配置，创建相应Leader选举算法实现，Zookeeper提供了三种默认算法（LeaderElection、AuthFastLeaderElection、FastLeaderElection），可通过zoo.cfg中的electionAlg属性来指定，但现只支持FastLeaderElection选举算法。在初始化阶段，Zookeeper会创建Leader选举所需的网络I/O层QuorumCnxManager，同时启动对Leader选举端口的监听，等待集群中其他服务器创建连接。

　　　　2. 注册JMX服务。

　　　　3. 检测当前服务器状态。运行期间，QuorumPeer会不断检测当前服务器状态。在正常情况下，Zookeeper服务器的状态在LOOKING、LEADING、FOLLOWING/OBSERVING之间进行切换。在启动阶段，QuorumPeer的初始状态是LOOKING，因此开始进行Leader选举。

　　　　4. Leader选举。通过投票确定Leader，其余机器称为Follower和Observer。具体算法在后面会给出。

　　4. Leader和Follower启动期交互过程

　　　　1. 创建Leader服务器和Follower服务器。完成Leader选举后，每个服务器会根据自己服务器的角色创建相应的服务器实例，并进入各自角色的主流程。

　　　　2. Leader服务器启动Follower接收器LearnerCnxAcceptor。运行期间，Leader服务器需要和所有其余的服务器（统称为Learner）保持连接以确集群的机器存活情况，LearnerCnxAcceptor负责接收所有非Leader服务器的连接请求。

　　　　3. Leader服务器开始和Leader建立连接。所有Learner会找到Leader服务器，并与其建立连接。

　　　　4. Leader服务器创建LearnerHandler。Leader接收到来自其他机器连接创建请求后，会创建一个LearnerHandler实例，每个LearnerHandler实例都对应一个Leader与Learner服务器之间的连接，其负责Leader和Learner服务器之间几乎所有的消息通信和数据同步。

　　　　5. 向Leader注册。Learner完成和Leader的连接后，会向Leader进行注册，即将Learner服务器的基本信息（LearnerInfo），包括SID和ZXID，发送给Leader服务器。

　　　　6. Leader解析Learner信息，计算新的epoch。Leader接收到Learner服务器基本信息后，会解析出该Learner的SID和ZXID，然后根据ZXID解析出对应的epoch_of_learner，并和当前Leader服务器的epoch_of_leader进行比较，如果该Learner的epoch_of_learner更大，则更新Leader的epoch_of_leader = epoch_of_learner + 1。然后LearnHandler进行等待，直到过半Learner已经向Leader进行了注册，同时更新了epoch_of_leader后，Leader就可以确定当前集群的epoch了。

　　　　7. 发送Leader状态。计算出新的epoch后，Leader会将该信息以一个LEADERINFO消息的形式发送给Learner，并等待Learner的响应。

　　　　8. Learner发送ACK消息。Learner接收到LEADERINFO后，会解析出epoch和ZXID，然后向Leader反馈一个ACKEPOCH响应。

　　　　9. 数据同步。Leader收到Learner的ACKEPOCH后，即可进行数据同步。

　　　　10. 启动Leader和Learner服务器。当有过半Learner已经完成了数据同步，那么Leader和Learner服务器实例就可以启动了。

　　5. Leader和Follower启动

　　　　1. 创建启动会话管理器。

　　　　2. 初始化Zookeeper请求处理链，集群模式的每个处理器也会在启动阶段串联请求处理链。

　　　　3. 注册JMX服务。

　　至此，集群版的Zookeeper服务器启动完毕。

三、总结

　　本篇博文分析了Zookeeper服务端的启动的详细细节，之后会给出具体的代码分析。也谢谢各位园友的观看~

1. 介绍

不得不说ZK的出现是解决分布式一致性问题的一道曙光。但是事务都是发展的，即使是ZK也不是十全十美的。

今天和小伙伴聊了点ZK的问题。一些ZK使用攻略也希望在此跟大家分享下。

2. ZK的缺点

1. 读写性能不佳：ZK的读写性能测试可以参考 ZooKeeper service latencies under various loads & configurations

下图可以看到的是220万操作，在4核20client上的效果。简单总结是相同core，增加client整体性能会下降。

1. 不适合主数据存储：zk的quorum选举适用在共享集群配置而不是主数据存储。因为其吞吐量低，容忍故障所需要的冗余副本比较多
2. 只容忍（N-1）/2的故障
3. ZK设计的时候是基于session的，也就是基于TTL机制。保持会话需要不断续期TTL。后起之秀如etcd等都已通过grpc改进了TTL。后续我会专门聊聊etcd

3. ZK在实际应用中的问题

ZK在实际使用中肯能会受到网络抖动的影响，有时候这些影响对应用会造成“灾难”级的伤害。例如发生网络问题时，ZK集群需要开始选主，选主过程如果持续较长，应用都会抛异常。而且后续可能会出现follower不能及时跟上leader的情况。如果这个过程持续数十分钟，那么将会导致应用在这个期间内无法提供服务。影响是非常大的。

以上故事来自小伙伴的真实经历。但是到底哪些行为会造成ZK异常的选主行为尚没搞清楚。有谁知道也可以教下我。

Zookeeper是一个分布式协调框架，有不错的性能，也经过许多公司的验证，所以在很多场景都有使用。大家一般用Zookeeper来实现服务发现(类似DNS)，配置管理，分布式锁，leader选举等。在这些场景中，Zookeeper成为了一个被依赖的核心组件，Zookeeper的稳定性是需要特别关注的。

去哪儿网也在很多场景依赖Zookeeper，所以我们也一直在摸索怎么更好的运维稳定的Zookeeper集群。在过去的几年我们也踩过一些坑，也因为Zookeeper导致了故障。现在将我们运维Zookeeper集群的一些经验分享，也欢迎大家提供更好的建议。

那么在打算运维一套Zookeeper集群之前，我们先了解一些Zookeeper的基本原理。

1. 集群里分三种角色: Leader, Follower和Observer。Leader和Follower参与投票，Observer只会『听』投票的结果，不参与投票。

2. 投票集群里的节点数要求是奇数

3. 一个集群容忍挂掉的节点数的等式为 N = 2F + 1，N为投票集群节点数，F为能同时容忍失败节点数。比如一个三节点集群，可以挂掉一个节点，5节点集群可以挂掉两个...

4. 一个写操作需要半数以上的节点ack，所以集群节点数越多，整个集群可以抗挂点的节点数越多(越可靠)，但是吞吐量越差。

5. Zookeeper里所有节点以及节点的数据都会放在内存里，形成一棵树的数据结构。并且定时的dump snapshot到磁盘。

6. Zookeeper的Client与Zookeeper之间维持的是长连接，并且保持心跳，Client会与Zookeeper之间协商出一个Session超时时间出来(其实就是Zookeeper Server里配置了最小值，最大值，如果client的值在这两个值之间则采用client的，小于最小值就是最小值，大于最大值就用最大值)，如果在Session超时时间内没有收到心跳，则该Session过期。

7. Client可以watch Zookeeper那个树形数据结构里的某个节点或数据，当有变化的时候会得到通知。

有了这些了解后，那么我们心里其实有底了。

1. 最小生产集群

要确保Zookeeper能够稳定运行，那么就需要确保投票能够正常进行，最好不要挂一个节点整个就不work了，所以我们一般要求 最少5个节点部署 。

2. 网络

除了节点外，我们还要看不能一台物理机器，一个机柜或一个交换机挂掉然后影响了整个集群，所以节点的 网络结构也要考虑 。这个可能就比很多应用服务器的要求更加严格。

3. 分Group，保护核心Group

要确保Zookeeper整个集群可靠运行，就是要确保投票集群可靠。那在我们这里，将一个Zookeeper集群划分为多个小的Group ，我们称Leader+Follower为核心Group，核心Group我们一般是不向外提供服务的，然后我们会根据不同的业务再加一些Observer，比如一个Zookeeper集群为服务发现，消息，定时任务三个不同的组件提供服务，那么我们为建立三个Observer Group，分别给这三个组件使用，而Client只会连接分配给它的Observer Group，不去连接核心Group。这样核心Group就不会给Client提供长连接服务，也不负责长连接的心跳，这大大的减轻了核心Group的压力，因为在实际环境中，一个Zookeeper集群要为上万台机器提供服务，维持长连接和心跳还是要消耗一定的资源的。因为Observer是不参与投票的所以加Observer并不会降低整体的吞吐量，而且Observer挂掉不会影响整个集群的健康。

但是这里要注意的是，分Observer Group只能解决部分问题，因为毕竟所有的写入还是要交给核心Group来处理的，所以对于写入量特别大的应用来说，还是需要进行集群上的隔离，比如Storm和Kafka就对Zookeeper压力比较大，你就不能将其与服务发现的集群放在一起。

4. 内存

因为Zookeeper将所有数据都放在内存里，所以对JVM以及机器的内存也要预先计划，如果出现Swap那将严重的影响Zookeeper集群的性能，所以我一般不怎么推荐将Zookeeper用作通用的配置管理服务。因为一般配置数据还是挺大的，这些全部放在内存里不太可控。

5. 日志清理

因为Zookeeper要频繁的写txlog(Zookeeper写的一种顺序日志)以及定期dump内存snapshot到磁盘，这样磁盘占用就越来越大，所以Zookeeper提供了清理这些文件的机制，但是这种机制并不太合理，它只能设置间隔多久清理，而不能设置具体的时间段。那么就有可能碰到高峰期间清理，所以建议将其关闭:autopurge.purgeInterval=0。然后使用crontab等机制，在业务低谷的时候清理。

6. 日志，jvm配置

从官网直接下载的包如果直接启动运行是很糟糕的，这个包默认的配置日志是不会轮转的，而且是直接输出到终端。我们最开始并不了解这点，然后运行一段时间后发现生成一个庞大的zookeeper.out的日志文件。除此之外，这个默认配置还没有设置任何jvm相关的参数(所以堆大小是个默认值)，这也是不可取的。那么有的同学说那我去修改Zookeeper的启动脚本吧。最好不要这样做，Zookeeper会加载conf文件夹下一个名为zookeeper-env.sh的脚本，所以你可以将一些定制化的配置写在这里，而不是直接去修改Zookeeper自带的脚本。

#!/usr/bin/env bash

JAVA_HOME= #java home

ZOO_LOG_DIR= #日志文件放置的路径

ZOO_LOG4J_PROP="INFO,ROLLINGFILE" #设置日志轮转

JVMFLAGS="jvm的一些设置，比如堆大小，开gc log等"

7. 地址

在实际环境中，我们可能因为各种原因比如机器过保，硬件故障等需要迁移Zookeeper集群，所以Zookeeper的地址是一个很头痛的事情。这个地址有两方面，第一个是提供给Client的地址，建议这个地址通过配置的方式下发，不要让使用方直接使用，这一点我们前期做的不好。另外一个是集群配置里，集群之间需要通讯，也需要地址。我们的处理方式是设置hosts:

192.168.1.20 zk1

192.168.1.21 zk2

192.168.1.22 zk3

在配置里:

server.1=zk1:2081:3801

server.2=zk2:2801:3801

server.3=zk3:2801:3801

这样在需要迁移的时候，我们停老的节点，起新的节点只需要修改hosts映射就可以了。比如现在server.3需要迁移，那我们在hosts里将zk3映射到新的ip地址。但是对于java有一个问题是，java默认会永久缓存DNS cache，即使你将zk3映射到别的ip，如果并不重启server.1, server.2，它是不会解析到新的ip的，这个需要修改$JAVA_HOME/jre/lib/security/java.security文件里的networkaddress.cache.ttl=60，将其修改为一个比较小的数。

对于这个迁移的问题，我们还遇到一个比较尴尬的情况，在最后的坑里会有提及。

8. 日志位置

Zookeeper主要产生三种IO: txlog(每个写操作，包括新Session都会记录一条log)，Snapshot以及运行的应用日志。一般建议将这三个IO分散到三个不同的盘上。不过我们倒是一直没有这么实验过，我们的Zookeeper也是运行在虚拟机(一般认为虚拟机IO较差)上。

9. 监控

我们对Zookeeper做了这样一些监控:

a. 是否可写。 就是一个定时任务定时的去创建节点，删节点等操作。这里要注意的是Zookeeper是一个集群，我们监控的时候我还是希望对单个节点做监控，所以这些操作的时候不要连接整个集群，而是直接去连接单个节点。

b. 监控watcher数和连接数 特别是这两个数据有较大波动的时候，可以发现使用方是否有误用的情况

c. 网络流量以及client ip 这个会记录到监控系统里，这样很快能发现『害群之马』

10. 一些使用建议

a. 不要强依赖Zookeeper，也就是Zookeeper出现问题业务已然可以正常运行。Zookeeper是一个分布式的协调框架，主要做的事情就是分布式环境的一致性。这是一个非常苛刻的事情，所以它的稳定性受很多方面的影响。比如我们常常使用Zookeeper做服务发现，那么服务发现其实是不需要严格的一致性的，我们可以缓存server list，当Zookeeper出现问题的时候已然可以正常工作，在这方面etcd要做的更好一些，Zookeeper如果出现分区，少数派是不能提供任何服务的，读都不可以，而etcd的少数派仍然可以提供读服务，这在服务发现的时候还是不错的。

b. 不要将很多东西塞到Zookeeper里，这个上面已经提到过。

c. 不要使用Zookeeper做细粒度锁，比如很多业务在订单这个粒度上使用Zookeeper做分布式锁，这会频繁的和Zookeeper交互，对Zookeeper压力较大，而且一旦出现问题影响面广。但是可以使用粗粒度的锁(其实leader选举也是一种锁)。

d. 不建议做通用配置的第二个理由是，通用配置要提供给特别多特别多系统使用，而且一些公共配置甚至所有系统都会使用，一旦这样的配置发生变更，Zookeeper会广播给所有的watcher，然后所有Client都来拉取，瞬间造成非常大的网络流量，引起所谓的『惊群』。而自己实现通用配置系统的时候，一般会对这种配置采取排队或分批通知的方式。

11. 一些坑

a. zookeeper client 3.4.5 ping时间间隔算法有问题，在遇到网络抖动等原因导致一次ping失败后会断开连接。3.4.6解决了这个问题 Bug1751。

b. zookeeper client如果因为网络抖动断开了连接，如果后来又重连上了，zookeeper client会自动的将之前订阅的watcher等又全部订阅一遍，而Zookeeper默认对单个数据包的大小有个1M的限制，这往往就会超限，最后导致一直不断地的重试。这个问题在较新的版本得到了修复。Bug706

c. 抛出UnresolvedAddressException异常导致Zookeeper选举线程退出，整个集群无法再选举，处于崩溃的边缘。这个问题是，某次OPS迁移机器，将老的机器回收了，所以老的机器的IP和机器名不复存在，最后抛出UnresolvedAddressException这个异常，而Zookeeper的选举线程(QuorumCnxManager类里的Listener)只捕获了IOException，导致该线程退出，该线程一旦退出只要现在的leader出现问题，需要重新选举，则不会选出新的leader来，整个集群就会崩溃。Bug2319(PS，这个bug是我report的)

一、前言

　　前面分析了Zookeeper客户端的细节，接着继续学习Zookeeper中的一个非常重要的概念：会话。

二、会话

　　客户端与服务端之间任何交互操作都与会话息息相关，如临时节点的生命周期、客户端请求的顺序执行、Watcher通知机制等。Zookeeper的连接与会话就是客户端通过实例化Zookeeper对象来实现客户端与服务端创建并保持TCP连接的过程.

　　2.1 会话状态

　　在Zookeeper客户端与服务端成功完成连接创建后，就创建了一个会话，Zookeeper会话在整个运行期间的生命周期中，会在不同的会话状态中之间进行切换，这些状态可以分为CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE等。

　　一旦客户端开始创建Zookeeper对象，那么客户端状态就会变成CONNECTING状态，同时客户端开始尝试连接服务端，连接成功后，客户端状态变为CONNECTED，通常情况下，由于断网或其他原因，客户端与服务端之间会出现断开情况，一旦碰到这种情况，Zookeeper客户端会自动进行重连服务，同时客户端状态再次变成CONNCTING，直到重新连上服务端后，状态又变为CONNECTED，在通常情况下，客户端的状态总是介于CONNECTING和CONNECTED之间。但是，如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况，客户端的状态就会直接变更为CLOSE状态。

　　2.2 会话创建

　　Session是Zookeeper中的会话实体，代表了一个客户端会话，其包含了如下四个属性

　　1. sessionID。会话ID，唯一标识一个会话，每次客户端创建新的会话时，Zookeeper都会为其分配一个全局唯一的sessionID。

　　2. TimeOut。会话超时时间，客户端在构造Zookeeper实例时，会配置sessionTimeout参数用于指定会话的超时时间，Zookeeper客户端向服务端发送这个超时时间后，服务端会根据自己的超时时间限制最终确定会话的超时时间。

　　3. TickTime。下次会话超时时间点，为了便于Zookeeper对会话实行"分桶策略"管理，同时为了高效低耗地实现会话的超时检查与清理，Zookeeper会为每个会话标记一个下次会话超时时间点，其值大致等于当前时间加上TimeOut。

　　4. isClosing。标记一个会话是否已经被关闭，当服务端检测到会话已经超时失效时，会将该会话的isClosing标记为"已关闭"，这样就能确保不再处理来自该会话的心情求了。

　　Zookeeper为了保证请求会话的全局唯一性，在SessionTracker初始化时，调用initializeNextSession方法生成一个sessionID，之后在Zookeeper运行过程中，会在该sessionID的基础上为每个会话进行分配，初始化算法如下

public static long initializeNextSession(long id) {     long nextSid = 0;     // 无符号右移8位使为了避免左移24后，再右移8位出现负数而无法通过高8位确定sid值     nextSid = (System.currentTimeMillis() << 24) >>> 8;     nextSid = nextSid | (id << 56);     return nextSid; }

　　其中的id表示配置在myid文件中的值，通常是一个整数，如1、2、3。该算法的高8位确定了所在机器，后56位使用当前时间的毫秒表示进行随机。SessionTracker是Zookeeper服务端的会话管理器，负责会话的创建、管理和清理等工作。

　　2.3 会话管理

　　Zookeeper的会话管理主要是通过SessionTracker来负责，其采用了分桶策略（将类似的会话放在同一区块中进行管理）进行管理，以便Zookeeper对会话进行不同区块的隔离处理以及同一区块的统一处理。

　　Zookeeper将所有的会话都分配在不同的区块一种，分配的原则是每个会话的下次超时时间点（ExpirationTime）。ExpirationTime指该会话最近一次可能超时的时间点。同时，Zookeeper Leader服务器在运行过程中会定时地进行会话超时检查，时间间隔是ExpirationInterval，默认为tickTime的值，ExpirationTime的计算时间如下

　　ExpirationTime = ((CurrentTime + SessionTimeOut) / ExpirationInterval + 1) * ExpirationInterval

　　会了保持客户端会话的有效性，客户端会在会话超时时间过期范围内向服务端发送PING请求来保持会话的有效性（心跳检测）。同时，服务端需要不断地接收来自客户端的心跳检测，并且需要重新激活对应的客户端会话，这个重新激活过程称为TouchSession。会话激活不仅能够使服务端检测到对应客户端的存货性，同时也能让客户端自己保持连接状态，其流程如下　　

　　如上图所示，整个流程分为四步

　　1. 检查该会话是否已经被关闭。若已经被关闭，则直接返回即可。

　　2. 计算该会话新的超时时间ExpirationTime_New。使用上面提到的公式计算下一次超时时间点。

　　3. 获取该会话上次超时时间ExpirationTime_Old。计算该值是为了定位其所在的区块。

　　3. 迁移会话。将该会话从老的区块中取出，放入ExpirationTime_New对应的新区块中。

　　在上面会话激活过程中，只要客户端发送心跳检测，服务端就会进行一次会话激活，心跳检测由客户端主动发起，以PING请求形式向服务端发送，在Zookeeper的实际设计中，只要客户端有请求发送到服务端，那么就会触发一次会话激活，以下两种情况都会触发会话激活。

　　1. 客户端向服务端发送请求，包括读写请求，就会触发会话激活。

　　2. 客户端发现在sessionTimeout/3时间内尚未和服务端进行任何通信，那么就会主动发起PING请求，服务端收到该请求后，就会触发会话激活。

　　对于会话的超时检查而言，Zookeeper使用SessionTracker来负责，SessionTracker使用单独的线程（超时检查线程）专门进行会话超时检查，即逐个一次地对会话桶中剩下的会话进行清理。如果一个会话被激活，那么Zookeeper就会将其从上一个会话桶迁移到下一个会话桶中，如ExpirationTime 1 的session n 迁移到ExpirationTime n 中，此时ExpirationTime 1中留下的所有会话都是尚未被激活的，超时检查线程就定时检查这个会话桶中所有剩下的未被迁移的会话，超时检查线程只需要在这些指定时间点（ExpirationTime 1、ExpirationTime 2...）上进行检查即可，这样提高了检查的效率，性能也非常好。

　　2.4 会话清理

　　当SessionTracker的会话超时线程检查出已经过期的会话后，就开始进行会话清理工作，大致可以分为如下七步。

　　1. 标记会话状态为已关闭。由于会话清理过程需要一段时间，为了保证在此期间不再处理来自该客户端的请求，SessionTracker会首先将该会话的isClosing标记为true，这样在会话清理期间接收到该客户端的心情求也无法继续处理了。

　　2. 发起会话关闭请求。为了使对该会话的关闭操作在整个服务端集群都生效，Zookeeper使用了提交会话关闭请求的方式，并立即交付给PreRequestProcessor进行处理。

　　3. 收集需要清理的临时节点。一旦某个会话失效后，那么和该会话相关的临时节点都需要被清理，因此，在清理之前，首先需要将服务器上所有和该会话相关的临时节点都整理出来。Zookeeper在内存数据库中会为每个会话都单独保存了一份由该会话维护的所有临时节点集合，在Zookeeper处理会话关闭请求之前，若正好有以下两类请求到达了服务端并正在处理中。

　　　　· 节点删除请求，删除的目标节点正好是上述临时节点中的一个。

　　　　· 临时节点创建请求，创建的目标节点正好是上述临时节点中的一个。

　　对于第一类请求，需要将所有请求对应的数据节点路径从当前临时节点列表中移出，以避免重复删除，对于第二类请求，需要将所有这些请求对应的数据节点路径添加到当前临时节点列表中，以删除这些即将被创建但是尚未保存到内存数据库中的临时节点。

　　4. 添加节点删除事务变更。完成该会话相关的临时节点收集后，Zookeeper会逐个将这些临时节点转换成"节点删除"请求，并放入事务变更队列outstandingChanges中。

　　5. 删除临时节点。FinalRequestProcessor会触发内存数据库，删除该会话对应的所有临时节点。

　　6. 移除会话。完成节点删除后，需要将会话从SessionTracker中删除。

　　7. 关闭NIOServerCnxn。最后，从NIOServerCnxnFactory找到该会话对应的NIOServerCnxn，将其关闭。

　　2.5 重连

　　当客户端与服务端之间的网络连接断开时，Zookeeper客户端会自动进行反复的重连，直到最终成功连接上Zookeeper集群中的一台机器。此时，再次连接上服务端的客户端有可能处于以下两种状态之一

　　1. CONNECTED。如果在会话超时时间内重新连接上集群中一台服务器 。

　　2. EXPIRED。如果在会话超时时间以外重新连接上，那么服务端其实已经对该会话进行了会话清理操作，此时会话被视为非法会话。

　　在客户端与服务端之间维持的是一个长连接，在sessionTimeout时间内，服务端会不断地检测该客户端是否还处于正常连接，服务端会将客户端的每次操作视为一次有效的心跳检测来反复地进行会话激活。因此，在正常情况下，客户端会话时一直有效的。然而，当客户端与服务端之间的连接断开后，用户在客户端可能主要看到两类异常：CONNECTION_LOSS（连接断开）和SESSION_EXPIRED（会话过期）。

　　1. CONNECTION_LOSS。此时，客户端会自动从地址列表中重新逐个选取新的地址并尝试进行重新连接，直到最终成功连接上服务器。若客户端在setData时出现了CONNECTION_LOSS现象，此时客户端会收到None-Disconnected通知，同时会抛出异常。应用程序需要捕捉异常并且等待Zookeeper客户端自动完成重连，一旦重连成功，那么客户端会收到None-SyncConnected通知，之后就可以重试setData操作。

　　2. SESSION_EXPIRED。客户端与服务端断开连接后，重连时间耗时太长，超过了会话超时时间限制后没有成功连上服务器，服务器会进行会话清理，此时，客户端不知道会话已经失效，状态还是DISCONNECTED，如果客户端重新连上了服务器，此时状态为SESSION_EXPIRED，用于需要重新实例化Zookeeper对象，并且看应用的复杂情况，重新恢复临时数据。

　　3. SESSION_MOVED。客户端会话从一台服务器转移到另一台服务器，即客户端与服务端S1断开连接后，重连上了服务端S2，此时会话就从S1转移到了S2。当多个客户端使用相同的sessionId/sessionPasswd创建会话时，会收到SessionMovedException异常。因为一旦有第二个客户端连接上了服务端，就被认为是会话转移了。

三、总结

　　本篇博文介绍了Zookeeper会话的相关细节，通过本篇的学习理解了会话的细节，也谢谢各位园友的观看~

一、前言

　　在学习了Paxos在Chubby中的应用后，接下来学习Paxos在开源软件Zookeeper中的应用。

二、Zookeeper

　　Zookeeper是一个开源的分布式协调服务，其设计目标是将那些复杂的且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一些列简单的接口提供给用户使用。其是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/发布、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。其可以保证如下分布式一致性特性。

　　① 顺序一致性，从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中去。

　　② 原子性，所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即整个集群要么都成功应用了某个事务，要么都没有应用。

　　③ 单一视图，无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。

　　④ 可靠性，一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直被保留，除非有另一个事务对其进行了变更。

　　⑤ 实时性，Zookeeper保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

　　2.1 设计目标

　　Zookeeper致力于提供一个高性能、高可用、且具有严格的顺序访问控制能力（主要是写操作的严格顺序性）的分布式协调服务，其具有如下的设计目标。

　　① 简单的数据模型，Zookeeper使得分布式程序能够通过一个共享的树形结构的名字空间来进行相互协调，即Zookeeper服务器内存中的数据模型由一系列被称为ZNode的数据节点组成，Zookeeper将全量的数据存储在内存中，以此来提高服务器吞吐、减少延迟的目的。

　　② 可构建集群，一个Zookeeper集群通常由一组机器构成，组成Zookeeper集群的而每台机器都会在内存中维护当前服务器状态，并且每台机器之间都相互通信。

　　③ 顺序访问，对于来自客户端的每个更新请求，Zookeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序。

　　④ 高性能，Zookeeper将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。

　　2.2 基本概念

　　① 集群角色，最典型的集群就是Master/Slave模式（主备模式），此情况下把所有能够处理写操作的机器称为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器为Slave机器。Zookeeper引入了Leader、Follower、Observer三种角色，Zookeeper集群中的所有机器通过Leaser选举过程来选定一台被称为Leader的机器，Leader服务器为客户端提供写服务，Follower和Observer提供读服务，但是Observer不参与Leader选举过程，不参与写操作的过半写成功策略，Observer可以在不影响写性能的情况下提升集群的性能。

　　② 会话，指客户端会话，一个客户端连接是指客户端和服务端之间的一个TCP长连接，Zookeeper对外的服务端口默认为2181，客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接受来自服务器的Watch事件通知。

　　③ 数据节点，第一类指构成集群的机器，称为机器节点，第二类是指数据模型中的数据单元，称为数据节点-Znode，Zookeeper将所有数据存储在内存中，数据模型是一棵树，由斜杠/进行分割的路径，就是一个ZNode，如/foo/path1，每个ZNode都会保存自己的数据内存，同时还会保存一些列属性信息。ZNode分为持久节点和临时节点两类，持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上，而临时节点的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。另外，Zookeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，Zookeeper会自动在其节点后面追加一个整形数字，其是由父节点维护的自增数字。

　　④ 版本，对于每个ZNode，Zookeeper都会为其维护一个叫作Stat的数据结构，Stat记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）、aversion（当前ZNode的ACL版本）。

　　⑤ Watcher，Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端。

　　⑥ ACL，Zookeeper采用ACL（Access Control Lists）策略来进行权限控制，其定义了如下五种权限：

　　　　· CREATE：创建子节点的权限。

　　　　· READ：获取节点数据和子节点列表的权限。

　　　　· WRITE：更新节点数据的权限。

　　　　· DELETE：删除子节点的权限。

　　　　· ADMIN：设置节点ACL的权限。

　　2.3 ZAB协议

　　Zookeeper使用了Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息广播协议）的协议作为其数据一致性的核心算法。ZAB协议是为Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。

　　Zookeeper依赖ZAB协议来实现分布式数据的一致性，基于该协议，Zookeeper实现了一种主备模式的系统架构来保持集群中各副本之间的数据的一致性，即其使用一个单一的诸进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程中，ZAB协议的主备模型架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端大量的并发请求。

　　ZAB协议的核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式，即：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将一个客户端事务请求转化成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

　　ZAB一些包括两种基本的模式：崩溃恢复和消息广播。

　　当整个服务框架启动过程中或Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，状态同步时指数据同步，用来保证集群在过半的机器能够和Leader服务器的数据状态保持一致。

　　当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进入消息广播模式，当一台同样遵守ZAB协议的服务器启动后加入到集群中，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么加入的服务器就会自觉地进入数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。Zookeeper只允许唯一的一个Leader服务器来进行事务请求的处理，Leader服务器在接收到客户端的事务请求后，会生成对应的事务提议并发起一轮广播协议，而如果集群中的其他机器收到客户端的事务请求后，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。

　　当Leader服务器出现崩溃或者机器重启、集群中已经不存在过半的服务器与Leader服务器保持正常通信时，那么在重新开始新的一轮的原子广播事务操作之前，所有进程首先会使用崩溃恢复协议来使彼此到达一致状态，于是整个ZAB流程就会从消息广播模式进入到崩溃恢复模式。一个机器要成为新的Leader，必须获得过半机器的支持，同时由于每个机器都有可能会崩溃，因此，ZAB协议运行过程中，前后会出现多个Leader，并且每台机器也有可能会多次成为Leader，进入崩溃恢复模式后，只要集群中存在过半的服务器能够彼此进行正常通信，那么就可以产生一个新的Leader并再次进入消息广播模式。如一个由三台机器组成的ZAB服务，通常由一个Leader、2个Follower服务器组成，某一个时刻，加入其中一个Follower挂了，整个ZAB集群是不会中断服务的。

　　① 消息广播，ZAB协议的消息广播过程使用原子广播协议，类似于一个二阶段提交过程，针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集各自的选票，最后进行事务提交。

　　在ZAB的二阶段提交过程中，移除了中断逻辑，所有的Follower服务器要么正常反馈Leader提出的事务Proposal，要么就抛弃Leader服务器，同时，ZAB协议将二阶段提交中的中断逻辑移除意味着我们可以在过半的Follower服务器已经反馈Ack之后就开始提交事务Proposal，而不需要等待集群中所有的Follower服务器都反馈响应，但是，在这种简化的二阶段提交模型下，无法处理Leader服务器崩溃退出而带来的数据不一致问题，因此ZAB采用了崩溃恢复模式来解决此问题，另外，整个消息广播协议是基于具有FIFO特性的TCP协议来进行网络通信的，因此能够很容易保证消息广播过程中消息接受与发送的顺序性。再整个消息广播过程中，Leader服务器会为每个事务请求生成对应的Proposal来进行广播，并且在广播事务Proposal之前，Leader服务器会首先为这个事务Proposal分配一个全局单调递增的唯一ID，称之为事务ID（ZXID），由于ZAB协议需要保证每个消息严格的因果关系，因此必须将每个事务Proposal按照其ZXID的先后顺序来进行排序和处理。

　　② 崩溃恢复，在Leader服务器出现崩溃，或者由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式，在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader服务器，因此，ZAB协议需要一个高效且可靠的Leader选举算法，从而保证能够快速地选举出新的Leader，同时，Leader选举算法不仅仅需要让Leader自身知道已经被选举为Leader，同时还需要让集群中的所有其他机器也能够快速地感知到选举产生的新的Leader服务器。

　　③ 基本特性，ZAB协议规定了如果一个事务Proposal在一台机器上被处理成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交，假设一个事务在Leader服务器上被提交了，并且已经得到了过半Follower服务器的Ack反馈，但是在它Commit消息发送给所有Follower机器之前，Leader服务挂了。如下图所示

　　在集群正常运行过程中的某一个时刻，Server1是Leader服务器，其先后广播了P1、P2、C1、P3、C2（C2是Commit Of Proposal2的缩写），其中，当Leader服务器发出C2后就立即崩溃退出了，针对这种情况，ZAB协议就需要确保事务Proposal2最终能够在所有的服务器上都被提交成功，否则将出现不一致。

　　ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务。如果在崩溃恢复过程中出现一个需要被丢弃的提议，那么在崩溃恢复结束后需要跳过该事务Proposal，如下图所示

　　假设初始的Leader服务器Server1在提出一个事务Proposal3之后就崩溃退出了，从而导致集群中的其他服务器都没有收到这个事务Proposal，于是，当Server1恢复过来再次加入到集群中的时候，ZAB协议需要确保丢弃Proposal3这个事务。

　　在上述的崩溃恢复过程中需要处理的特殊情况，就决定了ZAB协议必须设计这样的Leader选举算法：能够确保提交已经被Leader提交的事务的Proposal，同时丢弃已经被跳过的事务Proposal。如果让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号（ZXID最大）的事务Proposal，那么就可以保证这个新选举出来的Leader一定具有所有已经提交的提议，更为重要的是如果让具有最高编号事务的Proposal机器称为Leader，就可以省去Leader服务器查询Proposal的提交和丢弃工作这一步骤了。

　　④ 数据同步，完成Leader选举后，在正式开始工作前，Leader服务器首先会确认日志中的所有Proposal是否都已经被集群中的过半机器提交了，即是否完成了数据同步。Leader服务器需要确所有的Follower服务器都能够接收到每一条事务Proposal，并且能够正确地将所有已经提交了的事务Proposal应用到内存数据库中。Leader服务器会为每个Follower服务器维护一个队列，并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器，并在每一个Proposal消息后面紧接着再发送一个Commit消息，以表示该事务已经被提交，等到Follower服务器将所有其尚未同步的事务Proposal都从Leader服务器上同步过来并成功应用到本地数据库后，Leader服务器就会将该Follower服务器加入到真正的可用Follower列表并开始之后的其他流程。

　　下面分析ZAB协议如何处理需要丢弃的事务Proposal的，ZXID是一个64位的数字，其中32位可以看做是一个简单的单调递增的计数器，针对客户端的每一个事务请求，Leader服务器在产生一个新的事务Proposal时，都会对该计数器进行加1操作，而高32位则代表了Leader周期epoch的编号，每当选举产生一个新的Leader时，就会从这个Leader上取出其本地日志中最大事务Proposal的ZXID，并解析出epoch值，然后加1，之后以该编号作为新的epoch，低32位则置为0来开始生成新的ZXID，ZAB协议通过epoch号来区分Leader周期变化的策略，能够有效地避免不同的Leader服务器错误地使用不同的ZXID编号提出不一样的事务Proposal的异常情况。当一个包含了上一个Leader周期中尚未提交过的事务Proposal的服务器启动时，其肯定无法成为Leader，因为当前集群中一定包含了一个Quorum（过半）集合，该集合中的机器一定包含了更高epoch的事务的Proposal，因此这台机器的事务Proposal并非最高，也就无法成为Leader。

　　2.4 ZAB协议原理

　　ZAB主要包括消息广播和崩溃恢复两个过程，进一步可以分为三个阶段，分别是发现（Discovery）、同步（Synchronization）、广播（Broadcast）阶段。ZAB的每一个分布式进程会循环执行这三个阶段，称为主进程周期。

　　· 发现，选举产生PL(prospective leader)，PL收集Follower epoch(cepoch)，根据Follower的反馈，PL产生newepoch(每次选举产生新Leader的同时产生新epoch)。

　　· 同步，PL补齐相比Follower多数派缺失的状态、之后各Follower再补齐相比PL缺失的状态，PL和Follower完成状态同步后PL变为正式Leader(established leader)。

　　· 广播，Leader处理客户端的写操作，并将状态变更广播至Follower，Follower多数派通过之后Leader发起将状态变更落地(deliver/commit)。

　　在正常运行过程中，ZAB协议会一直运行于阶段三来反复进行消息广播流程，如果出现崩溃或其他原因导致Leader缺失，那么此时ZAB协议会再次进入发现阶段，选举新的Leader。

　　2.4.1 运行分析

　　每个进程都有可能处于如下三种状态之一

　　· LOOKING：Leader选举阶段。

　　· FOLLOWING：Follower服务器和Leader服务器保持同步状态。

　　· LEADING：Leader服务器作为主进程领导状态。

　　所有进程初始状态都是LOOKING状态，此时不存在Leader，此时，进程会试图选举出一个新的Leader，之后，如果进程发现已经选举出新的Leader了，那么它就会切换到FOLLOWING状态，并开始和Leader保持同步，处于FOLLOWING状态的进程称为Follower，LEADING状态的进程称为Leader，当Leader崩溃或放弃领导地位时，其余的Follower进程就会转换到LOOKING状态开始新一轮的Leader选举。

　　一个Follower只能和一个Leader保持同步，Leader进程和所有与所有的Follower进程之间都通过心跳检测机制来感知彼此的情况。若Leader能够在超时时间内正常收到心跳检测，那么Follower就会一直与该Leader保持连接，而如果在指定时间内Leader无法从过半的Follower进程那里接收到心跳检测，或者TCP连接断开，那么Leader会放弃当前周期的领导，比你转换到LOOKING状态，其他的Follower也会选择放弃这个Leader，同时转换到LOOKING状态，之后会进行新一轮的Leader选举，并在选举产生新的Leader之后开始新的一轮主进程周期。

　　2.5 ZAB与Paxos的联系和区别

　　联系：

　　① 都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行。

　　② Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提议进行提交。

　　③ 在ZAB协议中，每个Proposal中都包含了一个epoch值，用来代表当前的Leader周期，在Paxos算法中，同样存在这样的一个标识，名字为Ballot。

　　区别：

　　Paxos算法中，新选举产生的主进程会进行两个阶段的工作，第一阶段称为读阶段，新的主进程和其他进程通信来收集主进程提出的提议，并将它们提交。第二阶段称为写阶段，当前主进程开始提出自己的提议。

　　ZAB协议在Paxos基础上添加了同步阶段，此时，新的Leader会确保存在过半的Follower已经提交了之前的Leader周期中的所有事务Proposal。

　　ZAB协议主要用于构建一个高可用的分布式数据主备系统，而Paxos算法则用于构建一个分布式的一致性状态机系统。

三、总结

　　此部分也还是理论知识偏多，学好理论之后再看代码应该会更快速一些，也谢谢各位园友的观看~　

维基的简介：Paxos算法是莱斯利·兰伯特（Leslie Lamport，就是 LaTeX 中的"La"，此人现在在微软研究院）于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。

Paxos算法目前在Google的Chubby、MegaStore、Spanner等系统中得到了应用，Hadoop中的ZooKeeper也使用了Paxos算法，在上面的各个系统中，使用的算法与Lamport提出的原始Paxos并不完全一样，这个以后再慢慢分析。本博文的目的是，如何让一个小白在半个小时之内理解Paxos算法的思想。小白可能对数学不感兴趣，对分布式的复杂理论不熟悉，只是一个入门级程序员。之所以想写这篇博文，是因为自己看了网上很多介绍Paxos算法的文章，以及博客，包括Lamport的论文，感觉还是难以理解，大多过于复杂，本人一直认为，复杂高深的理论背后一定基于一些通用的规律，而这些通用的规律在生活中其实我们早就遇到过，甚至用过。所以，我们先忽略Paxos算法本身，从生活中的小事开始谈起。

 假如有一群驴友要决定中秋节去旅游，这群驴友分布在全国各地，假定一共25个人，分别在不同的省，要决定到底去拉萨、昆明、三亚等等哪个地点（会合时间中秋节已经定了，此时需要决定旅游地）。最直接的方式当然就是建一个QQ群，大家都在里面投票，按照少数服从多数的原则。这种方式类似于“共享内存”实现的一致性，实现起来简单，但Paxos算法不是这种场景，因为Paxos算法认为这种方式有一个很大的问题，就是QQ服务器挂掉怎么办？Paxos的原则是容错性一定要很强。所以，Paxos的场景类似于这25个人相互之间只能发短信，为了这件事情能够达成一致，这25个人找了另外的5个人（当然这5个人可以从25个人中选，这里为了描述方便，就单拿出另外5个人），比如北京、上海、广州、深圳、成都的5个人，25个人都给他们发短信，告诉自己倾向的旅游地。这5个人相互之间可以并不通信，只接受25个人发过来的短信。这25个人我们称为驴友，那5个人称为队长。

先来看驴友的逻辑。驴友可以给任意5个队长都发短信，发短信的过程分为两个步骤：

第一步（申请阶段）：询问5个队长，试图与队长沟通旅游地。因为每个队长一直会收到不同驴友的短信，不能跟多个驴友一起沟通，在任何时刻只能跟一个驴友沟通，按照什么原则才能做到公平公正公开呢？这些短信都带有发送时间，队长采用的原则是同意与短信发送时间最新的驴友沟通，如果出现了更新的短信，则与短信更新的驴友沟通。总之，作为一个有话语权的人，只有时刻保持倾听最新的呼声，才能做出最明智的选择。在驴友发出短信后，等着队长回复。某些队长可能会回复说，你这条短信太老了，我不与你沟通；有些队长则可能返回说，你的短信是我收到的最新的，我同意跟你沟通。对于后面这些队长，还得返回自己决定的旅游地。关于队长是怎么决定旅游地的，后面再说。

对于驴友来说，第一步必须至少有半数以上队长都同意沟通了，才能进入下一步。否则，你连沟通的资格都没有，一直在那儿狂发吧。你发的短信更新，你获得沟通权的可能性才更大。。。。。。

因为至少有半数以上队长（也就是3个队长以上）同意，你才能与队长们进行实质性的沟通，也就是进入第二步；而队长在任何时候只能跟1个驴友沟通，所以，在任何时候，不可能出现两个驴友都达到了这个状态。。。当然，你可以通过狂发短信把沟通权抢了。。。。

对于获得沟通权的那个驴友（称为A），那些队长会给他发送他们自己决定的旅游地（也可能都还没有决定）。可以看出，各个队长是自己决定旅游地的，队长之间无需沟通。

第二步（沟通阶段）：这个幸运的驴友收到了队长们给他发的旅游地，可能有几种情况：

第一种情况：跟A沟通的队长们（不一定是全部5个队长，但是半数以上）全部都还没有决定到底去那儿旅游，此时驴友A心花怒放，给这些队长发第二条短信，告诉他们自己希望的旅游地（比如马尔代夫）；

可能会收到两种结果：一是半数以上队长都同意了，于是表明A建议的马尔代夫被半数以上队长都同意了，整个决定过程完毕了，其它驴友迟早会知道这个消息的，A先去收拾东西准备去马尔代夫；除此之外，表明失败。可能队长出故障了，比如某个队长在跟女朋友打电话等等，也可能被其它驴友抢占沟通权了（因为队长喜新厌旧嘛，只有要更新的驴友给自己发短信，自己就与新人沟通，A的建议队长不同意）等等。不管怎么说，苦逼的A还得重新从第一步开始，重新给队长们发短信申请。

第二种情况：至少有一个队长已经决定旅游地了，A可能会收到来自不同队长决定的多个旅游地，这些旅游地是不同队长跟不同驴友在不同时间上做出的决定，那么，A会先看一下，是不是有的旅游地已经被半数以上队长同意了（比如3个队长都同意去三亚，1个同意去昆明，另外一个没搭理A），如果出现了这种情况，那就别扯了，说明整个决定过程已经达成一致了，收拾收拾准备去三亚吧，结束了；如果都没有达到半数以上（比如1个同意去昆明，1个同意去三亚，2个同意去拉萨，1个没搭理我），A作为一个高素质驴友，也不按照自己的意愿乱来了（Paxos的关键所在，后者认同前者，否则整个决定过程永无止境），虽然自己原来可能想去马尔代夫等等。就给队长们发第二条短信的时候，告诉他们自己希望的旅游地，就是自己收到的那堆旅游地中最新决定的那个。（比如，去昆明那个是北京那个队长前1分钟决定的，去三亚的决定是上海那个队长1个小时之前做出来的，于是顶昆明）。驴友A的想法是，既然有队长已经做决定了，那我就干脆顶最新那个决定。

从上面的逻辑可以看出，一旦某个时刻有半数以上队长同意了某个地点比如昆明，紧跟着后面的驴友B继续发短信时，如果获得沟通权，因为半数以上队长都同意与B沟通了，B必然会收到至少一个队长给他发的昆明这个结果，B于是会顶这个最新地点，不会更改，因为后面的驴友都会顶昆明，因此同意昆明的队长越来越多，最终必然达成一致。

看完了驴友的逻辑，那么队长的逻辑是什么呢？

队长的逻辑比较简单。

在申请阶段，队长只会选择与最新发申请短信的驴友沟通，队长知道自己接收到最新短信的时间，对于更老的短信，队长不会搭理；队长同意沟通了的话，会把自己决定的旅游地（或者还没决定这一信息）发给驴友。

在沟通阶段，驴友C会把自己希望的旅游地发过来（同时会附加上自己申请短信的时间，比如3分钟前），所以队长要检查一下，如果这个时间（3分钟前）确实是当前自己最新接收到申请短信的时间（说明这段时间没有驴友要跟自己沟通），那么，队长就同意驴友C的这个旅游地了（比如昆明，哪怕自己1个小时前已经做过去三亚的决定，谁让C更新呢，于是更新为昆明）；如果不是最新的，说明这3分钟内又有其它驴友D跟自己申请了，因为自己是个喜新厌旧的家伙，同意与D沟通了，所以驴友C的决定自己不会同意，等着D一会儿要发过来的决定吧。

Paxos的基本思想大致就是上面的过程。让我们来对应一下。

Paxos主要用于保证分布式存储中副本（或者状态）的一致性。副本要保持一致，那么，所有副本的更新序列就要保持一致。因为数据的增删改查操作一般都存在多个客户端并发操作，到底哪个客户端先做，哪个客户端后做，这就是更新顺序。如果不是分布式，那么可以利用加锁的方法，谁先申请到锁，谁就先操作。但是在分布式条件下，存在多个副本，如果依赖申请锁+副本同步更新完毕再释放锁，那么需要有分配锁的这么一个节点（如果是多个锁分配节点，那么又出现分布式锁管理的需求，把锁给哪一个客户端又成为一个难点），这个节点又成为单点，岂不是可靠性不行了，失去了分布式多副本的意义，同时性能也很差，另外，还会出现死锁等情况。

所以，说来说去，只有解决分布式条件下的一致性问题，似乎才能解决本质问题。

如上面的例子，Paxos解决这一问题利用的是选举，少数服从多数的思想，只要2N+1个节点中，有N个以上同意了某个决定，则认为系统达到了一致，并且按照Paxos原则，最终理论上也达到了一致，不会再改变。这样的话，客户端不必与所有服务器通信，选择与大部分通信即可；也无需服务器都全部处于工作状态，有一些服务器挂掉，只有保证半数以上存活着，整个过程也能持续下去，容错性相当好。

Paxos中的Acceptor就相当于上面的队长，Proposer就相当于上面的驴友，epoch编号就相当于例子中申请短信的发送时间。关于Paxos的正式描述已经很多了，这里就不复述了，关于Paxos正确性的证明，因为比较复杂，以后有时间再分析。另外，Paxos最消耗时间的地方就在于需要半数以上同意沟通了才能进入第二步，试想一下，一开始，所有驴友就给队长狂发短信，每个队长收到的最新短信的是不同驴友，这样，就难以达到半数以上都同意与某个驴友沟通的状态，为了减小这个时间，Paxos还有Fast Paxos的改进等等，有空再分析。

倒是有一些问题可以思考一下：在Paxos之前，或者说除了Chubby，ZooKeeper这些系统，其它分布式系统同样面临这样的一致性问题，比如HDFS、分布式数据库、Amazon的Dynamo等等，解决思路又不同，有空再进行对比分析。

最后谈谈一致性这个名词。

关于Paxos说的一致性，个人理解是指冗余副本（或状态等，但都是因为存在冗余）的一致性。这与关系型数据库中ACID的一致性说的不是一个东西。在关系数据库里，可以连副本都没有，何谈副本的一致性？按照经典定义，ACID中的C指的是在一个事务中，事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。那么，什么又是一致性状态呢，这跟业务约束有关系，比如经典的转账事务，事务处理完毕后，不能出现一个账户钱被扣了，另一个账户的钱没有增加的情况，如果两者加起来的钱还是等于转账前的钱，那么就是一致性状态。

从很多博文来看，对这两种一致性往往混淆起来。另外，CAP原则里面所说的一致性，个人认为是指副本一致性，与Paxos里面的一致性接近。都是处理“因为冗余数据的存在而需要保证多个副本保持一致”的问题，NoSQL放弃的强一致性也是指副本一致性，最终一致性也是指副本达到完全相同存在一定延时。

当然，如果数据库本身是分布式的，且存在冗余副本，则除了解决事务在业务逻辑上的一致性问题外，同时需要解决副本一致性问题，此时可以利用Paxos协议。但解决了副本一致性问题，还不能完全解决业务逻辑一致性；如果是分布式数据库，但并不存在副本的情况，事务的一致性需要根据业务约束进行设计。

另外，谈到Paxos时，还会涉及到拜占庭将军问题，它指的是在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。Paxos本身就是利用消息传递方式解决一致性问题的，所以它的假定是信道必须可靠，这里的可靠，主要指消息不会被篡改。消息丢失是允许的。

关于一致性，关于事务的ACID，CAP，NoSQL等等问题，以后再详细分析。

Vineet Gupta的回答

• “你愿意.......”（男：）“我愿意！”（女：）“我愿意！”
• “现在我宣布你们...”

• “你愿意...?”（男：）“我愿意！”（女1：）“我愿意！”（女2：）“我愿意！”...
• “现在我宣布你们...”

二阶段提交（2PC）

1. 表决阶段。在表决阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
2. 提交阶段。在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

• 现在一些节点已经开始了2PC循环，而另一些节点没有意识到2PC循环已经发生。那些已经开始2PC循环的节点被阻塞在等待下一个阶段上。
• 在我们的场景中，已经投票的资源管理单元也可能不得不锁定一些资源，这样资源管理不会因为等待协调器恢复并启动阶段二而耗尽时间。

三阶段提交（3PC）

• 如果任何资源管理向恢复节点报告说它并没有接收到“准备提交”的信息，恢复节点便知道事务没有提交给任何资源管理。现在要么事务被悲观地终止，要么协议实例重新运行。
• 如果有一个管理单元提交事务后崩溃了，我们知道的是，其它每一个资源管理单元可能会收到“准备提交”的确认信息，否则协调器不会进入提交阶段。所以协调器是可以进入到最后一个阶段的。

Paxos-为什么麻烦？

Paxos-它如何运行?

• 选择一个节点作为领导者/提议者。
• 领导者选择一个值并将它发给所有节点（Paxos中被称为接收者），（这个值）封装在接收-请求消息中，接收者可以回复拒绝或接受。
• 一旦多数节点都接受，共识就达成了同时协调器向所有节点广播提交信息。

• 给领导者指定顺序。这让每个节点能够区分当前领导者和旧的领导者，它阻止旧领导者（或许刚从旧的故障中恢复）扰乱已经达成的共识。
• 限制领导者对值的选择。一旦就某个值`达成了共识，Paxos强制将来的领导只能选择相同的值确保共识能延续下去。这一点是这样实现的-接收节点发送它赞同的最新的值和它收到的领导者的序列号（来实现上一点）。新的领导者可以从接受者发送的值中选择一个，万一没有任何接收节点发送值，领导者也可以选择自己的值。

协议步骤：

准备阶段：

• 一个节点被选为领导者并且选择序列号x和值v创建提议P1(x,v)。领导者把P1发送给接收者并等待大部分节点响应。
• 接收者一旦接收到提议P1(x,v)会做下面的事：
  • 如果是接收者第一次收到提议而且它选择赞同，回复“赞同”-这是接收者的承诺，它将承诺拒绝将来所有小于x的提议请求。
  - 如果接收者已经赞同了提议：
  • 比较x和接收者赞同的提议的最高序列号，称为P2(y,v2)
  • 若x<y,回应“拒绝”以及y的值
  - 若x>y,回应“赞同”以及P2(y,v2)

接受阶段

Paxos对故障的处理

• 领导者故障了-另一位（新的）领导者可以通过发出自己的协议来接管协议。
• 原先的（故障）领导者恢复后-两个领导者可以同时存在，这归功于下面的规则：只赞同更高序列号的协议以及只提交以前接受的值。

拓展阅读

• Principles of Transaction Processing，第八章提供了2PC的详细概述。
• Non-blocking Commit Protocols-Dale Skeen著作的描述3PC的原始论文
• The Part-time Parliament-Lamport的关于Paxos的原始论文。它用议会类比，当论文发表时人们发现很难回到过去的议会（译者注：议会的时代和论文发表的时代差距很远，人们很难理解过去的议会，所以也难于理解这篇论文）。
• Paxos Made Simple-Lamport重写的论文，去掉了议会类比。虽然简单，你也有可能错过论文的（核心），需要多次阅读来理解论文核心思想。
• Paxos Made Live-谷歌关于他们Paxos算法实现的描述。是关于Paxos的最具可读性的论文。

Russell Cohen的回答

背景

在计算机通信理论中，有一个著名的两军问题(two-army problem)，讲述通信的双方通过ACK来达成共识，永远会有一个在途的ACK需要进行确认，因此无法达成共识。

两军问题和Basic Paxos非常相似

1） 通信的各方需要达成共识；

2） 通信的各方仅需要达成一个共识；

3） 假设的前提是信道不稳定，有丢包、延迟或者重放，但消息不会被篡改。

Basic Paxos最早以希腊议会的背景来讲解，但普通人不理解希腊议会的运作模式，因此看Basic Paxos的论文会比较难理解。两军问题的背景大家更熟悉，因此尝试用这个背景来演绎一下Basic Paxos。

为了配合Basic Paxos的多数派概念，把两军改为3军；同时假设了将军和参谋的角色。

假设的3军问题

1） 1支红军在山谷里扎营，在周围的山坡上驻扎着3支蓝军；

2） 红军比任意1支蓝军都要强大；如果1支蓝军单独作战，红军胜；如果2支或以上蓝军同时进攻，蓝军胜；

3） 三支蓝军需要同步他们的进攻时间；但他们惟一的通信媒介是派通信兵步行进入山谷，在那里他们可能被俘虏，从而将信息丢失；或者为了避免被俘虏，可能在山谷停留很长时间；

4） 每支军队有1个参谋负责提议进攻时间；每支军队也有1个将军批准参谋提出的进攻时间；很明显，1个参谋提出的进攻时间需要获得至少2个将军的批准才有意义；

5） 问题：是否存在一个协议，能够使得蓝军同步他们的进攻时间？

接下来以两个假设的场景来演绎BasicPaxos；参谋和将军需要遵循一些基本的规则

1） 参谋以两阶段提交（prepare/commit）的方式来发起提议，在prepare阶段需要给出一个编号；

2） 在prepare阶段产生冲突，将军以编号大小来裁决，编号大的参谋胜出；

3） 参谋在prepare阶段如果收到了将军返回的已接受进攻时间，在commit阶段必须使用这个返回的进攻时间；

两个参谋先后提议的场景

1） 参谋1发起提议，派通信兵带信给3个将军，内容为（编号1）；

2） 3个将军收到参谋1的提议，由于之前还没有保存任何编号，因此把（编号1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（ok）；

3） 参谋1收到至少2个将军的回复，再次派通信兵带信给3个将军，内容为（编号1，进攻时间1）；

4） 3个将军收到参谋1的时间，把（编号1，进攻时间1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（Accepted）；

5） 参谋1收到至少2个将军的（Accepted）内容，确认进攻时间已经被大家接收；

6） 参谋2发起提议，派通信兵带信给3个将军，内容为（编号2）；

7） 3个将军收到参谋2的提议，由于（编号2）比（编号1）大，因此把（编号2）保存下来，避免遗忘；又由于之前已经接受参谋1的提议，因此让通信兵带信回去，内容为（编号1，进攻时间1）；

8） 参谋2收到至少2个将军的回复，由于回复中带来了已接受的参谋1的提议内容，参谋2因此不再提出新的进攻时间，接受参谋1提出的时间；

两个参谋交叉提议的场景

1） 参谋1发起提议，派通信兵带信给3个将军，内容为（编号1）；

2） 3个将军的情况如下

a) 将军1和将军2收到参谋1的提议，将军1和将军2把（编号1）记录下来，如果有其他参谋提出更小的编号，将被拒绝；同时让通信兵带信回去，内容为（ok）；

b) 负责通知将军3的通信兵被抓，因此将军3没收到参谋1的提议；

3） 参谋2在同一时间也发起了提议，派通信兵带信给3个将军，内容为（编号2）；

4） 3个将军的情况如下

a) 将军2和将军3收到参谋2的提议，将军2和将军3把（编号2）记录下来，如果有其他参谋提出更小的编号，将被拒绝；同时让通信兵带信回去，内容为（ok）；

b) 负责通知将军1的通信兵被抓，因此将军1没收到参谋2的提议；

5） 参谋1收到至少2个将军的回复，再次派通信兵带信给有答复的2个将军，内容为（编号1，进攻时间1）；

6） 2个将军的情况如下

a) 将军1收到了（编号1，进攻时间1），和自己保存的编号相同，因此把（编号1，进攻时间1）保存下来；同时让通信兵带信回去，内容为（Accepted）；

b) 将军2收到了（编号1，进攻时间1），由于（编号1）小于已经保存的（编号2），因此让通信兵带信回去，内容为（Rejected，编号2）；

7） 参谋2收到至少2个将军的回复，再次派通信兵带信给有答复的2个将军，内容为（编号2，进攻时间2）；

8） 将军2和将军3收到了（编号2，进攻时间2），和自己保存的编号相同，因此把（编号2，进攻时间2）保存下来，同时让通信兵带信回去，内容为（Accepted）；

9） 参谋2收到至少2个将军的（Accepted）内容，确认进攻时间已经被多数派接受；

10） 参谋1只收到了1个将军的（Accepted）内容，同时收到一个（Rejected，编号2）；参谋1重新发起提议，派通信兵带信给3个将军，内容为（编号3）；

11） 3个将军的情况如下

a) 将军1收到参谋1的提议，由于（编号3）大于之前保存的（编号1），因此把（编号3）保存下来；由于将军1已经接受参谋1前一次的提议，因此让通信兵带信回去，内容为（编号1，进攻时间1）；

b) 将军2收到参谋1的提议，由于（编号3）大于之前保存的（编号2），因此把（编号3）保存下来；由于将军2已经接受参谋2的提议，因此让通信兵带信回去，内容为（编号2，进攻时间2）；

c) 负责通知将军3的通信兵被抓，因此将军3没收到参谋1的提议；

12） 参谋1收到了至少2个将军的回复，比较两个回复的编号大小，选择大编号对应的进攻时间作为最新的提议；参谋1再次派通信兵带信给有答复的2个将军，内容为（编号3，进攻时间2）；

13） 将军1和将军2收到了（编号3，进攻时间2），和自己保存的编号相同，因此保存（编号3，进攻时间2），同时让通信兵带信回去，内容为（Accepted）；

14） 参谋1收到了至少2个将军的（accepted）内容，确认进攻时间已经被多数派接受；

小结

BasicPaxos算法难理解，除了讲故事的背景不熟悉之外，还有以下几点

1） 参与的各方并不是要针锋相对，拼个你死我活；而是要合作共赢，最终达成一个共识；当大家讲起投票的时候，往往第一反应是要针锋相对，没想到是要合作共赢；很明显可以想到，在第二个场景下，如果参谋1为了逞英雄，强行要提交他提出的进攻时间1，那么最终是无法达成一个共识的；这里的点就在于参谋1违反了规则，相当于产生了拜占庭错误；

2） 常规的通信协议设计，对于写操作，通常都是只返回成功和失败的状态，不会返回更多的东西；但BasicPaxos的prepare和commit，将军除了返回成功还是失败的状态之外，还会把之前已经发生的一些状态带回给参谋，这个和常规的通信协议是不同的；

3） 在两军问题的背景下，其实知道进攻时间被至少2个将军接受的是参谋，而不是将军；在“两个参谋交叉提议的场景”下，当参谋1没有做第2次prepare之前，将军1记录的其实是一个错误的进攻时间；理论上来说，任何一个将军在任何一个时刻都无法判断自己不是处在将军1的场景下；因此BasicPaxos在3个蓝军组成的系统中达成了一个共识，但并没有为每个将军明确了共识；

4） 本文的两个场景都以“两个参谋”来讲，这里的“两个参谋”可能是真的两个不同的参谋，也可能是同一个参谋因为某种原因先后做了多次提议；对应分布式系统的场景

a） 真的有两个并发的client

b） 两个client一先一后；第一个client执行到某个步骤因为某种原因停止了；过了一段时间，另外一个client接着操作同一个数据

c） 同一个client重试；第一次执行到某一步骤因为某种原因停止了，立即或者稍后进行了重试

后记

写这篇文章的时候，参考了以下两篇文章。

Paxos算法细节详解(一)--通过现实世界描述算法

http://www.cnblogs.com/endsock/p/3480093.html

第一篇文章用了我们喜闻乐见的背景，大部分内容非常容易理解，尤其是用比特币来映射编号，非常贴切；只是对于proposer-1小姐最后的“背叛”会有点违反常识。看完这个故事之后就一直在想更贴切的背景。在两军问题中，蓝军各方是要合作达成一个共识；对于参谋来说，获得了前一个参谋的提议就接受，而不再提出自己的提议是符合逻辑的，这个和paxos也更加吻合。在实际的分布式系统中，如果遇到冲突，涉及的各方也不是要针锋相对争个你死我活，想要的只是能发现冲突，只有一方成功、或者全部失败都无所谓，只要能保证数据一致就行。

以两军问题为背景，在提议编号上找不到合适的映射点，比较生硬，这一点不如第一遍文章中的故事。

Question 7: The Two Generals’ Problem of reaching consensus on when to attack is unsolvable, how come it’s possible to have consensus with Paxos?

http://bogdan.pistol.gg/2014/10/20/paxos-algorithm-explained-part-2-insights/#q7

paxos最终仍然无法解决两军问题，即使是扩展到3军也是无法解决的。在3军背景下，按paxos算法的定义，最后是达成了一个共同的进攻时间，3军中的任何一方都可以通过paxos算法读取出这个进攻时间。但3军怎么知道在什么时候去读取、其他人是否已经读取，这是一个和两军问题同样的问题；同时由于通信兵可能无限延迟，可能部分蓝军在进攻时间之前读取到了，部分蓝军可能在进攻时间之后才读取到，所以两军最终还是无解的。第二篇参考文章中也详细描述了这些问题。所以写paxos和两军问题，不是说paxos解决了两军问题，只是借用两军问题的背景来演绎paxos。

最近研究paxos算法，看了许多相关的文章，概念还是很模糊，觉得还是没有掌握paxos算法的精髓，所以花了3天时间分析了libpaxos3的所有代码，此代码可以从https://bitbucket.org/sciascid/libpaxos 下载。对paxos算法有初步了解之后，再看此文的效果会更好；如果你也想分析libpaxos3的话，此文应该会对你有不小帮助；关于paxos的历史这里不多做介绍，关于描述paxos算法写的最好的一篇文章应该就是维基百科了，地址戳这里：http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95

在paxos算法中，分为4种角色：

  Proposer ：提议者

  Acceptor：决策者

  Client：产生议题者

  Learner：最终决策学习者

上面4种角色中，提议者和决策者是很重要的，其他的2个角色在整个算法中应该算做打酱油的，Proposer就像Client的使者，由Proposer使者拿着Client的议题去向Acceptor提议，让Acceptor来决策。这里上面出现了个新名词：最终决策。现在来系统的介绍一下paxos算法中所有的行为：

1. Proposer提出议题
2. Acceptor初步接受 或者 Acceptor初步不接受
3. 如果上一步Acceptor初步接受则Proposer再次向Acceptor确认是否最终接受
4. Acceptor 最终接受 或者Acceptor 最终不接受

上面Learner最终学习的目标是Acceptor们最终接受了什么议题？注意，这里是向所有Acceptor学习，如果有多数派个Acceptor最终接受了某提议，那就得到了最终的结果，算法的目的就达到了。画一幅图来更加直观：

为什么需要3个Acceptor？因为Acceptor必须是最少大于等于3个，并且必须是奇数个，因为要形成多数派嘛，如果是偶数个，比如4个，2个接受2个不接受，各执己见，没法搞下去了。

为什么是3个Proposer？ 其实无所谓是多少个了，1~n 都可以的；如果是1个proposer，毫无竞争压力，很顺利的完成2阶段提交，Acceptor们最终批准了事。如果是多个proposer就比较复杂了，请继续看。

上面的图中是画了很多节点的，每个节点需要一台机器么？答案是不需要的，上面的图是逻辑图，物理中，可以将Acceptor和Proposer以及Client放到一台机器上，只是使用了不同的端口号罢了，Acceptor们启动不同端口的TCP监听，Proposer来主动连接即可；完全可以将Client、Proposer、Acceptor、Learner合并到一个程序里面；这里举一个例子：比如开发一个JOB程序，JOB程序部署在多台服务器上(数量为奇数)，这些JOB有可能同时处理一项任务，现在使用paxos算法让这些JOB自己来商量由谁(哪台机器)来处理这项任务，这样JOB程序里就需要包含Client、Proposer、Acceptor、Learner这4大功能，并且需要配置其他JOB服务器的IP地址。

再举一个例子，zookeeper常常用来做分布式事务锁。Zookeeper所使用的zad协议也是类似paxos协议的。所有分布式自协商一致性算法都是paxos算法的简化或者变种。Client是使用zookeeper服务的机器，Zookeeper自身包含了Acceptor, Proposer, Learner。Zookeeper领导选举就是paxos过程，还有Client对Zookeeper写Znode时，也是要进行Paxos过程的，因为不同Client可能连接不同的Zookeeper服务器来写Znode，到底哪个Client才能写成功？需要依靠Zookeeper的paxos保证一致性，写成功Znode的Client自然就是被最终接受了，Znode包含了写入Client的IP与端口，其他的Client也可以读取到这个Znode来进行Learner。也就是说在Zookeeper自身包含了Learner(因为Zookeeper为了保证自身的一致性而会进行领导选举，所以需要有Learner的内部机制，多个Zookeeper服务器之间需要知道现在谁是领导了)，Client端也可以Learner，Learner是广义的。

现在通过一则故事来学习paxos的算法的流程(2阶段提交)，有2个Client(老板，老板之间是竞争关系)和3个Acceptor(政府官员)：

1. 现在需要对一项议题来进行paxos过程，议题是“A项目我要中标！”，这里的“我”指每个带着他的秘书Proposer的Client老板。
2. Proposer当然听老板的话了，赶紧带着议题和现金去找Acceptor政府官员。
3. 作为政府官员，当然想谁给的钱多就把项目给谁。
4. Proposer-1小姐带着现金同时找到了Acceptor-1~Acceptor-3官员，1与2号官员分别收取了10比特币，找到第3号官员时，没想到遭到了3号官员的鄙视，3号官员告诉她，Proposer-2给了11比特币。不过没关系，Proposer-1已经得到了1,2两个官员的认可，形成了多数派(如果没有形成多数派，Proposer-1会去银行提款在来找官员们给每人20比特币，这个过程一直重复每次+10比特币，直到多数派的形成)，满意的找老板复命去了，但是此时Proposer-2保镖找到了1,2号官员，分别给了他们11比特币，1,2号官员的态度立刻转变，都说Proposer-2的老板懂事，这下子Proposer-2放心了，搞定了3个官员，找老板复命去了，当然这个过程是第一阶段提交，只是官员们初步接受贿赂而已。故事中的比特币是编号，议题是value。

　　　　这个过程保证了在某一时刻，某一个proposer的议题会形成一个多数派进行初步支持；

 ===============华丽的分割线，第一阶段结束================

　　5.　现在进入第二阶段提交，现在proposer-1小姐使用分身术(多线程并发)分了3个自己分别去找3位官员，最先找到了1号官员签合同，遭到了1号官员的鄙视，1号官员告诉他proposer-2先生给了他11比特币，因为上一条规则的性质proposer-1小姐知道proposer-2第一阶段在她之后又形成了多数派(至少有2位官员的赃款被更新了);此时她赶紧去提款准备重新贿赂这3个官员(重新进入第一阶段)，每人20比特币。刚给1号官员20比特币， 1号官员很高兴初步接受了议题，还没来得及见到2,3号官员的时候

这时proposer-2先生也使用分身术分别找3位官员(注意这里是proposer-2的第二阶段)，被第1号官员拒绝了告诉他收到了20比特币，第2,3号官员顺利签了合同，这时2，3号官员记录client-2老板用了11比特币中标，因为形成了多数派，所以最终接受了Client2老板中标这个议题，对于proposer-2先生已经出色的完成了工作；

这时proposer-1小姐找到了2号官员，官员告诉她合同已经签了，将合同给她看，proposer-1小姐是一个没有什么职业操守的聪明人，觉得跟Client1老板混没什么前途，所以将自己的议题修改为“Client2老板中标”，并且给了2号官员20比特币，这样形成了一个多数派。顺利的再次进入第二阶段。由于此时没有人竞争了，顺利的找3位官员签合同，3位官员看到议题与上次一次的合同是一致的，所以最终接受了，形成了多数派，proposer-1小姐跳槽到Client2老板的公司去了。

===============华丽的分割线，第二阶段结束===============

　　Paxos过程结束了，这样，一致性得到了保证，算法运行到最后所有的proposer都投“client2中标”所有的acceptor都接受这个议题，也就是说在最初的第二阶段，议题是先入为主的，谁先占了先机，后面的proposer在第一阶段就会学习到这个议题而修改自己本身的议题，因为这样没职业操守，才能让一致性得到保证，这就是paxos算法的一个过程。原来paxos算法里的角色都是这样的不靠谱，不过没关系，结果靠谱就可以了。该算法就是为了追求结果的一致性。

一、前言

　　在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。

二、集中式系统

　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。

三、分布式系统

　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点

　　3.1 分布性

　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。

　　3.2 对等性

　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的，副本指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。服务副本是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。

　　3.3 并发性

　　同一分布式系统中的多个节点，可能会并发地操作一些共享资源，诸如数据库或分布式存储等，如何高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。

　　3.4 缺乏全局时钟

　　典型的分布式系统由一系列在空间上随意分布的多个进程组成，具有明显的分布性，这些进程之间通过交换消息来进行互相通信，因此，在分布式系统中，很难定义两个时间究竟谁先谁后，原因就是因为分布式系统缺乏一个全局的时钟序列控制。

　　3.5 故障总是会发生

　　组成分布式系统的所有计算机，都有可能发生任何形式的故障，任何在设计阶段考虑到的异常情况，一定会在系统实际运行中发生。

四、分布式环境的问题

　　4.1 通信异常

　　从集中式到分布式，必然引入了网络因素，而由于网络本身的不可靠性，因此就引入了额外的问题。分布式系统各节点之间的网络通信能够正常进行，其延时也会远大于单机操作，在消息的收发过程中，消息丢失和消息延迟变得十分普遍。

　　4.2 网络分区

　　当网络发生异常情况时，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式胸的所有节点中，只有部分节点之间能够正常通信，而另一些节点则不能，这种现象称之为网络分区，当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事务处理，这就对分布式一致性提出了非常大的挑战。

　　4.3 三态

　　由于网络可能会出现各种各样的问题，因此分布式系统的每一次请求与响应，存在特有的三态概念：成功、失败、超时。当网络在异常情况下，可能会出现超时现象，通常由以下两种情况：1. 由于网络原因，该请求并没有被成功地发送到接收方，而是在发送过程就发生了消息丢失现象。2. 该请求成功的被接收方接受后，并进行了处理，但是在将响应反馈给发送方时，发生了消息丢失现象。

　　4.4 节点故障

　　节点故障是指组成分布式系统的服务器节点出现宕机或僵死现象，每个节点都有可能出现故障，并且煤炭都在发生。

五、从ACID到CAP/BASE

　　5.1 ACID

　　事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行单元，狭义上的食物特指数据库事务。一方面，当多个应用程序并发访问数据库时，食物可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作相互干扰，另一方面，食物为数据库操作序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在宜昌状态下仍能保持数据一致性的方法。事务具有原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），简称ACID。

　　① 原子性，指事务必须是一个原子的操作序列单元，事务中包含的各项操作在一次执行过程中，只允许出现以下两种状态之一，全部成功执行，全部不执行。任何一项操作失败都将导致整个事务失败，同时其他已经被执行的操作都将被撤销并回滚，只有所有操作全部成功，整个事务才算是成功完成。

　　② 一致性，指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态，即事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态，因此当数据库只包含成功事务提交的结果时，就能说数据库处于一致性状态，而如果数据库系统在运行过程中发生故障，有些事务尚未完成就被迫中断，这些未完成的事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

　　③ 隔离性，指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰，即不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能相互干扰。

　　④ 持久性，指一个事务一旦提交，他对数据库中对应数据的状态变更就应该是永久的，即一旦某个事务成功结束，那么它对数据库所做的更新就必须被永久的保存下来，即使发生系统崩溃或者宕机故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态。

　　5.2 分布式事务

　　分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上，通常一个分布式事务中会涉及对多个数据源或业务系统的操作。一个分布式事务可以看做是由多个分布式的操作序列组成，通常可以把这一系列分布式的操作序列称为子事务。由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。

　　5.3 CAP

　　CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性、分区容错性这三个基本需求，最多只能同时满足其中的两个。

　　① 一致性，指数据在多个副本之间是否能够保持一致的特性，在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致状态。对于一个将数据副本分布在不同分布式节点上的系统来来说，如果对第一个结点的数据进行了更新操作并且成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个结点的数据进行读取操作时，获取的仍然是老数据（脏数据），这就是典型的分布式数据不一致的情况，在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到期最新的值，那么这样的系统就被认为具有强一致性。

　　② 可用性，指系统提供的服务必须一直处于可用的状态，对于用户的每一操作请求总是能够在有限的时间内返回结果。

　　③ 分区容错性，分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

　　5.4 BASE

　　BASE是基本可用（Basically Available）、Soft state（弱状态）、Eventually consistent（最终一致性）三个短语的简写。

　　① 基本可用，指分布式系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。

　　② 弱状态，也称为软状态，指允许系统中的二数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

　　③ 最终一致性，指系统中所有的数据副本，在经过一段时回见的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。

六、总结

　　这篇博文主要介绍了分布式的一些相关知识，更详细的知识之后会给出。谢谢各位园友的观看~

  最近有点忙，一直没更新博客，继续坚持下去。

一、背景 

  1. 什么是缓存无底洞问题：

 2. 缓存无底洞产生的原因：

   键值数据库或者缓存系统，由于通常采用hash函数将key映射到对应的实例，造成key的分布与业务无关，但是由于数据量、访问量的需求，需要使用分布式后（无论是客户端一致性哈性、redis-cluster、codis），批量操作比如批量获取多个key(例如redis的mget操作)，通常需要从不同实例获取key值，相比于单机批量操作只涉及到一次网络操作，分布式批量操作会涉及到多次网络io。

3. 无底洞问题带来的危害：

  (1) 客户端一次批量操作会涉及多次网络操作，也就意味着批量操作会随着实例的增多，耗时会不断增大。

  (2) 服务端网络连接次数变多，对实例的性能也有一定影响。

 
4. 结论：

  用一句通俗的话总结：更多的机器不代表更多的性能，所谓“无底洞”就是说投入越多不一定产出越多。

  分布式又是不可以避免的，因为我们的网站访问量和数据量越来越大，一个实例根本坑不住，所以如何高效的在分布式缓存和存储批量获取数据是一个难点。

二、哈希存储与顺序存储

   在分布式存储产品中，哈希存储与顺序存储是两种重要的数据存储和分布方式，这两种方式不同也直接决定了批量获取数据的不同，所以这里需要对这两种数据的分布式方式进行简要说明：

   1. hash分布：

   hash分布应用于大部分key-value系统中，例如memcache, redis-cluster, twemproxy，即使像mysql在分库分表时候，也经常会用user%100这样的方式。

   hash分布的主要作用是将key均匀的分布到各个机器，所以它的一个特点就是数据分散度较高，实现方式通常是hash(key)得到的整数再和分布式节点的某台机器做映射，以redis-cluster为例子：

   问题：和业务没什么关系，不支持范围查询。

  2. 顺序分布

 3. 两种分布方式的比较：

三、分布式缓存/存储四种Mget解决方案

1. IO的优化思路：

  (1) 命令本身的效率：例如sql优化，命令优化

  (2) 网络次数：减少通信次数

  (3) 降低接入成本:长连/连接池,NIO等。

  (4) IO访问合并:O(n)到O(1)过程:批量接口(mget),

2.  如果只考虑减少网络次数的话，mget会有如下模型：

3. 四种解决方案：

(1).串行mget

将Mget操作(n个key)拆分为逐次执行N次get操作, 很明显这种操作时间复杂度较高，它的操作时间=n次网络时间+n次命令时间，网络次数是n，很显然这种方案不是最优的，但是足够简单。

(2). 串行IO

    将Mget操作(n个key)，利用已知的hash函数算出key对应的节点，这样就可以得到一个这样的关系：Map<node, somekeys>，也就是每个节点对应的一些keys

    它的操作时间=node次网络时间+n次命令时间，网络次数是node的个数，很明显这种方案比第一种要好很多，但是如果节点数足够多，还是有一定的性能问题。

(3). 并行IO

   此方案是将方案（2）中的最后一步，改为多线程执行，网络次数虽然还是nodes.size()，但网络时间变为o(1)，但是这种方案会增加编程的复杂度。

   它的操作时间=1次网络时间+n次命令时间

(4). hash-tag实现。

    第二节提到过，由于hash函数会造成key随机分配到各个节点，那么有没有一种方法能够强制一些key到指定节点到指定的节点呢?

    redis提供了这样的功能，叫做hash-tag。什么意思呢？假如我们现在使用的是redis-cluster（10个redis节点组成），我们现在有1000个k-v，那么按照hash函数(crc16)规则，这1000个key会被打散到10个节点上，那么时间复杂度还是上述(1)~(3)

    那么我们能不能像使用单机redis一样，一次IO将所有的key取出来呢？hash-tag提供了这样的功能，如果将上述的key改为如下，也就是用大括号括起来相同的内容，那么这些key就会到指定的一个节点上。

   例如：

Java代码  

1. user1,user2,user3......user1000  
2. {user}1,{user}2,{user}3.......{user}1000  

例如下图：它的操作时间=1次网络时间+n次命令时间

3. 四种批量操作解决方案对比：

四、总结和建议

    无底洞问题对资源和性能有一定影响，但是其实大部分系统不需要考虑这个问题，因为

    1. 99%公司的数据和流量无法和facebook相比。

    2. redis/memcache的分布式集群通常来讲是按照项目组做隔离的，以我们经验来看一般不会超过50对主从。   

    所以这里只是提供了一种优化的思路，开阔一下视野。

五、参考文献

1. Facebook's Memcached Multiget Hole: More machines != More Capacity  
2. Multiget的无底洞问题
3. 再说memcache的multiget hole（无底洞）

   一、什么是缓存雪崩

      从下图可以很清晰出什么是缓存雪崩：

      1. 由于Cache层承载着大量请求，有效的保护了Storage层(通常认为此层抗压能力稍弱)，所以Storage的调用量实际很低，所以它很爽。

      2. 但是，如果Cache层由于某些原因(宕机、cache服务挂了或者不响应了)整体crash掉了，也就意味着所有的请求都会达到Storage层，所有Storage的调用量会暴增，所以它有点扛不住了，甚至也会挂掉 

    二、 缓存雪崩的危害

           雪崩的危害显而易见，通常来讲可能很久以前storage已经扛不住大量请求了，于是加了cache层，所以雪崩会使得storage压力山大，甚至是挂掉。   

    三、如何预防缓存雪崩

    1. 保证Cache服务高可用性：

        和飞机都有多个引擎一样，如果我们的cache也是高可用的，即使个别实例挂掉了，影响不会很大（主从切换或者可能会有部分流量到了后端），实现自动化运维。例如：

     memcache的一致性hash：

     redis的sentinel和cluster机制：

   有关memcache和redis的高可用方案，之后会有文章进行介绍。

  2. 依赖隔离组件为后端限流：

      其实无论是cache或者是mysql, hbase, 甚至别人的API，都会出现问题，我们可以将这些视同为资源，作为并发量较大的系统，假如有一个资源不可访问了，即使设置了超时时间，依然会hang住所有线程，造成其他资源和接口也不可以访问。

      相信大家一定遇到过这样的页面：这些应该就是淘宝的降级策略。

       降级在高并发系统中是非常正常的：比如推荐服务中，很多都是个性化的需求，假如个性化需求不能提供服务了，可以降级补充热点数据，不至于造成前端页面是个大空白（开了天窗了）

       在实际项目中，我们对重要的资源都进行隔离，比如hbase, elasticsearch, zookeeper, redis，别人的api(可能是http, rpc)，让每种资源都单独运行在自己的线程池中，即使资源出现了问题，对其他服务没有影响。

       但是线程池如何管理，比如如何关闭资源池，开启资源池，资源池阀值管理，这些做起来还是相当麻烦的，幸好netfilx公司提供了一个很牛逼的工具：hystrix，可以做各种资源的线程池隔离。

        有关hystrix的详细介绍可以参考：http://hot66hot.iteye.com/blog/2155036

        hystrix附图：

3. 提前演练：

   在项目上线前，通过演练，观察cache crash后，整体系统和storage的负载, 提前做好预案。  

转载请注明出处哈:http://carlosfu.iteye.com/blog/2269678

     

         

Java代码  

1. package com.carlosfu.service;  
2.   
3. import org.apache.commons.lang.StringUtils;  
4.   
5. import com.carlosfu.cache.Cache;  
6. import com.carlosfu.storage.Storage;  
7.   
8. /** 
9.  * 某服务 
10.  *  
11.  * @author carlosfu 
12.  * @Date 2015-10-11 
13.  * @Time 下午6:28:46 
14.  */  
15. public class XXXService {  
16.   
17.     /** 
18.      * 缓存 
19.      */  
20.     private Cache cache = new Cache();  
21.   
22.     /** 
23.      * 存储 
24.      */  
25.     private Storage storage = new Storage();  
26.   
27.     /** 
28.      * 模拟正常模式 
29.      * @param key 
30.      * @return 
31.      */  
32.     public String getNormal(String key) {  
33.         // 从缓存中获取数据  
34.         String cacheValue = cache.get(key);  
35.         // 缓存为空  
36.         if (StringUtils.isBlank(cacheValue)) {  
37.             // 从存储中获取  
38.             String storageValue = storage.get(key);  
39.             // 如果存储数据不为空,将存储的值设置到缓存  
40.             if (StringUtils.isNotBlank(storageValue)) {  
41.                 cache.set(key, storageValue);  
42.             }  
43.             return storageValue;  
44.         } else {  
45.             // 缓存非空  
46.             return cacheValue;  
47.         }  
48.     }  
49.   
50.   
51.     /** 
52.      * 模拟防穿透模式 
53.      * @param key 
54.      * @return 
55.      */  
56.     public String getPassThrough(String key) {  
57.         // 从缓存中获取数据  
58.         String cacheValue = cache.get(key);  
59.         // 缓存为空  
60.         if (StringUtils.isBlank(cacheValue)) {  
61.             // 从存储中获取  
62.             String storageValue = storage.get(key);  
63.             cache.set(key, storageValue);  
64.             // 如果存储数据为空，需要设置一个过期时间(300秒)  
65.             if (StringUtils.isBlank(storageValue)) {  
66.                 cache.expire(key, 60 * 5);  
67.             }  
68.             return storageValue;  
69.         } else {  
70.             // 缓存非空  
71.             return cacheValue;  
72.         }  
73.     }  
74.   
75. }  

 

  

 一、什么是缓存粒度

    下面这个图是很多项目关于缓存使用最常用的一个抽象，那么我们假设storage层为mysql, cache层为redis。

    假如我现在需要对视频的信息做一个缓存，也就是需要对select * from video where id=?的每个id在redis里做一份缓存，这样cache层就可以帮助我抗住很多的访问量（注：这里不讨论一致性和架构等等问题，只讨论缓存的粒度问题）。

    我们假设视频表有100个属性（这个真有，有些人可能难以想象），那么问题来了，需要缓存什么维度呢，也就是有两种选择吧：

Java代码  

1. (1)cache(id)=select * from video where id=#id  
2. (2)cache(id)=select importantColumn1, importantColumn2 .. importantColumnN from video where id=#id  

    其实这个问题就是缓存粒度问题，我们在缓存设计应该佮预估和考虑呢？下面我们将从通用性、空间、代码维护三个角度进行说明。

二、全部数据和部分数据比较

1. 两者的特点是显而易见的：

2. 通用性：

    如果单从通用性上看，全部数据是最优秀的，但是有个问题就是是否有必要缓存全部数据，认为以后会有这样的需求，但是从经验看除了非常重要的信息，那些不重要的字段基本不会在需求里出现，也就是说这种通用性 通常都是想象出来的。太多人觉得通用性是最重要的。vid拿一些基本信息，会想专辑明星。。要不要用通用性高的，于是加了全局的，通用性很重要，但是要想清楚。

3. 空间占用：

    很显然，缓存全部数据，会占用大量的内存，有人会说，不就费一点内存吗，能有多少钱？而且已经有人习惯了把缓存当做下水道来使用，什么都框框的往里面放，但是我这里要说内存并不是免费的，可以说是很珍贵的资源。instagram21->4G的例子就说明了这个道理，好的程序员可以帮助公司节约大量的资源。

    而且单个cache(id)也带来两个问题：序列化的开销和网络流量的开销（QPS,百倍），都是无容忽视的。

4. 代码维护：

    代码维护性，全部数据的优势更加明显，而部分数据一旦要加新字段就会修改代码，而且还需要对原来的数据进行刷新。

三、总结：

 缓存粒度问题是一个容易被忽视的问题，如果使用不当，可能会造成很多无用空间的浪费，可能会造成网络带宽的浪费，可能会造成代码通用性较差等情况，必须学会综合数据通用性、空间占用比、代码维护性 三点评估取舍因素权衡使用。

一、缓存的成本和收益是什么：

  既然要讨论是否真的需要缓存这个问题，就要知道缓存带来的成本与收益（好处、坏处）是什么？

  上面的表格应该清楚的表达了使用缓存后的收益和成本分别是什么。下面将进行详细的解析

二、缓存成本与收益详解：

  1. 收益是很明显的，通常来说一个设计还不错的缓存系统，能够帮助你的业务实现加速读写，同时帮助降低了后端负载。

   (1) 加速读写：通常来说加速是明显的，因为缓存通常都是全内存的系统，而后端（可能是mysql、甚至是别人的HTTP, RPC接口）都有速度慢和抗压能力差的特性，通过缓存的使用可以有效的提高用户的访问速度同时优化了用户的体验。

   (2) 降低后端负载：通过缓存的添加，如果程序没有什么问题，在命中率还可以的情况下，可以帮助后端减少访问量和复杂计算(join、或者无法在优化的sql等)，在很大程度降低了后端的负载。

  2. 成本：

   (1) 数据不一致性：无论你的设计做的多么好，缓存数据与权威数据源（可以理解成真实或者后端数据源）一定存在着一定时间窗口的数据不一致性，这个时间窗口的大小可大可小，具体多大还要看一下你的业务允许多大时间窗口的不一致性。

   (2) 代码维护成本：加入缓存后，代码就会在原数据源基础上加入缓存的相关代码，例如原来只是一些sql, 现在要加入k-v缓存，必然增加了代码的维护成本。

   (3) 架构复杂度：加入缓存后，例如加入了redis-cluster，一般来说缓存不会像Mysql有专门的DBA，很有可能没有专职的管理人员，所以也增加了架构的复杂度和维护成本。

三、如何选择？

  如果当前系统的访问速度和访问量能够满足现有的要求，就不必增加缓存，其实像mysql并没有那么差，一台运行良好的Mysql，扛个QPS=1000没什么问题。

  如果要加入选择了缓存，一定要能给出足够的理由，不是为了简单的show技术和想当然，最好的方法就是用数据说话：加速比有多少、后端负载降低了多少。

四、什么样的场景需要缓存？

    在公司里，据我观察，无论怎么更新架构，使用各种新技术，但是80%的项目还是离不开SQL的，下面我们以SQL作为后端数据源、以Redis作为缓存层，说一下哪些场景是需要缓存的。

1、复杂开销大的计算、降低后端负载

    以Mysql为例子，一些复杂的操作或者计算(例如大量联表操作、一些分组计算)，如果不加

缓存，大量流量将在这些复杂计算的执行。

2. 加速请求响应

    即使单条后端数据足够快（例如select * from table where id=?），那么依然可以利用redis/memcache将这些操作进行merge做优化(例如：cache(select * from table where id in(id1,id10....idK)))，从而优化整个IO链的相应时间。

附图一张：

 一、缓存的几种更新策略

  从下面的表格看，缓存的更新策略大致分为三种，本文将从一致性和维护成本两个方面对于三种缓存更新策略进行简要说明，因为这些东西比较理论和抽象，如哪里说得不对，欢迎拍砖。

  注：

  (1) 一致性：缓存和真实数据源（例如mysql, hbase, elasticsearch等等）是否存在一段时间数据的不一致。

  (2) 维护成本: 开发人员的开发和维护成本。

二、LRU/LFU/FIFO算法剔除

1. 使用场景：

    通常用于缓存使用量超过了预设的最大值时候（缓存空间不够），如何对现有的数据进行清理。例如FIFO会把最新进入缓存的数据清理出去, LRU会把最近最少使用的数据清理掉。

例如：Memcache使用的是LRU，具体Memcache如何实现的，这里就不在赘述了，网上资料多的是。

例如：Redis使用maxmemory-policy这个配置作为内存最大值后对于数据的更新策略。

• volatile-lru -> 用lru算法删除过期的键值
• allkeys-lru -> 用lru算法删除所有键值
• volatile-random -> 随机删除过期的键值
• allkeys-random -> 随机删除任何键值
• volatile-ttl -> 删除最近要到期的键值
• noeviction -> 不删除键，只返回一个错误

2. 常用算法：

这里不再赘述，常用的算法有如下几种：

FIFO[first in first out] 

LFU[Less Frequently Used] 

LRU[Least Recently used] 

3. 一致性

可以想象，要清理哪些数据，不是由开发者决定（只能决定大致方向：策略算法），数据的一致性是最差的。

4. 维护成本

这些算法不需要开发者自己来实现，通常只需要配置最大maxmemory和对应的策略即可。

开发者只需要有这个东西，知道是什么意思，选择自己需要的算法，算法的实现是由缓存服务器实现的。

三、超时剔除

1. 使用场景：

   就是我们通常做的缓存数据过期时间设置，例如redis和memcache都提供了expire这样的API，来设置K-V的过期时间。

   一般来说业务可以容忍一段时间内（例如一个小时），缓存数据和真实数据（例如：mysql, hbase等等）数据不一致（一般来说，缓存可以提高访问速度降低后端负载），那么我们可以对一个数据设置一定时间的过期时间，在数据过期后，再从真实数据源获取数据，重新放到缓存中，继续设置过期时间。

   例如： 一个视频的描述信息，我们可以容忍一个小时内数据不一致，但是涉及到钱的方面，如果不一致可想而知。

2. 一致性：

    一段时间内（取决于过期时间）存在数据一致性问题，即缓存数据和真实数据源数据不一致。

3. 维护成本

      用户的维护成本不是很高，只需要设置expire过期时间即可（前提是你的业务允许这段时间可能发生的数据不一致）。

四、主动更新

1. 使用背景：

   业务对于数据的一致性要求很高，需要在真实数据更新后，立即更新缓存数据。

   具体做法：例如可以利用消息系统或者其他方式（比如数据库触发器，或者其他数据源的listener机制来完成）通知缓存更新。

2.  一致性：

   可以想象一致性最高（几乎接近强一致），但是有个问题：如果主动更新发生了问题，那么这条数据很可能很长时间不会更新了（所以可以结合超时剔除一起使用，下面最佳实践会说到）

3. 维护成本：

   相当高，用户需要自己来完成更新（需要一定量的代码，从某种程度上加大了系统的复杂性），需要自己检查数据是否真的更新了之类的工作。

五、最佳实践

    其实最佳实践就是组合使用：

    1. 一般来说我们都需要配置超过最大缓存后的更新策略（例如：LRU）以及最大内存，这样可以保证系统可以继续运行（例如redis可能存在OOM问题）（极端情况下除外，数据一致性要求极高）。

    2. 一般来说我们需要把超时剔除和主动更新组合使用，那样即使主动更新出了问题，也能保证过期时间后，缓存就被清除了（不至于永远都是脏数据）。