一款Kafka可视化Web界面管理工具

虽然 NewSQL 分布式数据库产品都宣传完备支持分布式事务，但这并不是说应用可以完全不用关心数据拆分，这些数据库的最佳实践中仍然会写到，应用的大部分场景尽可能避免分布式事务。

既然强一致事务付出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务?

尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中。

尝试将一致性要求弱化，便是柔性事务，放弃 ACID(Atomicity，Consistency，Isolation，Durability)，转投BASE(Basically Available，Soft state，Eventually consistent)。

例如 Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发 OLTP 场景，我个人更建议使用柔性事务而非强一致的分布式事务。

关于柔性事务，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与框架(例如阿里刚开源的 Fescar)，限于篇幅不再赘述，有空再单独写篇文章。

解决分布式事务是否只能用两阶段提交协议?OceanBase1.0 中通过 updateserver 避免分布式事务的思路很有启发性 ，不过 2.0 版后也变成了 2PC。

业界分布式事务也并非只有两阶段提交这一解，也有其他方案 its-time-to-move-on-from-two-phase：

 

其中提到：分布式系统中，您可以知道工作在哪里，或者您可以知道工作何时完成，但您无法同时了解两者;两阶段协议本质上是反可用性协议。

完备性

两阶段提交协议是否严格支持 ACID，各种异常场景是不是都可以覆盖?

2PC 在 Commit 阶段发送异常，其实跟最大努力一阶段提交类似也会有部分可见问题，严格讲一段时间内并不能保证 A 原子性和 C 一致性(待故障恢复后 Recovery 机制可以保证最终的 A 和 C)。

完备的分布式事务支持并不是一件简单的事情，需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常，通过严格的测试。

之前跟某友商交流，他们甚至说目前已知的 NewSQL 在分布式事务支持上都是不完整的，他们都有案例跑不过，圈内人士这么笃定，也说明了分布式事务的支持完整程度其实是层次不齐的。

但分布式事务又是这些 NewSQL 数据库的一个非常重要的底层机制，跨资源的 DML、DDL 等都依赖其实现，如果这块的性能、完备性打折扣，上层跨分片 SQL 执行的正确性会受到很大影响。

性能

传统关系数据库也支持分布式事务 XA，但为何很少有高并发场景下用呢?

因为 XA 的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的 OLTP 系统中。

NewSQL 数据库的分布式事务实现也仍然多基于两阶段提交协议，例如 google percolator 分布式事务模型，采用原子钟+MVCC+Snapshot Isolation(SI)。

这种方式通过 TSO(Timestamp Oracle)保证了全局一致性，通过 MVCC 避免了锁，另外通过 primary lock 和 secondary lock 将提交的一部分转为异步，相比 XA 确实提高了分布式事务的性能。

SI 是乐观锁，在热点数据场景，可能会大量的提交失败。另外 SI 的隔离级别与 RR 并无完全相同，它不会有幻想读，但会有写倾斜。

但不管如何优化，相比于 1PC，2PC 多出来的 GID 获取、网络开销、prepare 日志持久化还是会带来很大的性能损失，尤其是跨节点的数量比较多时会更加显著。

例如在银行场景做个批量扣款，一个文件可能上 W 个账户，这样的场景无论怎么做还是吞吐都不会很高。

Spanner 给出的分布式事务测试数据：

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!