标签：分析 可用性 ZK Zookeeper 源码 解析 Leader 服务端
Zookeeper 源码分析
算法基础
拜占庭将军问题
Paxos 算法
ZAB 协议
CAP
CAP理论告诉我们， 一个分布式系统不可能同时满足以下三种
CAP理论
一致性（C:Consistency）
可用性（A:Available）
分区容错性（ P:Partition Tolerance）
这三个基本需求， 最多只能同时满足其中的两项， 因为P是必须的， 因此往往选择就在CP或者AP中。
1） 一致性（ C:Consistency）
在分布式环境中， 一致性是指数据在多个副本之间是否能够保持数据一致的特性。 在一致性的需求下， 当一个系统在数据一致的状态下执行更新操作后， 应该保证系统的数据仍然处于一致的状态。
2） 可用性（A:Available）
可用性是指系统提供的服务必须一直处于可用的状态， 对于用户的每一个操作请求总是能够在有限的时间内返回结果。
3） 分区容错性（ P:Partition Tolerance）
分布式系统在遇到任何网络分区故障的时候， 仍然需要能够保证对外提供满足一致性和可用性的服务， 除非是整个网络环境都发生了故障。
ZooKeeper保证的是CP
（1） ZooKeeper不能保证每次服务请求的可用性。 （注：在极端环境下， ZooKeeper可能会丢弃一些请求， 消费者程序需要重新请求才能获得结果） 。 所以说， ZooKeeper不能保证服务可用性。
（2） 进行Leader选举时集群都是不可用。
源码详解
辅助源码
ZK 服务端初始化源码解析
ZK 服务端加载数据源码解析
ZK 选举源码解析
Follower 和 Leader 状态同步源码
服务端 Leader 启动
服务端 Follower 启动
客户端启动
客户端初始化源码解析
标签：分析,可用性,ZK,Zookeeper,源码,解析,Leader,服务端 来源： https://blog.csdn.net/qq_44226094/article/details/121585085
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。