微服务下分布式事务问题

IMG_20160925_143422.jpg

数据一致性来描述更贴切一些,在微服务化后,分布式事务上有很多选择,像多阶段提交、补偿模式、可靠事件、TCC等等,多阶段提交强一致性好但很难提升吞吐,为了吞吐基本上都是选择了最终一致性的分布式事务模型。补偿模式、可靠事件、TCC都属于最终一致性的范畴,都被广泛采用。无论采用哪种模式,都应该在特定业务场景下选择合适的分布式事务模型,并且具体场景具体分析了。这些模型也有很多分享参考,不再废话,下面着重介绍另一种分布式事务模型。

交叉事务模型

最初是2个数据源,我把它叫做双事务,扩展后支持多个数据源叫做交叉事务,这种事务适用于有2个或多个DataSource的场景下来保证数据的事务完整性,吞吐和一致性效果都很不错,这种事务模型利用了JDBC事务,基本思路是先执行DML SQL,出现异常或者需要回滚时依次回滚已经执行事务,最后再执行提交, 并且实现难度也不大,下面是伪代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
List<Connection> connections = new ArrayList<>();
int i = 0;
try {
for (Connection connection : connections) {
boolean isExecuted= execute(connection);
i++;
if(!isExecuted){
throw new SQLException();
}
}
} catch (SQLException e) {
for (int j = 0; j <= i; j++) {
connections.get(j).rollback();
}
} finally {
for (Connection connection : connections) {
connection.commit();
}
}

交叉事务要配合实际的JDBC事务和一些锁机制才能很好的工作,交叉事务很好的解决了多数据源的问题,但不是任何场景都适用,我总结了适用场景供大家参考:

  1. 每个数据源事务处理要求很快,通常是零点几~十几毫秒,不适合长事务慢事务
  2. 通过建立多个数据源来工作,不是网络接口。
  3. 每个数据源事务中要配合锁机制保证数据一致性,where id=? for update行锁或者乐观锁都可以,但必须保证整个个事务过程中不允许被其他事务修改。

这个事务模型在这样一个测试模型下的测试结果:

在多线程下随机对10组数据做随机更新,并记录下测试的最终状态,最后读取数据库最后实际数据比较。在这样的测试模型,每秒大约3000的事务,多次测试结果均显示无不一致数据,效果很好,后期的实际业务测试下也显示出其一致性和性能都不错。