数据库产品的金融级分布式事务技术路线问答
RP钉子2020-03-22 20:19:24

有网友提问” 银行核心业务系统最主要的技术特征就是数据一致性,采用关系型集中式数据库产品,故天然不用担心数据一致性、事务响应时间的额外开销、悲观锁、死锁发现和死锁解除。但对OLTP分布式数据库而言,核心业务系统对应的就是分布式事务一致性,在分布式数据库产品明确哪些产品可行、哪些厂商能成为行业最后赢家之前,如何设计和实现分布式事务一致性,各家银行采用了许多不同的策略,从而产生了多个不同技术路线和技术流派,例如分布式柔性事务、分布式强一致性事务等等。

下面的解答希望对大家有帮助:

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

https://download.csdn.net/download/weixin_44994688/12262492

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

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

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

3)、OLTP分布式数据库厂商会走向两极分化:

3.1)SequoiaDB 和 TiDB 追求多模数据库路线,也即业务场景上支持75%的 OLTP 业务场景 和75%的OLAP 业务场景(注:交易响应时间不满足高性能要求,分析计算能力不满足大规模数据量计算),数据库类型会完全融入 KV文档类型类MongoDB语法,及兼容MySQL 语法、PostgreSQL语法;

3.2) Oceanbase 、HotDB 、 TDSQL、GoldenDB、DDM、GaussDB T 100%专注OLTP分布式数据库 方向,SQL语法及生态完全融入MySQL体系或PostgreSQL体系,及兼容Oracle数据库语法。

OLTP分布式事务数据库的分布式事务指标评判总结:

衡量一款分布式事务数据库产品的分布式事务能力,要从:

(1) 业务代码是否同集中式数据库一样的编码处理逻辑 及数据库连接地址配置

(2)数据一致性是否等同集中式数据库的实时一致

(3)吞吐量能否水平扩展数十倍 集中式数据库产品(或等同Oracle/DB2 跑中高档小型机/AS400等的吞吐量)

(4)隐患核心系统业务每笔交易的响应时间是否可控在合理范围之内(注:假定网络时延足够小,则至少确保银行转账业务场景控制在 200毫秒以内/笔交易)

(5)分布式事务中的锁是否为悲观锁

(6)分布式事务中的死锁能否自动发现和自动解除

0
0
写文章
戳我,来吐槽~