分布式系统架构( 三 ) _分布式

2.添加数据库节点,其中一个从节点挂掉,由其他从节点提供服务
在实际系统中CAP是不能同时满足的，思考为啥不能同时满足CAP？
回答：假设有一个系统如下：

文章插图

有用户向Node1发送了请求更改了数据，将数据库从V0更新成了V1 。由于网络断开，所以Node2数据库依然是V0，如果这个时候有一个请求发给了Node2，但是Node2并没有办法可以直接给出最新的结果V1，这个时候该怎么办呢？
这个时候无法两种方法，一种是将错就错，将错误的V0数据返回给用户。第二种是阻塞等待，等待网络通信恢复，Node2中的数据更新之后再返回给用户。显然前者牺牲了一致性，后者牺牲了可用性。
这个例子虽然简单，但是说明的内容却很重要。在分布式系统当中，CAP三个特性我们是无法同时满足的，必然要舍弃一个。三者舍弃一个，显然排列组合一共有三种可能。
结论：在分布式系统中只能保证CP、AP，根据不同的系统选择不同的实现方案。
1.6BASE理论1.6.1概念BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
1.6.2各个理论详解1、Basically Available（基本可用）基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。比如：响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
2、Soft state（软状态）什么是软状态呢？相对于一致性，要求多个节点的数据副本都是一致的，这是一种 “硬状态” 。
软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。
3、Eventually consistent（最终一致性）最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
1.7一致性协议2PC在了解2PC之前了解下分布式事务概念，分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID），只是分布式事务相对于本地事务而言其表现形式有很大的不同。
1.7.1概念2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare
phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。（准备、提交协议）
在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议.

文章插图

两个阶段过程：
1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。
1.7.2执行流程场景一执行成功提交流程

文章插图

说明：ACK 确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。
阶段一
1. 事务询问：协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 执行事务 (写本地的Undo/Redo日志)
3. 各参与者向协调者反馈事务询问的响应