分布式OLTP

1.简介

$OLTP$指的是$Online Transaction Processing$，即更注重于小范围的数据读取或写入。

其事务特点为的周期较短、涉及数据较少。

$OLAP$指的是$Online Analytical Processing$，即更注重大范围的数据查询与分析。

其事务特点为周期较长、设计数据较多、只涉及只读的语句且常常涉及复杂的$JOIN$。

2.事务协调

一个重要的假设是参与事务的节点都是可信的，这会简化我们的协议。

如果假设可能存在不可信的节点如bitcoin，那么需要用$Byzantine Fault Tolerant$协议，这常用于区块链中。

3.原子提交协议

对于一个涉及多节点的事务完成时，协调者需要询问所有参与的节点该事务是否可以安全的落地。

常见的做法有多数同意，如$Raft$，$Paxos$，也有全部同意如$Two-Phase Commit$，$Three-Phase Commit$。常见协议有：

• $Two-Phase Commit$
• $Three-Phase Commit$
• $Paxos$
• $Raft$
• $Zookeeper$
• $Viewstamped Replication$

3.1.Two-Phase Commit

在$Two-Phase Commit$中，需要一个$Coordinator$作为协调器，对参与的节点$Participant$进行事务状态的追踪于管理。

协调器可以是中心的，也可以是临时的。同时，协调器也可以是参与者。取决于实现。

其工作流程如下：

• $Prepare$:协调器通过网络与参与者通信，附带了事务的内容。参与者收到事务内容后，会执行事务但不提交。若执行顺利，则回信$ok$。仅当协调器收到所有参与者该事务的$ok$信息后才会进行下一阶段。
• $Commit$:协调器告知所有参与者，所有参与者都同意执行该事务了。于是所有参与者对事务进行提交，并回信协调者事务。当协调者收到所有来自于节点的成功提交信息，则向外界返回$COMMIT$。

若在第一阶段中有参与者返回了失败或错误信息，则协调器会向所有节点发起事务回滚通知。

二阶段提交的问题如下：

• 同步阻塞：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。也就是说从投票阶段到提交阶段完成这段时间，资源是被锁住的。
• 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。 尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
• 数据不一致。在二阶段提交的第二阶段，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
• 极限情况下,对某一事务的不确定性：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

3.2.Paxos

Paxos中，每个周期会选出来一个Leader，由该Leader扮演协调者的工作。

在一个事务提交时，不需要所有参与者都同意才对事务进行提交，只需要大部分参与者同意即可，很大程度上减轻了阻塞问题。

4.Replication

Replication是将一个节点的状态复制到多个节点上，从而达到冗余容灾的作用。

一种实现方法是主从节点，即所有的写操作都只经过主节点，然后主节点通过网络将写操作传播给所有从节点，从而让主从节点状态达到一致。

另一种实现方式是多副本，事务允许写入任何一个副本中，但此时有差异的副本就需要通过某种协议同步他们之间的状态。可以参考FaceBook的做法。

传播又分两种级别。这指的是，对于一个具有复制能力的主从集群，当我提交事务时，什么时候告诉外界该事务已经被提交：

• $Synchronous(Strong Consistency)$：所有从节点都得到了看到了该事务的修改
• $Asynchronous(Eventual Consistency)$：一开始可能只有主节点看到了事务的修改，但最终所有事务都会看到该事务的修改

5.CAP定理

CAP定理（CAP theorem），又被称作 布鲁尔定理 （Brewer's theorem），它指出对于一个分布式计算系统 "分布式计算")来说，不可能同时满足以下三点

• 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
• 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
• 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。

理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。