金融级分布式事务技术路线？

对于金融级的分布式事务要求，其实算是比较明确的。首先是强一致性，这个是和互联网行业不一样的地方，也是分布式数据库的基本要求。

现在不建议金融行业继续掺和自研数据库的事情，因为市场上已经很多分布式数据库产品和案例了。所以现在银行有两种。一种是自己已经推出了分布式案例的，会在自己的选型基础上继续扩展。一种是尚未使用分布式的，会挑选国内的分布式数据库来部署。

那么现在主要谈谈这个第二种。分布式数据库该怎么选型？银行会在保证全局ACID的前提下，也就是强一致性前提下挑选分布式数据库产品。分布式事务的一致性现在已经不需要银行来设计保证了，数据库产品就已经涵盖这个能力。不过每个数据库在这点使用的技术确实不一样，有依赖生成全局事务号的，也有基于全局时钟的，可能还用很多其他全局的组件和服务。这些设计会影响事务的性能，因此需要详细测试才能比较出来。不过我个人认为这个是基础，挑选分布式数据库还有其他很多方面需要考虑。

OLTP分布式数据库或称  分布式事务数据库 必须要做到同 集中式数据库 等同的 事务一致性、吞吐量应该更大、响应时间可控。 一个不支持分布式事务强一致的数据库产品 不能称之为 分布式事务数据库产品，刚好看到一份银行核心系统转账业务场景性能测试的 普通一致 和 强一致 的 吞吐量、响应时间的对比，见文档：http://www.talkwithtrend.com/Document/detail/tid/433445

市场号称能做交易或专注做交易产品的分布式事务情况如下：

1） 专注OLTP分布式数据库产品：Oceanbase 、HotDB 做到了等同 集中式数据库 的 事务一致性 和透明性，TDSQL、GoldenDB、DDM、GaussDB T依然是采用外接GTS服务或zookeeper的模式，属于柔性事务 

2) 专注多模HTAP分部署数据库产品： SequoiaDB 准确说不支持 、TiDB 还未等同集中式数据库的 事务一致性 和透明性 ，另外响应时间 和吞吐量是大概是  蚂蚁金服Oceanbase 和热璞数据库HotDB的 25%。

3)、OLTP分布式数据库厂商会走向两极分化： SequoiaDB  和 TiDB 追求多模数据库路线，也即业务场景上支持75%的  OLTP和75%的OLAP （注：交易响应时间不满足高性能要求，分析计算能力不满足大规模数据量计算）  ，数据库类型会完全融入 KV文档类型类MongoDB语法，及兼容MySQL 语法、PostgreSQL语法； Oceanbase 、HotDB 、 TDSQL、GoldenDB、DDM、GaussDB T 100%专注OLTP分布式数据库 方向，语法及生态完全融入MySQL体系，兼容Oracle数据库语法。

总结：

衡量分布式事务数据库产品的分布式事务能力，从： 业务代码是否要修改或做特殊设置等、数据一致性是否等同集中式数据库、吞吐量能否水平扩展数十倍 集中式数据库产品（或等同Oracle/DB2 跑中高档小型机/AS400等的吞吐量）、响应时间可控（注：假定网络时延足够小时，银行转账业务场景能否控制 200毫秒以内）、事务中的锁为悲观锁、事务中的死锁自动发现和自动解除

传统关系型数据库和分布式数据库所提到的“一致性”，个人觉得并不完全等同。分布式数据库一致性包含数据一致性、事务一致性两个维度。
分布式数据库的一致性，分为强一致性、弱一致性、最终一致性。属于哪个一致性等级，与数据库多副本状态下的读写成功所需的最小化副本数有关。银行账户类系统选择强一致性最为保险，互联网公司可能会倾向于选择最终一致性。