什么是分布式数据库

写多读少、低延时、海量并发、海量存储、高可靠性、关系型数据库。
强调写多读少，是因为写少读多的情况下运用多个备份就好了，用不着搞分布式数据库

架构风格

PXGC风格

以PostgreSQL为内核代表的架构风格，立足于传统单体数据库，增加协调节点，全局时钟，分片信息节点

代表产品

TBase ,GuassDB 300,AntDB,GoldenDB

架构示意图

image.png

NewSQL风格

存储基础是类似BigTable的分布式键值系统，最早不具备事务处理能力，Google Spanner后增加新的事务能力

代表产品

Spanner,CockroachDB,TiDB , YugabyteDB,OceanBase

架构示意图

image.png

分布式数据库的两个2PC改进模型

Precolator模型

第一阶段

image.png

第二阶段

image.png

NewSQL阵营应用，需要支持MVCC。
多个分片数据中，选择一条数据作为主锁记录，所有分片数据处理完后，直接提交这条主锁记录。
查询的时候如果bal.lock有值，会根据指针查找记录是否已提交。
为减少查询消耗，事务提交后，bal.lock值会有异步线程进行清除。

数据不一致

第二阶段只需要和一个节点进行操作，是原子性的。不需要像传统2PC，第二阶段和所有节点通信。

单点故障

1 异步线程在事务管理器宕机后会进行回滚
2 事务管理器本身会通过共识算法保存记录日志，一个节点宕机后，其他节点也会通过日志进行恢复操作

GoldenDB 一阶段提交

虽然名字叫“一阶段提交”，但 GoldenDB 的流程依然可以分为两个阶段。
第一阶段，GoldenDB 的协调节点接到事务后，在全局事务管理器（GTM）的全局事务列表中将事务标记成活跃的状态。这个标记过程是 GoldenDB 的主要改进点，实质是通过全局事务列表来申请资源，规避可能存在的事务竞争。这样的好处是避免了与所有参与者的通讯，也减少了很多无效的资源锁定动作。
第二阶段，协调节点把一个全局事务分拆成若干子事务，分配给对应的 MySQL 去执行。如果所有操作成功，协调者节点会将全局事务列表中的事务标记为结束，整个事务处理完成。如果失败，子事务在单机上自动回滚，而后反馈给协调者节点，后者向所有数据节点下发回滚指令。