从事务一致性到分布式架构 - 程序员必懂的架构演进

大家好！我是程序员 NEO 👋

让我们开始今天的技术分享~

传统架构事务

事务的主要作用就是控制数据的一致性，避免出现脏数据。在程序中，事务的控制主要分为编码式事务控制和声明式事务控制。

编码式事务控制模式的主要流程为：在业务方法中进行try-catch处理，业务方法执行没有异常则提交事务，出现异常则在catch中进行回滚：

public void test() {
    Connection connection = null;
    try {
        connection = getConnection();
        connection.setAutoCommit(false);
        // 你的业务方法
        connection.commit();
    } catch (Exception e) {
        connection.rollback();
    }finally {
        connection.close();
    }
}

如果采用编程式事务，那么在任何需要事务的地方都要开启事务、try-catch、提交或者回滚事务，会导致重复编码、编写与业务无关的代码。基于Spring Aop思想，我们可以利用Aop的方式，对需要使用事务的方法进行增强，将公用的部分提取出来，这种模式就是声明式事务控制。

在SpringBoot单体架构服务中，在需要事务控制的业务方法上，使用@Transactional注解就能实现声明式事务控制。

分布式架构事务

传统的单体架构下，我们可以很轻松地实现关系型数据库的事务控制，但在分布式架构下，一个请求调用链可能会经过多个服务，操作多个数据库。这种情况下，事务被分散到了各个子系统中，分布式架构事务（下面简称分布式事务）问题显得尤为重要，特别是在金融电商领域，如果分布式事务没控制好，损失的就是是真金白银。

数据库数据一致性的强度可以分为三种：

1. 强一致性：要求数据库中更新后的数据能立即对外可见；
2. 弱一致性：能够容忍数据库中部分更新后的数据，对外不可见；
3. 最终一致性：要求数据库中更新后的数据在一段时间后（这个时间区间的长度主要受网络通信延迟，系统负载等因素影响），对外可见。

在本地事务中，关系型数据库的ACID（原子性 - Atomicity、一致性 - Consistency、隔离性 - Isolation、持久性 - Durability）特性可以确保数据的强一致性，但要让分布式环境下的数据任何时刻都保持强一致性是不可能的，我们只能根据实际业务采用折衷的方案，确保数据最终一致性即可。

分布式事务控制可以参考一些著名的理论来支撑：CAP理论和BASE理论。

CAP理论指的是分布式系统的三个特性，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）：

分布式系统中，服务被分散到各个服务器上，服务之间的调用都是通过网络通信完成，所以网络通信问题是我们必须面对的问题。换句话说，分区容错性是一个分布式系统必然需要面对和解决的问题。因此我们只能在AP和CP上进行选择，实际业务中，我们更多的是在C（一致性）和A（可用性）之间寻求平衡。基于这个特点，业界中又衍生出了BASE理论。

BASE理论是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写，是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。基于BASE理论，又衍生出了不同于ACID的刚性事务的柔性事务概念。

基于这些理论，业界提出了相应的分布式事务解决方案，详见：

• 👉 分布式事务解决方案