zookeeper基本特性、使用场景、分布式带来的CAP问题、分布式BASE理论

注：本博客原始资料来自于享学课堂

目录

1、分布式带来的问题

2、CAP理论

3、BASE理论

4、zookeeper的优势

5、为什么使用zookeeper，zookeeper使用场景

---

1、分布式带来的问题

1. 通信异常
2. 网络分区
3. 三态(成功，失败，超时)
4. 节点故障

针对上面带来的问题，就有了相应的解决办法

2、CAP理论

• C 一致性（consistence）：数据在分布式环境下的多个副本之间能否保持一致性，这里的一致性更多是指强一致性；
• A 可用性（able）：分布式系统一直处于可用状态，对于请求总是能在有限的时间内返回结果致性；
• P 分区容错性(partition)：除非整个网络故障，分布式系统在任何网络或者单点故障时，仍能对外提供满足一致性和可用性的服务；

一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求，最多只能同时满足其中的两项；（满足A

放弃P （满足AC）	将数据和服务都放在一个节点上，避免因网络引起的负面影响，充分保证系统的可用性和一致性。但放弃P意味着放弃了系统的可扩展性
放弃A (满足PC)	当节点故障或者网络故障时，受到影响的服务需要等待一定的世界，因此在等待时间里，系统无法对外提供正常服务，因此是不可用的；
放弃C (满足AP)	系统无法保证数据的实时一致性，但是承诺数据最终会保证一致性。因此存在数据不一致的窗口期，至于窗口期的长短取决于系统的设计
放弃P	放弃P意味着使用单服务，这和分布式就背道而驰了，所以不能放弃P

所以，我们往往就花在怎么样根据业务场景在A和C直接寻求平衡；

3、BASE理论

即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性；

1. Basically Avaliable  基本可用：当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的“基本可用”；体现在“时间上的损失”和“功能上的损失”；e.g：部分用户双十一高峰期淘宝页面卡顿或降级处理；
2. Soft state 软状态：允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性；e.g：12306网站卖火车票，请求会进入排队队列；
3. Eventually consistent 最终一致性：所有的数据在经过一段时间的数据同步后，最终能够达到一个一致的状态；e.g：理财产品首页充值总金额短时不一致；

分布式一致性算法

序号	算法	说明
1	2p/3p	2p两阶段提交，数据库分布式事务经常使用的一种分布式算法，算法简单，但有出现阻塞，数据再某情况不一致的问题 3p对2p进行了完善，完善了阻塞以及可用性
2	paxos算法	分布式一致性算法，也分两个阶段，遵循少数服从多数的原则，并不需要所有参与者都同意某一协议
3	zab	借鉴paxos思路，是zookeeper解决分布式一致性所使用的算法

---

4、zookeeper的优势

ZooKeeper致力于提供一个高性能、高可用，且具备严格的顺序访问控制能力的分布式协调服务

• 简单的数据结构：共享的树形结构，类似文件系统，存储于内存；
• 可以构建集群：避免单点故障，3-5台机器就可以组成集群，超过半数正常工作就能对外提供服务；
• 顺序访问：对于每个写请求，zk会分配一个全局唯一的递增编号，利用这个特性可以实现高级协调服务；
• 高性能：基于内存操作，服务于非事务请求，适用于读操作为主的业务场景。3台zk集群能达到13w QPS；

5、为什么使用zookeeper，zookeeper使用场景

分布式环境协调和通信到底有什么场景？

 

• 数据发布订阅
• 负载均衡
• 命名服务
• Master选举
• 集群管理
• 配置管理
• 分布式队列
• 分布式锁