ShardingSphere分布式事务

1. 本地事务

大多数场景下，我们的应用都只需要操作单一的数据库，这种情况下的事务称之为本地事务 (Local Transaction)。本地事务的ACID特性是数据库直接提供支持。本地事务应用架构如下所示：

在JDBC编程中，我们通过java.sql.Connection对象来开启、关闭或者提交事务。代码如下所示：

1 Connection conn = ... //获取数据库连接 
2 conn.setAutoCommit(false); //开启事务 
3 try{ 
4 //...执行增删改查sql 
5 conn.commit(); //提交事务 
6 }catch (Exception e) { 
7 conn.rollback();//事务回滚 
8 }finally{ 
9 conn.close();//关闭链接 
10 }

2.分布式事务

分布式事务产生原因：

在微服务架构中，完成某一个业务功能可能需要横跨多个服务，操作多个数据库。这就涉及到到了分布式事务，需要操作的资源位于多个资源服务器上，而应用需要保证对于多个资源服务器的数据操作，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。

使用本地事物能不能解决上述问题呢？

如果要解决上述问题，就需要做到在一个请求中先连接数据库A再切换连接为数据库B，

对于转账交易来说，A中的钱划扣了，那么就需要切换数据库连接为B，将B中的数据库的钱也划扣掉。如果B出现失败，两个数据库开始回滚。

典型分布式事务产生场景:

1) 跨库事务

跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。下图演示了一个服务同时操作2个库的情况：

2) 分库分表

通常一个库数据量比较大或者预期未来的数据量比较大，都会进行分库分表。如下图，将数据库B拆分成了2个库：

对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。如，对于sql：insert into user(id,name) values (1,"张三"),(2,"李四")。这条sql是操作单库的语法，单库情况下，可以保证事务的一致性。 但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。

3) 微服务架构<