本文转载自微信公众号《程序员jinjunzhu》，作者jinjunzhu。转载本文请联系程序员jinjunzhu公众号。蚂蚁集团自研数据库OceanBase已经开源，这对于国内分布式数据库来说是一个天大的喜讯。OceanBase作为商业数据库，并没有透露太多技术细节。以后还会有另一个优秀的分布式数据库可以用来研究。参考文献1[1]根据官网描述，在国际事务处理性能委员会（TPC，TransactionProcessingPerformanceCouncil）官网于5月20日发布的最新数据分析基准测试（TPC-H）榜单中，OceanBase以1526万QphH和30000GB的总性能得分排名第一。这意味着OceanBase成为唯一在事务处理和数据分析测试中均获得第一名的中国自主研发数据库。1架构主流的分布式数据库有PGXC和NewSql两种架构。1.1PGXCPGXC指的是PostgreSQL-XC，是指以PostgreSQL为核心的分布式数据库。整体架构如下：PGXC架构是传统单体数据库的集群，在集群的基础上增加了一个协调节点。协调节点具有以下功能：客户端访问流程管理分布式事务管理查询处理还增加了分片管理和全局时钟。分片管理用于管理集群的分片信息。全局时钟的介绍见下一节。虽然PGXC名字的由来是PostgreSQL组成的分布式数据库，但是其他单体数据库组成的分布式数据库也可以理解为PGXC。比如Golden就是以mysql为核心。1.2与以传统单一数据库为核心的PGXC相比，NewSQL在基于NoSQL的分布式键值存储系统的基础上构建了分布式事务处理能力。架构如下图所示：此外，NewSQL还有两点改进：针对HA，摒弃了传统数据库的主从复制，采用Paxos、Raft等共识算法保证多副本的一致性。存储方面，采用LSM树模型替代B+树，写入性能更高。2全局时钟2.1线程一致性线性化（Linearizability）是分布式系统中最强的一致性模型。总体思路是确保阅读多个不同副本的客户端与阅读同一副本具有相同的结果，也就是说，整个系统看起来只有一份。让我们看两个不满足线性化的例子。2.1.1同一个client如下图：client1第一次读取x的值为0，第二次读取时认为client3修改了x的值，所以读取新的值1，但是第三次??读取的时候，因为读取了另一个副本，因为这个副本还没有同步，读取到的是旧值0。2.1.2不同的client如下图：client1第一次读取x的值为0，第二次读取时，由于client3修改了x的值，读取到的是新的1值，但是client1第二次读取后，client2读取了x的值，因为它又读取了一份，因为这份副本还没有同步完成，所以读取的是旧值0。线性一致性要求任何一个客户端读取并返回一个新值后，所有后续客户端（包括同一个客户端和不同客户端）读取后也必须返回一个新值。下图是线性一致性：2.2Globalclockslave从上面的描述可以看出，线性一致性是基于事件的先后顺序的。所有的操作都必须记录在时间线上，任何两个事件都有一个顺序。但是集群中的每个节点都有自己的时间轴，如何实现时间顺序。这时候就需要一个全局的绝对时间，也就是这里说的全局时钟。一般来说，全局时钟可以通过从时间服务器获取时间来实现，但是必须保证高可用性。下面介绍几种全局时钟的实现：2.2.1TrueTimeGoogleSpanner使用GPS加原子钟来分配时间，支持多点授时机制。有两个明显的优点：多点授时分散，可靠性高。支持全局部署，可以减少客户端与时间服务器的通信时间。但也存在一些问题：使用物理时钟时会出现时钟偏移和时钟回调。多点授时可能会出现系统整体授时误差。从引入Spanner开始，时间误差在7毫秒以内。2.2.2HybridLogicalClock（HLC）HLC（HybridLogicalClock），由于Truetime依赖硬件设备实现，实现难度大，所以部分数据库采用混合逻辑时钟，即物理时钟和逻辑时钟一起使用.多个时间源、多个时间点服务，系统整体也会出现时间误差。2.2.3时间戳Oracle，简称TSO，是一种集中式的计时方案，使用单一时间源和单一计时点实现全局时钟，并使用全球唯一的时间戳作为xid（globaltransactionid）。优点：实现简单单调递增单时间源可以减少事务冲突缺点也很明显单点计时，性能瓶颈不适合大规模集群部署目前TiDB和OceanBase都采用这种方案。2.2.4总结Spanner需要借助物理设备实现，对其他开源数据库参考价值不大。其他人，无论是使用HLC还是TSO，都有自己的优点和缺点。两者之间还有一种授时方案，单一时间源，多点授时，使用较少。3HTAPHTAP的英文全称是HybridTransactionandAnalyticalProcessing，即混合事务和分析处理，可以在同一个数据库系统中完成事务处理（OLTP）和数据分析（OLAP）请求。HTAP需要在计算和存储两个层面支持OLTP和OLAP，而存储是基础。OLTP通常使用行存储，而OLAP一般使用列存储，两者有很大区别。HTAP解决这个差异有两种方式：GoogleSpanner的PAX，一种新的聚合存储，在行存储的基础上融合了列存储的特点。TiDB的思想是使用Raft协议在OLTP和OLAP之间异步复制数据，通过OLAP的特殊设计来弥补异步带来的数据不一致。OceanBase采用了独创的分布式计算引擎，可以让系统中的多个计算节点同时运行OLTP类应用和OLAP类应用，实现了一套计算引擎同时支持混合负载的能力。4RANGE动态分区下图中有4条数据。如果按照HASH分片，一般选择id作为key进行HASH计算，然后根据计算结果将数据分配到不同的分片。这样做的好处是实现起来简单，但是有两个问题：1.Sharding没有业务属性，访问业务热点可能会有问题。当分片大小发生变化时，迁移数据就会出现问题。与HASH相比，Range分片技术非常不同的地方在于数据没有被打散。比如上表，我们可以按照城市对数据进行切分，这样数据读取效率会更高。Range动态分区用于NewSQL架构的分布式数据库，一般具有以下特点：4.1自动合并和拆分可以为分配的数据量设置一个阈值，当一个分片中的数据量超过最大阈值时，它可以自动拆分为2个分片，当分片数据量小于最小阈值时，合并分片。4.2自动加载当一个分片上有大量热点数据时，节点访问压力会很大。系统可以自动调度这些热点数据访问到不同的节点，以平衡访问压力。4.3减少分布式事务分布式事务的开销远大于本地事务。分布式数据库可以将频繁参与同一个分布式事务的数据调度到同一个分片上，从而避免了分布式事务。Spanner支持4.4最近访问。在全局部署场景下，用户被分配到最近节点的分片，可以减少访问延迟。Spanner支持4.5高可靠分布式数据库的高可靠是分区级别的高可靠。下图是OceanBase中一个Zone的架构图：OceanBase基于Paxos算法实现系统的高可用，在分区级别可以做到最小粒度。集群中数据的每个分区都会保存到所有的Zone中，分区的多个副本使用Paxos协议进行日志同步。每个分区及其副本组成一个独立的Paxos复制组，其中一个是leader，其他分区是follower。此副本的所有写请求将自动路由到相应的主分区。主分区可以分布在不同的OBServer上，这样对于不同副本的写操作也会分布到不同的数据节点上，实现多点数据写入，提高系统性能。5percalator模型分布式数据库是在BigTable的基础上增加了分布式事务的解决方案。Percolator模型是Google提出的建立在BigTable之上的分布式事务解决方案。参考文献2[2]percalator模型采用了2-stagesubmission的思想。这里以银行汇款为例。账户1向账户2汇款100元，这两个账户位于不同的分区。5.1初始状态初始阶段，如果一开始账户1有300元，账户2有500元，如下图：上表中，“：”代表的数据版本前面时间戳，后跟数据值。第一列是表名，第二列低版本保存数据，第三列保存加在数据上的锁。第四列高版本存放的是指向所存数据版本的指针，例如版本6存放的是指向版本5的指针，6：data@5。5.2Prewrite事务管理器向两个分片发送Prepare请求。分片收到请求后，会为每一个要修改的数据行写入日志，根据时间戳记录交易的私有版本。这里的私有版本是7，这样就拿到了锁，其他事务就不能操作这两条数据了。如下图所示：从第二列的数据可以看出，账户1减少了200元，账户2增加了600元。从第三列可以看出，账户1获得了主锁，账户2有一个锁指针指向主锁。注意：主锁的选择是随机的，账户1和账户2都可以选择。5.3提交在提交阶段，协调节点只需要与拥有主锁的分片进行通信。这里只需要和账号1通信，保证commit命令的原子性。此时数据如下：可以看到账号1的主锁已经被清除，并且添加了版本8，版本8的数据指向了版本7。这样一来，版本7和8不是私有版本，其他交易可以操作这条记录。私有版本还有一个功能，就是账号1提交失败后，账号2可以按照私有版本回滚。5.4事务提交成功后，账户2上的私有版本和锁指针并没有被同步清除，而是启动了一个异步线程进行清除。异步线程清空后，最终数据如下图所示：可以看到，最终账户2清空了锁指针和私有版本。账户2的锁没有同步清除。其他线程读取account2时，会根据primary@order.bal查找主锁。如果他们发现主锁已经被清除，他们可以继续读。阅读时做一些二次锁清理。6小结本文主要从五个方面讲述分布式数据库的重点知识，欢迎批评指正。参考文献[1]参考文献1：https://open.oceanbase.com/[2]参考文献2：https://www.cs.princeton.edu/courses/archive/fall10/cos597B/papers/percolator-osdi10。PDF格式
