PD Server实现了逻辑上的时间戳，谷歌论文也提出了原子钟的概念，从物理上保证事务号全局有序。
2.OceanBase
OceanBase是蚂蚁金服自研的分布式数据库，号称代码从第一行完全自研。最近ob也屡屡刷新新闻头条，刷榜TPCC官网测试结果，刷新天猫交易额和tps记录，不过金融行业比如银行的应用案例并不多，也许是银行和支付宝可能天然有鸿沟吧。ob架构比较特殊，下面介绍一下它的架构特点：
①最底层是ob server，每个ob server集成了总控服务、sql引擎、存储引擎和数据分区。
②上层是ob proxy，实现sql的路由，这个不止是应用到observer的路由，也有observer之间的路由。
③数据拆成一个个分区，每个分区做paxos复制，保证强一致，主分区宕机不可用会自动切换到备分区。
④checkpoint时间改变，将checkpoint周期拉长为1天，所有交易都落在内存，然后每天夜里去刷一次盘，redo日志实时记录，这样避免了随机写的性能损耗，只有顺序写，更像内存数据库，性能更好，这样也带来一些问题，比如宕机后恢复时间变长，还有查询刚刚做的修改需要先查基础数据，再去应用redo条目，得到最新数据。
⑤两阶段提交并不使用ob proxy节点充当协调者，而是将ob proxy路由到的第一个主数据分区作为协调者，同时两阶段提交的prepare和commit等信息会进行持久化，如果写协调节点宕机，那么备分区会启用，同时读取持久化信息，这个设计和一般的分布式数据库不太一样。
⑥集群维护一个partition cache，分区的分布信息会通过ob proxy在不同ob server间传递。
⑦ob最早的时候曾经开源过一段时间，随后基于它也诞生了cbase、obase这些产品。
3.GaussDB
华为GaussDB分为三个产品线，Gauss100前身是华为自研的内存数据库gmdb，目前已经开源，Gauss200是基于pgxc架构研发的OLAP分析型数据库，Gauss300是在200的基础上继续研发的HTAP数据库，这里主要介绍Gauss300数据库，Gauss300就是上图中典型的架构：
①协调节点负责sql解析、转发的同时也充当了两阶段提交的协调者的角色，协调节点上面存储有部分元数据信息，元数据需要在多个协调节点之间进行同步，如果协调节点宕机，会影响ddl相关操作，还可能造成两阶段提交的残留信息，需要有两阶段残留清理机制。
②数据节点通过quorum-based流复制实现高可用，主备数据节点是实例级别的，一个主节点就是一个主PG实例，一台机器可以有多个主数据节点。
③GTM复制分配全局事务id，GTM一主多备，GTM主备之间要同步gxid信息，而且是强同步，那么带来一个问题，备GTM节点宕机会造成主GTM不可用，造成全局可用性问题，这块华为将GTM的高可用转移到etcd中，将GTM生成的xid写入到etcd中，etcd自身就是一个高可用强一致的集群，这样就保证了GTM的高可用，主GTM宕机那么备GTM会接替，然后继续从etcd集群中读写事务号。
④GTM的事务号是批量分配的，如果在高并发的情况下，gxid如果一条一条分配则会有性能瓶颈，华为将事务号改为一次分配几万甚至几十万，避免了GTM事务号分配的瓶颈。
⑤事务id由32位改为64位。PG的事务号是32位的，最大到42亿，所以事务号在PG中是很珍贵的资源，用完了就会循环使用，循环使用会带来很多严重问题，华为将事务号由32位改为了64位，这样事务号根本不可能用尽，那么一次分配几十万也不足为奇了。
⑥为了提升性能，华为也正在研发gtm-lite功能，该功能可以实现本地事务不走GTM，因为生产环境大部分是本地事务，因而能大大提升性能。
⑦Gauss300是基于pgxc架构演进而来的，类似基于pgxc的还有亚信AntDB、腾讯TBase。
4.SequoiaDB
SequoiaDB是巨杉自主研发的分布式数据库，最初的应用场景主要是历史数据归档和非结构化数据存档，但是近期来巨杉也在积极开发oltp功能，包括研发GTM，