众所周知,分布式数据库虽然在资源扩展与高并发性能方面有着独特的优势,但是不同行业核心业务系统对于事务性要求也是不同的,分布式数据库的事务管理器是如何满足核心业务不同的事务性需求的?
以金融行业来说,对分布式数据库分布式事务要求应该是非常高的,不同数据库实现分布式事务的机制有所不同,以我行采用的TDSQL数据库来说,分布式事务主要实现方式如下:
1)分布式事务是二阶段提交,组件proxy是事务协调者,启动事务时分别在每个分片节点上启动子事务,
在prepare commit时,proxy向gtid_log_t中记全局事务日志,全局事务日志保存在gtid_log_t(分片表),(通过交易的第一条SQL访问的SET记录全局事务日志);
2)prepare commit完成后,进入COMMIT阶段。
3)如果prepare commit 过程中发生异常时,各个set上的子事务回退。
4)进入COMMIT阶段,在COMMIT阶段的问题不会回退,会重复自动retry 提交,如果自动retry 提交超时,会在控制台出现一个事务提交报错,需要手工提交。
5)回退或retry提交都是依赖全局事务日志gtid_log_t。。全局事务日志保存在gtid_log_t分片表,依赖TDSQL一主多备确保零丢失。
6)主备之间的binlog传输是在prepare commit阶段完成。这样进入commit阶段,如果主节点故障,也不影响备节点retry提交事务。
7)全局一致性读,依靠TDSQL全局MC的组件,一个基于时间擢的全局序列,确保全局事务ID单调递增和唯一。
我们通常会通过破坏性测试来测试其分布式事务可靠性,例如一个表由ID和value组成,分布式事务是ID1+1,ID2+3,ID3+7,ID4-2,ID5-4,ID6-5,并发开启分布式事务,外部程序一定时间不断杀数据库DB进程,导致数据库故障主备切换,验证程序则不断地查分布式数据库整表sum(value),查到的数值不会变化。
收起