微服务下分布式事务问题

IMG_20160925_143422.jpg

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

交叉事务模型

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

List 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的事务，多次测试结果均显示无不一致数据，效果很好，后期的实际业务测试下也显示出其一致性和性能都不错。

文／铁汤

关键字：产品经理, 事务

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！