分布式事物学习

        分布式突破单机在计算和存储方面的瓶颈，在高并发和海量数据处理方面优势显著。但分布式提高了系统开发和维护的成本，通信异常、网络分区、三态(成功、失败、超时)、节点故障在分布式架构方面还具有挑战。

一、事物

•  ACID事物特性

        原子性：事物要么全部完成，要么全部不完成，中途发生错误，整个事物会回滚到起点

        一致性：事物执行前和后数据具有健康的一致性和完整性，事物中途失败，已变化的数据得到回滚，数据回到原点(数据也不一定还原，满足相关数据约定即可，又称内部一致性)

        隔离性：事物之间在操作同一份数据时，不同事物之间对数据具有隔离性(数据库事物隔离性策略)

        持久性：事物执行完后，所做改变永久保存下来

• 分布式事务 & CAP定理

        分布式事物可以看作由多个分布式操作序列组成，通常把这一系列操作序列称为子事物，保证各个子序列事物的分布式处理机制，即CAP定理。

        CAP定理指出对于一个分布式系统来说，不可能同时满足以下三点：

        C(一致性)：强一致性，就是所有节点上的数据时刻保持同步(多个副本的外部一致性、足相关数据约定)

        A(可用性)：任何非故障节点都应该在有限的时间内给出请求响应，无论请求是否成功

        P(分区容忍性)：发生网络分区(节点间无法通讯)时，在丢失任意多消失情况下，系统仍能正常工作，强调的是节点间的不连通问题

• 分布式一致性(在CAP中C的基础上的延伸)

        分布式系统数据一致性时具有容错性系统要考虑的基本问题，不同节点副本服务器对同一份数据达成某种共识，包含两层意思：

        Consistency：分布式系统之多个节点的数据返回始终一致的性质，强调对上层客服端调用时，暴露的数据一致性问题。

        Consensus：共识，强调多个提议者就某事达成共识，关注达成共识的过程，比如paxos/raft选举，属于服务端副本协议范畴。、

• 分布式一致性保障

        一致性模型：分布式存储系统通常维护多个副本进行数据容错，提高系统可用性，为了保证多副本的一致性，分布式系统对于读写操作的某种排序和执行规则，就定义了一种一致性模型。

        共识算法：简单说就是一个或多个节点提议了一个值后，通过分布式共识算法，使其它节点对这个值达成一致(业务事物)

二、一致性模型

        严格一致性(无法实现)：副本必须在物理时间钟下进行全局且持续同步，实际分布式不可实现

• 从两个角度看一致性：

        数据为中心一致性模型（服务端）：严格一致性，线性一致性，顺序一致性和因果一致性

        用户为中心一致性模型（用户访问）：最终一致性

• 强一致性：
  • 线性一致性：又叫原子一致性，使分布式多个副本看起来只有一个数据副本，且所有操作都是原子的。一个客服端成功提交写请求后，客服端并发请求一定能看到最近写入的值，否则都看不到(副本同步具有原子性)。
  • 顺序一致性(有强有弱)：因为全局时钟导致严格一致性很难实现，因此顺序一致性放弃了全局时钟的约束，改为分布式逻辑时钟实现。顺序一致性是指所有的进程都以相同的顺序看到所有的修改。读操作未必能够及时得到此前其他进程对同一数据的写更新，但是每个进程读到的该数据不同值的顺序却是一致的。

图中a满足顺序一致性，但是不满足强一致性。原因在于，从全局时钟的观点来看，P2进程对变量 X 的读操作在P1进程对变量 X 的写操作之后，然而读出来的却是旧的数据。但是这个图却是满足顺序一致性的，因为两个进程P1，P2的顺序一致性并没有冲突。从这两个进程的角度来看，顺序应该是这样的: Write(y，2)→ Read(x,O)→ Write(x,4)→ Read(y,2)，每个进程内部的读写顺序都是合理的，但是显然这个顺序与全局时钟下看到的顺序并不一样。

图中b满足强一致性，因为每个读操作都读到了该变量最新写的结果，同时两个进程看到的操作顺序与全局时钟的顺序一样，都是 Write(y,2)→ Read (x,4)→ Write(x,4)→ Read(y,2)。

图中c 不满足顺序一致性，当然也就不满足强一致性。因为从进程P1的角度来看，它对变量Y的读操作返回了结果0。也就是说，P1进程的对变量Y的读操作在P2进程对变量Y的写操作之前，这意味着它认为的顺序是这样的: Write(x,4)→ Read(y,O)→ Write(y,2)→ Read(x,O)，显然这个顺序是不能满足的，因为最后一个对变量x的读操作读出来的也是旧的数据。 因此这个顺序是有冲突的，不满足顺序一致性。

• 弱一致性
  • 因果一致性：顺序一致性的弱化，同步写顺序为：W(n1)->W(n3)，W(n2)->W(n3)，那么读也是R(n2)->R(n1)->R(n3)；简单说就是有因果关系的才讲究一致性，否则不用管。。
  • 最终一致性：分布式节点副本数据不保证任意时刻数据都相同，但随时间推移，数据趋于相同并最终相同，相同之前就会产生数据冲突（设置最少同步节点数量，达到了就视为写成功；读取数据时设置最少读取节点数量，多个节点比较后选择一份最终数据给用户，也视为读成功）

三、共识算法

• 2pc算法（事物）

        分布式中，业务数据数据中等待其它节点执行成功或失败并返回状态，根据返回结果判断是否提交事物。缺点是业务数据节点或参与者节点出现故障，事物会一致等待

• 3pc算法（事物）

        分布式中，业务数据数据中等待其它节点执行成功或失败并返回状态，如果等待超时或者参与者宕机，自动返回状态给提议者(数据节点)；数据节点宕机，参与者自动提交事物；故障后，业务事物自动处理，不影响整个系统业务

• paxos算法（一致性）

        分布式中出现节点宕机或网络异常等，保证数据强一致性，节点识别上述问题后，快速的提议协议值(值，带有版本号)，通知其它决策者达成共识，则该协议获得批准

• raft算法（一致性）

        从副本状态机的角度提出，管理副本状态机的日志复制，保证客服端不会读到过期数据，属于强一致性。

        领导者接受客服端请求，向追随者发出同步日志请求，日志同步到大多数节点后，告知追随者提交日志；追随者接受并持久化leader同步的日志，在leader告知日志可以提交后，提交日志；临时者，leader选举过程中的临时角色

• gossip协议（一致性）

        提出的用于分布式数据库的多节点间复制同步数据算法。gossip由根节点发起，当一个种子节点有状态需要更新到网络中其他节点时，它会随机选周围几个节点散播消息，收到该消息的节点也会重复该过程，直至所有节点都收到消息。不能保证任意时刻节点都能收到消息，理论最后会收到，属于最终一致性

借鉴于：分布式一致性 - 知乎 (zhihu.com)