分布式数据库事务管理器是如何满足核心业务系统需求的？

以金融行业来说，对分布式数据库分布式事务要求应该是非常高的，不同数据库实现分布式事务的机制有所不同，以我行采用的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)，查到的数值不会变化。

是个能抓住问题要点的人。建议按业务拆分

4）进入COMMIT阶段，在COMMIT阶段的问题不会回退，会重复自动retry 提交，如果自动retry 提交超时，会在控制台出现一个事务提交报错，需要手工提交。

手工提交是指的人工干预吗？在人工干预之前，这个数据还可以用吗？