分布式事务理论脉络

Posted 2021-04-25 木一行

当单机的应用无法应付业务增长，需要更多机器支撑，分布式系统应运而生。

分布式系统旨在解决两个问题：

1. 增大系统容量。多台机器应对大规模的应用场景让系统变成一个分布式架构

2. 加强系统可用。关键业务需要提高整个系统架构的可用性，架构中不能存在单点故障。这样整个系统不会因为一台机器故障而导致整体不可用，需要通过分布式架构来冗余系统以消除单点故障

而在分布式服务架构中，存在著名的CAP理论：

一致性(Consistency),可用性(Availability),分区一致性(Partition Tolerance)

在现实中不能都满足，最多只能满足其中两个。

数据一致性模型

数据一致性来说，简单说有三种类型：

1. Weak 弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系

2. Eventually 最终一致性：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。

3. Strong 强一致性：所有的副本同时读到最新的数据

ACID和BASE原理

ACID定理：单实例数据库遵循的事务原理，对应强一致性模型。

BASE定理：允许或是容忍系统出现暂时性的问题的,对应最终一致性模型。是为了提高性能，出现的ACID的一个变种。

ACID 的意思是酸，而 BASE 却是碱的意思，因此这是一个对立的东西。

其实，从本质上来讲，酸（ACID）强调的是一致性（CAP 中的 C），而碱（BASE）强调的是可用性（CAP 中的 A)。

强一致性的解决方案

在分布式系统中，ACID有更强的一致性，但可伸缩性比较差，仅在必要时使用。

解决方案有三种：

1. 两阶段提交

2. 三阶段提交

3. Paxos算法

4. Raft算法( Paxos算法的演化) 

5. NWR模型

最终一致性的解决方案

BASE的一致性较弱，但有很好的可伸缩性，还可以异步批量处理，大多数分布式事务适合BASE。要实现BASE事务，需要实现业务补偿逻辑。

应用层的分布式事务实践

很多公司的分布式系统事务基本上都是两阶段提交的变种，比如

• 阿里的TCC-Try-Confirm-Cancel

• 亚马逊的Plan-Reserve-Confirm方式

数据层的分布式事务实践

•  AWS的Aurora。改了mysql的InnoDB引擎，为了承诺高可用的SLA，需要6个副本。不像国内MySQL通过bin log的数据复制，而是更为惊艳的复制SQL语句，然后使用各种tricky的方式降低latency,比如多线程并行，使用SQL操作的merge等

• MySQL官方的MySQL Cluster

• 国内的PingCAP的TiDB

• 国外的CockroachDB

• 阿里的OcenBase

这些都是为了解决大规模数据的写入和读取问题出现的数据库软件。