本文共 1484 字，大约阅读时间需要 4 分钟。

分布式系统

• 分布式：分布式系统中的多台计算机都会再空间上随意的分布
• 对等性：分布式系统中的计算机没有主/从之分
• 并发性：更新的并发性

分布式的问题

• 通信异常：消息丢失和消息延迟
• 网络分区：网络延时不断增大，只有部分节点可以正常通信，局部小集群要完成原本需要整个分布式系统才能完成的任务
• 三态：成功，失败，超时
• 节点故障：机器宕机

ACID到CAP/BASE

1. ACID
   事务：是由一系列对系统中数据进行访问和更新的操作所组成的一个程序的执行逻辑单元；
   原子性：事务中包含的各项操作只允许两种状态：全部成功执行，全部不执行；
   一致性：事务的执行结果必须使得数据库从一个一致性状态转变到另外一个一致性状态；
   隔离性：再并发环境下，并发的事务时相互隔离的，有四个隔离级别，读未提交，读已提交，可重复读，串行化；
   持久性：一个是事务一旦提交，它对数据库对应数据的状态变更就应该时永久性的。

分布式事务：一个跨银行的转账操作涉及两个服务，包括本地银行的取款服务，目标银行的存款服务；

CAP理论和BASE理论

一个分布式系统不可能同时满足一致性、可用性、分区容错性，最多只能满足其中的两个

• 一致性：数据在多个副本之间保持一致性
• 可用性：是指系统提供的服务必须一致处于可用的状态，对于用户的每一个操作的请求总是能够在有限的时间内返回结果
• 分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务。
  

用CAP理论来分析ZooKeeper

CAP理论告诉我们，一个分布式系统不可能同时满足以下三种

• 一致性（C:Consistency）
• 可用性（A:Available）
• 分区容错性（P:Partition Tolerance）
  这三个基本需求，最多只能同时满足其中的两项，因为P是必须的,因此往往选择就在CP或者AP中。

在此ZooKeeper保证的是CP

**分析：**可用性（A:Available）

不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，ZooKeeper不能保证服务可用性。

进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性

BASE理论

• basically available基本可用
• soft state 软状态
• eventually consistence 最终一致性

BASE是对CAP中一致性和可用性权衡的结果，是基于CAP定理演化而来的，其核心是无法做到强一致性，但是每个应用可以根据自身的业务特点，采用适当的方式来使系统达到最终的一致性。

• 基本可用：是指分布式出现不可预知的故障的时候，允许损失部分可用性；响应时间的损失，时间变慢了；功能上的损失，步骤变繁琐了；

• 软状态：允许系统中的数据存在中间状态，并认为改中间状态存在不会影响系统的整体的可用性；

• 最终一致性：系统中的所有副本，经过一段时间同步后，最终能够达到一个一致性状态；

转载地址：https://blog.csdn.net/weixin_37850264/article/details/111655695 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！