微服务下分布式事务问题

IMG_20160925_143422.jpg

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

交叉事务模型

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

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