zookeeper学习笔记（1）分布式架构 - ACID、CAP、BASE分布式理论

落日映苍穹つ 2022-05-27 03:06 210阅读 0赞

*  集中事务处理 - ACID
 *  分布式事务处理 - CAP
 *  分布式事务处理 - BASE

--------------------

# **集中事务处理 - ACID** #

> **集中式系统**：集中式系统指由一台或者多台主机组成中心节点，数据集中存储在中心节点中。  
> **分布式系统**：分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信协调。

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库

（1）原子性  
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

（2）一致性  
一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。

（3）隔离性  
隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。  
![这里写图片描述][70]  
隔离级别越高，越能保证数据的一致性，但是对性能影响也越大，比较科学的方法是使用悲观锁和乐观所来进行事务控制。

（4）持久性  
在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

对于集中式事务来说，ACID就可以满足。但是当数据分不到不同机器上的时候，单纯的ACID就不能满足一致性要求，这时候就需要CAP和BASE理论。

--------------------

# **分布式事务处理 - CAP** #

可用性和一致性很难有两全其美的解决方案，CAP告诉我们，一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Tolerance of network Partition）

> **一致性（Consistency）**：指数据在多个副本之间是能够保持一致的特性。  
> **可用性（Availability）**：服务一直处在可用的状态，对用户每一个请求都能在**有限的时间**内返回结果。超出时间或者出现错误则认为系统是不可用的。  
> **分区容错性（Tolerance of network Partition）**：分布式系统在任何网络分区出现故障的时候，仍然保证对外提供一致性和可用性服务。

架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。大型网站，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。架构师用一般需要根据业务特点在C（一致性）和A（可用性）之间寻求平衡。

比如亚马逊的AWS就是保证了高一致性和分区容错性的前提下，极大的提升可用性。

--------------------

# **分布式事务处理 - BASE** #

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。其核心思想是即使无法做到强一致性(Strong consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

> **强一致性**：在更新完成后，任何后续访问都将返回更新过的值。  
> **最终一致性**：最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。  
> **软状态**：是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。  
> **基本可用**：基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。比如正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1～2秒。

**弱一致性中最主要的就是最终一致性：**  
最终一致性就是比如你往一个分支节点写入一个数据，然后立马去读这个数据，这个系统不保证你能立马读到这个数据。但是你最终会读到的。  
数据达到最终一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。

比如DNS就是一个典型的最终一致性的例子。  
假设我们在Godaddy上将自己的ip映射要一个域名上进行绑定，然后马上在网站上登录该域名。可能是登录不上的，需要等待5-10分钟。  
![这里写图片描述][70 1]  
因为你刚绑定的域名可能先要上传到.com的服务器上，甚至root的服务器上，然后再一步步的向下覆盖，才能最终达成一致。

**强一致性**  
google spanner 运行在了google cloud上，cloud spanner是全球分布式数据库并且完全一致，解决了很多服务提供商的分布式问题。比如一些银行系统和一些关键数据等需要强一致性的服务。

强一致性算法

> Paxos  
> Ratf(multi - paxos)  
> ZAB(multi - paxos)

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。

[70]: /images/20220527/572cd8617eee49e1b4d643fc952bc243.png
[70 1]: /images/20220527/7bc9751866ff48a6b0e909ee22752606.png