Zookeeper（CAP原则+⼀致性协议）
孺子可教zookeeper
⼀、zookeeper概述
ZooKeeper是⼀个的，开放源码的协调服务，是的Chubby⼀个的实现，是Hadoop和的重要组件。它是⼀个为分布式应⽤提供⼀致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的⽬标就是封装好复杂易出错的关键服务，将简单易⽤的接⼝和性能⾼效、功能稳定的系统提供给⽤户。
ZooKeeper包含⼀个简单的原语集，提供Java和C的接⼝。
⼆、CAP原则
CAP原则⼜称CAP定理，指的是在⼀个中， Consistency（⼀致性）、 Availability（可⽤性）、Partition tolerance（分区容错性），三者不可得兼。
褪黑素的作用
⼀致性（C）：在中的所有数据备份，在同⼀时刻是否同样的值。（等同于所有节点访问同⼀份最新的数据副本）
可⽤性（A）：保证每个请求不管成功或者失败都有响应。
分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。
⼀致性：
分为强⼀致性、弱⼀致性和最终⼀致性；
1、强⼀致性：
当更新操作完成之后，任何多个后续进程或者线程的访问都会**返回最新的更新过的值，直到这个数据被其他数据更新为⽌。
但是这种实现对性能影响较⼤，因为这意味着，只要上次的操作没有处理完，就不能让⽤户读取数据。
2、弱⼀致性：
系统并不保证进程或者线程的访问都会返回最新更新过的值。系统在数据写⼊成功之后，不承诺⽴即可以读到最新写⼊的值，也不会具体的承诺多久之后可以读到。甚⾄不能保证可以访问到。
3、最终⼀致性：
最终⼀致性也是弱⼀致性的⼀种，它⽆法保证数据更新后，所有后续的访问都能看到最新数值，⽽是需要⼀个时间，在这个时间之后可以保证这⼀点（就是在⼀段时间后，节点间的数据会最终达到⼀致状态），⽽在这个时间内，数据也许是不⼀致的，这个系统⽆法保证强⼀致性的时间⽚段被称为「不⼀致窗⼝」。不⼀致窗⼝的时间长短取决于很多因素，⽐如备份数据的个数、⽹络传输延迟速度、系统负载等。
可⽤性：
可⽤性指的是服务⼀直可⽤，⽽且是正常的相应时间。好的可⽤性主要是指系统能够很好的为⽤户服务，不出现⽤户操作失败或者访问超时等⽤户体验不好的情况。
分区容错性：
分布式系统在遇到⽹络故障的时候，仍然能够对外提供满⾜⼀致性和可⽤性的服务，除⾮整个⽹络环境都发⽣了故障
三、⼀致性协议
又是一年春草绿2PC：
它可以保证在分布式事务中，要么所有参与进程都提交事务，要么都取消事务，即实现 ACID 的原⼦性（A）。
在数据⼀致性中，它的含义是：要么所有副本（备份数据）同时修改某个数值，要么都不更改，以此来保证数据的强⼀致性。
2PC分为2个阶段土建部分
1、表决阶段：
1、事务询问
Coordinator （协调者）向所有的参与者发送⼀个 vote request
2、执⾏事务
各个参与者节点执⾏事务操作，并讲Undo和Redo信息记⼊事务⽇志中
一年级学生的特点3、各参与者向协调者反馈事务询问的响应.
如果参与者成功执⾏了事务操作，那么就反馈给协调者vote_commit响应，表⽰事务可以执⾏，如果没有参与者成功执⾏事务，那么就反馈给协调者vote_abort响应，表⽰事务不可以执⾏.
2、提交阶段：
Coordinator 收到所有参与者的表决信息，如果所有参与者⼀致认为可以提交事务，那么 Coordinator 就会发送 GLOBAL_COMMIT 消息，否则发送 GLOBAL_ABORT 消息；对于参与者⽽⾔，如果收到 GLOBAL_COMMIT 消息，就会提交本地事务，否则就会取消本地事务。
2PC的问题
1、同步阻塞：2PC 有⼏个过程（⽐如 Coordinator 等待所有参与者表决的过程中）都是同步阻塞的，所有参与该事务操作的逻辑都处于阻塞状态，各个参与者在等待其他参与者响应的过程中，将⽆法进⾏其他任何操作。在实际的应⽤中，这个问题是通过超时判断机制来解决的，但并不能完全解决同步阻塞问题；
2、Coordinator 单点问题：实际⽣产应⽤中，Coordinator 都会有相应的备选节点；
3、数据不⼀致：这个在前⾯已经讲述过了，如果在第⼆阶段，Coordinator 和参与者都出现挂掉的情况下，是有可能导致数据不⼀致的。3PC：
三阶段提交协议（Three-Pha Commit， 3PC）最关键要解决的就是 Coordinator 和参与者同时挂掉导致数据不⼀致的问题，所以 3PC 把在 2PC 中⼜添加⼀个阶段，这样三阶段提交就有：CanCommit、PreCommit 和 DoCommit 三个阶段。
CanCommit
1.事务询问协调者向参与者发送CanCommit请求。询问是否可以执⾏事务提交操作。然后开始等待参与者的响应。
2.响应反馈参与者接到CanCommit请求之后，正常情况下，如果其⾃⾝认为可以顺利执⾏事务，则返回Yes响应，并进⼊预备状态。否则反馈No
我国地形特点PreCommit
执⾏事务预提交：如果 Coordinator 接收到各参与者反馈都是Yes，那么执⾏事务预提交：
发送预提交请求：Coordinator 向各参与者发送 preCommit 请求，并进⼊ prepared 阶段；
事务预提交：参与者接收到 preCommit 请求后，会执⾏事务操作，并将 Undo 和 Redo 信息记录到事务⽇记中；
各参与者向 Coordinator 反馈事务执⾏的响应：如果各参与者都成功执⾏了事务操作，那么反馈给协调者 ACK 响应，同时等待最终指令，提交 commit 或者终⽌ abort，结束流程；
中断事务：如果任何⼀个参与者向 Coordinator 反馈了 No 响应，或者在等待超时后，Coordinator ⽆法接收到所有参与者的反馈，那么就会中断事务。
发送中断请求：Coordinator 向所有参与者发送 abort 请求；
中断事务：⽆论是收到来⾃ Coordinator 的 abort 请求，还是等待超时，参与者都中断事务
doCommit
执⾏提交
发送提交请求：假设 Coordinator 正常⼯作，接收到了所有参与者的 ack 响应，那么它将从预提交阶段进⼊提交状态，并向所有参与者发送 doCommit 请求；
事务提交：参与者收到 doCommit 请求后，正式提交事务，并在完成事务提交后释放占⽤的资源；
反馈事务提交结果：参与者完成事务提交后，向 Coordinator 发送 ACK 信息；
完成事务：Coordinator 接收到所有参与者 ack 信息，完成事务。
在doCommit阶段，如果参与者⽆法及时接收到来⾃协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进⾏事务的提交。（其实这个应该是基于概率来决定的，当进⼊第三阶段时，说明参与者在第⼆阶段已经收到了PreCommit请求，那么协调者产⽣PreCommit 请求的前提条件是他在第⼆阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（⼀旦参与者收到了PreCommit，意味他知道⼤家其实都同意修改了）所以，⼀句话概括就是，当进⼊第三阶段时，由于⽹络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的⼏率很⼤。）
中断事务：
假设 Coordinator 正常⼯作，并且有任⼀参与者反馈 No，或者在等待超时后⽆法接收所有参与者的反馈，都会中断事务。
发送中断请求：Coordinator 向所有参与者节点发送 abort 请求；
抽象反义词事务回滚：参与者接收到 abort 请求后，利⽤ undo ⽇志执⾏事务回滚，并在完成事务回滚后释放占⽤的资源；
反馈事务回滚结果：参与者在完成事务回滚之后，向 Coordinator 发送 ack 信息；
中断事务：Coordinator 接收到所有参与者反馈的 ack 信息后，中断事务。
双鱼女和狮子男3PC 分析
3PC 虽然解决了 Coordinator 与参与者都异常情况下导致数据不⼀致的问题，3PC 依然带来其他问题：⽐如，⽹络分区问题，在preCommit 消息发送后突然两个机房断开，这时候 Coordinator 所在机房会 abort, 另外剩余参与者的机房则会 commit。
⽽且由于3PC 的设计过于复杂，在解决2PC 问题的同时也引⼊了新的问题，所以在实际上应⽤不是很⼴泛。
2PC与3PC的区别
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为⼀旦参与者⽆法及时收到来⾃协调者的信息之后，他会默认执⾏commit。⽽不会⼀直持有事务资源并处于阻塞状态。但是这种机制也会导致数据⼀致性问题，因为，由于⽹络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执⾏了commit操作。这样就和其他接到abort命令并执⾏回滚的参与者之间存在数据不⼀致的情况。
