标签：事务 CAP 读书笔记 Zookeeper 分布式系统 一致性 数据 分布式
第一章 分布式架构
文章目录
1.1 从集中式到分布式
大型主机时代的到来，集中式的计算机系统架构成为主流，在那个时候，由于大型主机卓越的性能和良好的稳定性，在单机处理能力方面优势十分明显。
其中大型主机昂贵，另外一个重要的一点是，集中式系统具有明显的单点问题，虽然大型主机在性能和稳定性方面表现卓越，但不代表不会发生故障，因此，一旦一台大型主机出现了故障，那么整个系统将处于不可用状态，其后果相当严重。
最后，随着业务的不断增加，用户访问量迅速提高，计算机系统的规模也不断扩大，在单一大型主机上进行扩容十分困难。
1.1.2 分布式特点
在《分布式系统概念与设计》一书中，对分布式系统做了如下定义：
分布式系统是一个硬件或软件分布在不同网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
分布性
分布式系统中的多台计算机可以随意分布，同时，机器分布情况可以随时变动。
对等性
分布式系统中的计算机没有主/从之分，所有计算机节点都是对等的。
副本(Replica)是分布式系统最常见的概念，指的是分布式系统对数据和服务提供的一种冗余方式。为了对外提供高可用的服务，进行相应的副本处理。数据副本就是在不同节点上持久化一份数据，当一个节点上存储的数据丢失时，可以从副本上读取该数据，解决分布式系统中数据丢失的最为有效的方式。
并发性
在同一个分布式系统中的节点，很可能会并发地操作一些共享的资源，诸如数据库或分布式存储等，如何准确并高效地协调分布式并发操作成为分布式系统架构最大的挑战。
缺乏全局时钟
在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是分布式系统缺乏一个全局的时钟序列控制。
1.1.3 分布式环境中的各种问题
通信异常
从集中式向分布式演变的过程中，必然引出了网络的因素，因为网络本身的不可靠性，因此也引入了额外的问题。网络中各个节点之间的通信，每次网络通信都会伴随着网络不可用的风险，另外即使节点间能够正常通信，其延时也远大于单机操作。因此消息丢失和消息延迟变得非常普遍。
网络分区
因为当网络发生了异常，导致分布式系统中的部分节点之间的网络延时不断增大，最终导致在分布式系统的所有节点，只有部分节点能够进行正常通信，而另外一些节点不能——这种现象我们称为 网络分区 (脑裂)。
三态
因此，我们在分布式的环境下，网络可能会出现各种各样的问题。
在分布式系统中的每一次请求与响应，存在着特有"三态"。
即成功、失败与超时。
当网络异常的情况下，就可能会出现超时现象，通常以下两种情况：
- 由于网络原因，该请求(消息)并没有成功地发送到接收方，就发生了消息丢失现象。
- 该请求(消息)成功被接收方接收，并进行处理，但是将响应反馈给发送方的过程，发生了消息丢失的现象。
出现了这样的超时现象时，网络通信的发起方无法确定当前请求是否被成功处理。
节点故障
组成分布式系统的服务器节点出现了宕机或"僵死"现象。
1.2 从 ACID 到 CAP/BASE
除了从集中式到分布式架构的变迁过程中遇到的一系列问题，接下来，将重点看看分布式系统事务处理与数据一致性上遇到的问题。
1.2.1 ACID
事务(Transaction)是由一系列对系统中的数据进行访问与更新的操作所组成的一个程序执行单元，狭义上的事务特指数据库事务。一方面，当多个应用程序并发访问数据库，事务可以在这些应用程序之间提供一个隔离方法，以防彼此操作相互干扰，并且还提供了一个从失败中恢复到正常状态的方法，保证在异常的情况下，仍能保持数据一致性问题。
原子性
事务必须是一个原子操作，各项操作执行中，只能出现以下两种状态：
- 全部成功执行
- 全部不执行
一致性
当数据库只包含成功事务提交的结果，就能说数据库处于一致性状态。
如果数据库系统出现了故障，有些事务尚未完成就被迫中断，那些事务已经对数据库有一部分已写入，此时数据库就处于不正确的状态，即不一致的状态。
隔离性
是指在并发环境中，并发的事务是隔离的，即一个事务不能被其他事务所干扰，当不同事务并发操纵相同的数据时，每个事务都有各自完整的数据空间。
4个事务隔离级别，不同隔离级别对事务处理不同：
读未提交(Read Uncommitted)
该隔离级别允许脏读取，其隔离级别最低。在一个事务对数据已经做出了更新，另外一个事务仍能够访问到该数据。
读已提交(Read Committed)
它读未提交的唯一区别是，只能读取已经提交的数据，事务AB同时进行，B无法看到A在操作过程中对中间值，但出现了不可重复读取的问题。
可重复读(Repeatable Read)
简单来说，就是保证在事务处理过程中，多次读取到同一数据时，其值和事务开始时刻是一致的(其他事务提交不提交都读取不到)，但可能出现幻读数据，如果开始下一个事务读取该数据时，可能会改变。
串行化
串行化(Serializable)是最严格的事务隔离级别。它要求所有事务都被串行执行，即事务只能一个接一个地进行处理，不能并发执行。
事务隔离级别越高，越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。通常对于绝大多数的应用程序来说，可以优先考虑授权读取(读已提交)，这样避免脏读的同时保证了较好的并发性能，但会出现不可重复读，较为科学的方法是，由应用程序主动采用悲观锁或乐观锁来进行事务控制。
持久性
一个事务一旦提交，它对数据库对应的数据的状态变更是永久的。
1.2.2 分布式事务
对于单机数据库中，我们很容易能够实现一套满足ACID特性的事务处理系统，但在分布式数据库中，数据分散各台不同的机器上，就会遇到种种分布式事务问题。
一个最典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地的银行服务，一个本地银行提高取款服务，另外一个是目标银行提供存款服务，这两个服务本身是无状态的并且是相互独立的，共同构成了一个完整的分布式事务。
1.2.3 CAP 和 BASE 理论
随着分布式事务的出现，传统的单机事务已经无法胜任。对于一个高访问、高并发的分布式系统来说，很可能出现系统的可用性和严格一致性之间出现冲突。因此，如何构建一个可用性和一致性的分布式系统称为难题，出现了诸如CAP和BASE这样的分布式系统经典理论。
CAP 定理
CAP理论告诉我们，一个分布式系统不可能同时满足一致性(C:Consistency)，可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求，最多只能同时满足其中的两项。
一致性
在分布式环境中，一致性是指数据在多个副本之间能够保持一致的特性。如果能够做到针对一个数据项的更新操作执行成功后，所有用户都可以读取到其最新的值，那么系统就认为具有强一致性(严格一致性)。
可用性
是指系统提供的服务必须一直处在可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性
分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。
一个分布式系统无法同时满足这三个需求，而只能满足其中的两项。
因此在进行对CAP定理的应用时，我们就需要抛弃其中一项。
对于一个分布式系统而言，分区容错性可以说是最基本的要求。
BASE理论
Basically Available(基本可用)
Soft state(软状态)
Eventually consistent(最终一致性)
BASE是对CAP中一致性和可用性权衡的结果。
核心思想：即使无法做到强一致性(Strong consistency)，但每个应用结合自身业务特点，采用适当方式使系统达到最终一致性(Eventual consistency)。
Basically Available(基本可用)
指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但绝不等价系统不可用。以下是两个基本可用的典型例子。
- 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5s之内返回给用户查询结果，但由于出现故障，查询结果的响应时间增加到了1-2秒。
- 功能上的损失：正常情况下，在网站上购物，每个消费者都能顺利完成每一笔订单。但到了大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能被引导到一个降级页面。
Soft state(弱状态)
也称为软状态，与硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
Eventually consistent(最终一致性)
强调的是系统中的所有数据副本，在经过一段时间同步后，而不是实时，但最终能够达到一个一致的状态。
在实际工程实践中，最终一致性存在着以下5类主要变种。
因果一致性 (Causal consistency)
是指进程A在更新完某个数据项后通知进程B，那么进程B之后对该数据项的访问都应该获取进程A更新后的最新值。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。
读己之所写 (Read your writes)
是指进程A更新一个数据项之后，它自己总是能够访问到更新过最新值，而不会看到旧值，也就是对于单个数据获取者来说，其读取到的数据，一定不会比自己上次写入的要旧，因此这种是一种特殊的因果一致性。
会话一致性 (Session consistency)
将对系统数据的访问过程框定在了一个会话中，执行更新操作之后，客户端能够在同一会话中始终读取到该数据项的最新值。
单调读一致性 (Monotonic read consistency)
是指如果一个进程从系统中读取一个数据项的某一个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
单调写一致性 (Monotonic write consistency)
是指一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
事实上，最终一致性并不是只有在大型分布式系统才涉及的特性，许多关系型数据库也都采用了最终一致性模型，大多都会采用同步和异步的方式实现主备数据复制技术。在同步的方式中，数据的复制过程通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往会存在延时，这取决于事务日志在主备数据库之间的传输的实践的长短。当然无论采用多次尝试还是人为数据订正，关系型数据库还是能够保证最终数据一致性。
总结
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，它完全不同于ACID的强一致性模型，而是提出了通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致性状态。在具体的分布式系统架构设计中，ACID特性和BASE理论往往又会结合在一起使用。
标签：事务,CAP,读书笔记,Zookeeper,分布式系统,一致性,数据,分布式 来源： https://blog.csdn.net/qq_41010363/article/details/121500418
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。