分布式事务一直是数据库领域绕不开的话题。从两阶段提交到Paxos共识算法，从强一致到最终一致性，学术界和工业界讨论了几十年。但到了实际使用中，大家最关心的其实就一个问题：数据到底会不会错？特别是在金融、交易这类对数据一致性要求极高的场景下，哪怕出现一次不一致都是不可接受的。这篇文章通过对TeleDB分布式事务的实测验证，来看看它在一致性方面到底靠不靠谱。

测试方案设计

要验证分布式事务的一致性，光跑几个简单的INSERT和UPDATE是不够的，需要设计能够真正触发跨节点事务的测试场景。测试环境搭建了一个三节点的TeleDB集群，数据按分片规则分布在不同的节点上。

测试方案分为几个层次。第一层是正确性测试，验证在正常流程下跨节点事务能否保证ACID特性。第二层是异常测试，在事务执行过程中人为制造故障，比如杀掉某个节点、模拟网络分区，看事务是否能正确回滚或重试。第三层是并发测试，多个事务同时操作同一批数据，检查是否会出现脏读、不可重复读、幻读等问题。

测试工具方面，用了标准的数据库压测工具来模拟并发事务，同时写了一套自定义的校验脚本，在每次事务执行后自动检查数据的一致性约束。这套校验脚本虽然简单，但能覆盖大部分常见的一致性问题。

正常流程下的表现

先说正常流程。在跨节点事务中，TeleDB采用了两阶段提交的变体协议来保证原子性。简单理解就是：先在所有参与节点上预提交，全部预提交成功后再正式提交；如果任何一个节点预提交失败，整个事务回滚。

实测中，设计了一批涉及两到三个节点的跨节点事务，每个事务包含若干条跨节点的INSERT和UPDATE操作。在正常网络、节点全部存活的情况下，所有事务都能正确提交或回滚，数据一致性校验全部通过。这部分的结果符合预期，毕竟在一切正常的情况下，保证一致性不算特别难。

值得一提的是事务的响应时间。跨节点事务由于多了协调阶段的网络通信，延迟自然比单节点事务要高一些。在测试环境中，两节点事务的平均响应时间比单节点事务高出约30%到40%，三节点事务再高一些。这个延迟开销在可接受范围内，但说明在设计系统时要尽量减少不必要的跨节点事务。

异常场景下的表现

真正考验一致性的是异常场景。这里重点测了两种情况。

第一种是节点故障。在一个跨节点事务执行到预提交阶段时，强制关闭其中一个参与节点。按照两阶段提交的逻辑，协调者检测到节点不可用后应该中止事务。实测结果符合预期，事务被正确回滚，没有出现部分提交的情况。节点恢复后，数据状态与事务回滚后的预期一致。

第二种是网络分区。通过防火墙规则在事务执行过程中切断节点之间的网络连接。这种情况下TeleDB的表现取决于超时配置和重试策略。测试中发现，在网络恢复后，未完成的事务会根据协调者的状态决定提交还是回滚。在超时时间内恢复的，事务可以继续完成；超时后恢复的，事务被回滚。这个行为是合理的，但要注意合理设置超时参数，太短会导致不必要的回滚，太长会阻塞其他事务。

并发场景下的表现

并发测试是重头戏。在多个事务同时操作同一批数据时，隔离级别直接决定了能不能看到一致的数据视图。TeleDB默认的隔离级别是读已提交，也支持可重复读和串行化。

在读已提交级别下，测试了经典的转账场景：两个事务同时读取同一账户余额，各自计算后更新。结果是出现了经典的丢失更新问题，这在读已提交级别下是预期行为。将隔离级别提升到可序列化后，问题消失，但吞吐量有明显下降。

综合来看，TeleDB的分布式事务在一致性问题上的表现是可靠的。正常流程下数据不会出错，异常场景下能正确回滚，并发场景下通过合理设置隔离级别可以避免一致性问题。当然，强一致性是有代价的，跨节点事务的延迟和吞吐量都会受到影响，在架构设计时需要根据业务需求找到平衡点。