我要评论cap理论
cap理论告诉我们，一个分布式系统不可能同时满足以下三种
- 一致性（c:consistency）
- 可用性（a:available）
- 分区容错性（p:partition tolerance）
这三个基本要求，最多只能同时满足其中的两项，因为p是必须的，因此往往选择就在cp或者ap中
（1）一致性（c:consistency）
在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
（2）可用性（a:available）
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
（3）分区容错性（p:partition tolerance）
分布式系统在遇到任何网络分区故障的时候，仍然需要保证对外提供满足一致性和可用性，除非是整个网络环境都发生了故障(多个副本，其中几个副本down掉不影响系统使用)
zookeeper保证的是cp
（1）zookeeper不能保证每次服务请求的可用性。（注：在极端环境下，zookeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，zookeeper不能保证服务可用性
（2）进行leader选举时集群都是不可用。
paxos算法
paxos算法：一种基于消息传递且具有高度容错特性的一致性算法。
paxos算法解决的问题：就是如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。
在一个paxos系统中，首先将所有节点划分为proposer（提议者），acceptor（接受者）和learner（学习者）。（注意：每个节点都可以身兼数职）。
prepare准备阶段
- proposer向多个acceptor发出propose请求promise（承诺）
- acceptor针对收到的propose请求进行promise（承诺）
accept接受阶段
- proposer收到多数acceptor承诺的promise后，向acceptor发出propose请求（承诺）
- acceptor针对收到的propose请求进行accept处理
learn学习阶段
- proposer将形成的决议发送给所有learners
（1）prepare：proposer生产全局唯一且递增的proposal id，向所有acceptor发送propose请求，这里无需携带提案内容，只携带proposal id即可。
（2）promise：acceptor收到propose请求后，做出“两个承诺，一个应答”。
- 不再接受proposal id小于等于（注意：这里是<=）当前请求的propose请求。
- 不再接受proposal id小于（注意：这里是<）当前请求的accept请求。
- 不违背以前做出的承诺下，回复已经accept过的提案中proposal id最大的那个提案的value和proposal id，没有则返回空值。
（3）propose：proposer收到多数acceptor的promise应答后，从应答中选择proposal id最大的提案的value，作为本次要发起的提案。如果所有应答的提案value均为空值，则可以自己随意决定提案value。然后携带当前proposal id，向所有acceptor发送propose请求。
（4）accept：acceptor收到propose请求后，在不违背自己之前做出的承诺下，接受并持久化当前proposal id和提案value。
（5）learn：proposer收到多数acceptor的accept后，决议形成，将形成的决议发送给所有leader。
情况1：
有a1，a2，a3，a4，a5 5位议员，就税率问题进行决议
- a1发起1号proposal的propose，等待promise承诺；
- a2-a5回应promise；
- a1在收到两份回复时就会发起税率10%的proposal；
- a2-a5回应accept；
- 通过proposal，税率10%。
情况2：
- a1、a5同时发起propose（序号分别为1,2）
- a2承诺a1，a4承诺a5，a3行为成为关键
- 情况1：a3先收到a1消息，承诺a1。
- a1发起proposal（1, 10%），a2，a3接受。
- 之后a3又收到a5消息，回复a1：（1, 10%），并承诺a5。
- a5发起proposal（2, 20%），a3，a4接受。之后a1，a5同时广播决议。
- 情况2：a3先收到a1消息，承诺a1。之后立刻收到a5消息，承诺a5.
- a1发起proposal（1, 10%），无足够响应，a1重新propose（序号3），a3再次承诺a1。
- a5发起proposal（2, 20%），无足够响应，a5重新propose（序号4），a3再次承诺a5。
- ......
造成这种情况的原因是系统重有一个以上的proposer，多个proposers互相争夺acceptor，造成迟迟无法达成一致的情况，这对这种情况，一种改进的paxos算法被提出：从系统中选出一个节点作为leader，只有leader能够发起提案。这样，一次paxos流程中只有一个proposer，不会出现活锁的情况，此时只会出现例子中第一种情况。
zab协议：
zab算法：zab借鉴了paxos算法，是特别为zookeeper设计的支持崩溃恢复的原子广播协议。基于该协议，zookeeper设计为只有一台客户端（leader）负责处理外部的写事务请求，然后leader客户端将数据同步到其它follower节点，即zookeeper只有一个leader可以发起提案。
zab协议内容：
包括两种基本的模式：消息广播、崩溃恢复。
（1）客户端发起一个写操作请求。
（2）leader服务器将客户端的请求转化为事务proposal提案，同时为每个proposal分配一个全局的id，即zxid。
（3）leader服务器为每个follower服务器分配一个单独的队列，然后将需要广播的proposal依次放到队列中去，并且根据fifo策略进行消息发送。
（4）follower接收到proposal后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后leader反馈一个ack(确认消息)响应消息。
（5）leader接收到超过半数以上follower的ack响应消息后，即认为消息发送成功，可以发送commit消息。
（6）leader向所有follower广播commit消息，同时自身也会完成事务提交。follower接收到commit消息后，会将上一条事务提交。
（7）zookeeper采用zab协议的核心，就是只要有一台服务器提交了proposal，就要确认所有的服务器最终都能正确提交proposal
崩溃恢复：
一旦leader服务器出现崩溃或者由于网络原因导致leader服务器失去了与过半follower的联系，那么就会进入崩溃恢复模式
1）假设两种服务器异常情况：
（1）假设一个事务在leader提出之后，leader挂了。
（2）一个事务在leader上提交了，并且过半的follower都响应ack了，但是leader在commit消息发出之前挂了。
2）zab协议崩溃恢复要求满足以下两个要求：
（1）确保已经被leader提交的提案proposal，必须最终被所有的follower服务器提交。（已经产生的提案，follower必须执行）
（2）确保丢弃已经被leader提出的，但是没有被提交的proposal。（丢弃胎死腹中的提案）
崩溃恢复——leader选举：
崩溃恢复主要包括两部分：leader选举和数据恢复
leader选举：根据上述要求，zab协议需要保证选举出来的leader需要满足以下条件：
（1）新选举出来的leader不能包含未提交的proposal。即新leader必须都是已经提交了proposal的follower服务器节点。
（2）新选举的leader节点中含有最大的zxid。这样做的好处是可以避免leader服务器检查proposal的提交和丢弃工作。
崩溃恢复——数据恢复：
崩溃恢复主要包括两部分：leader选举和数据恢复
zab如何数据同步：
（1）完成leader选举后，在正式开始工作之前（接收事务请求，然后提出新的proposal），leader服务器会首先确认事务日志中的所有的proposal是否已经被集群中过半的服务器commit。
（2）leader服务器需要确保所有的follower服务器能够接收到每一条事务的proposal，并且能将所有已经提交的事务proposal应用到内存数据中。等到follower将所有尚未同步的事务proposal都从leader服务器上同步过，并且应用到内存数据中以后，leader才会把该follower加入到真正可用的follower列表中。
发表评论