《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL开源路线图（3） https://developer.aliyun.com/article/1232545?spm=a2c6h.13148508.setting.16.5e4f4f0ecmbIFO
（三）HLC高扩展分布式版
下一个阶段，我们开源的项目将会是一个Shared Nothing的分布式产品，但仍然是基于第一期的高可用能力。这一期的核心是对PG内核的分布式扩展，使得扩展后的系统能够最大限度地兼容单机SQL的能力，包括DML、DDL等，同时保持对外呈现单个数据库的ACID和MVCC的能力。
二者的目的就是保证分布式扩展后的这个系统，对用户大部分应用仍然像单机PG那样兼容，减少用户迁移和开发的工作量。
上图所示的架构中可以看到，分布式Shared Nothing系统中出现更多的组件，其中data node部分就是一期的高可用集群，只是有多个这样的集群，或称为基于X-Consensus复制组，每个 data node 复制组中有Leader、Follower和Logger。通过X-Consensus 共识协议保持数据一致性，每一个复制组负责整个数据库的部分数据，称为数据库分片。因为 data node上实际上运行的独立的PG内核又称为数据库分片，这些数据库分片其实就是多个数据库实例，通过一个新的引入组件叫协调节点（Coordinator nodes），实现对外呈现单个数据库的能力。
也就是对用户来说，看到的是一个数据库，一个字典表和一套用户表，但是在物理上每个数据库分片都存了用户表，只是一部分数据。用户查询先路由到协调节点，协调节点通过字典表和集群拓扑信息，判断查询需要涉及的数据库分片，并发送查询到相应节点，获得各个节点的返回结果后，协调节点还将负责将结果组合返回给用户。
除了查询和表逻辑对外呈现单个数据库特性外，分布数据库的ACID和数据一致性也需要维护。为此我们引入另外两个组件，一个是分布式事务管理TX Manager，保证一个事务在多个数据库实例上执行的时候满足ACID。另外一个是混合逻辑时钟，叫HOC，其目的是保证所有事务有一个全局的排序，从而实现分布式Shard的MVCC，也就是实现分布式Shard的SnapShot。
相对于中心使用来说，采用混合逻辑时钟的好处是混合时钟是分布式的，没有中心，在大规模集群情况下不会引入热点和瓶颈，同时可以避免新的组件，增加管理或者高可用的代价。
通过HLC对事务和操作进行时间意义上的全局排序，不仅仅需要实现HLC的协议，同时需要数据库内核的
支持。这个支持我们在一期已经完成了，是对 PG SnapShot 管理的增强，作为替换原来的活跃事务列表，为提交序列数或者叫CSN，作为SnapShot，这样分布式的HOC和单机PG的CSN机制整合，实现了事务的全局排序，从而为实现分布式MVCC提供这个基础。当所有的事务都按照时间排序时，那原有的MVCC机制就可以正常地运行，保证数据多版本支持，读写操作的并行执行。
在分布式 Shared Nothing 下，除了事务一致性外，如何分布式地处理SQL计算也是一个非常重要的特性。就像刚才提到的，我们首要的目标是最大限度地兼容单机的SQL能力，和事务一致性一起保证用户应用可以快速在功能上适配分布式数据库系统，比如对DDL的支持，对简单DML的支持，对带子查询的复杂DML的支持等等。
其次，需要在查询性能上进行优化，这中间的工作将非常地丰富，比如发送查询到数据库分片节点的操作，需要考虑是否整个或部分查询可以直接下推给某个或某些节点。查询计划在分布式下如何优化，如何结合分布式和单机的优化器的能力，如何在data node间交互，如何结合MPP和SMP等，都是我们将来所需要考虑的一些方向跟技术特性。
根据项目一期的基础，data node已经具备高可用能力，但是集群管理和分布式数据库的MetaData的管理都需要类似的高可用能力。我们需要一个基于X-Consensus的共识协议的分布式方案，解决用户数据库协调逻辑，集群管理和Meta管理的统一的高可用问题，所以我们将会在这个版本里实现分布式的高可用。
总体上，二期将推出一个具备完整SQL和数据一致能力的分布式Shared Nohting数据库，其主要特性都是对现有单机PG的补充、增强和扩展，这些能力的大部分将在第三期成为插件，满足用户快速升级的需求。
(四) Sharding 和 插件化版
第三期我们将在前面两期基础上持续地增强分布式能力、云化能力以及PG社区兼容能力，上方的架构图反映了我们在第三期的主要思路。
首先DB Node作为核心组件，提供单机数据库内核能力和分布式计算能力，同时管理每个Shard和跨Shard的事务，保持数据一致性，DB Node自己通过X-Consensus共识协议复制数据到Follower，维护节点级别的数据和逻辑冗余，有助于故障Shard快速恢复。每个DB Node的功能将通过对PG社区内核支持，加上分布式和高可用的插件的Patch实现这些功能。
在DB node上，我们维护一个PolarDB服务层，提供像集群管理、各种运维操作、负载路由以及中心时钟，是一个Option的需求。相对独立的服务层将有助于用户应用的对接，不受内核升级变化的影响，服务层可以随环境变化，针对不同云提供商和专有云来提供支持。
第三期主要的增强体现在以下几个方面。首先我们加强了Sharding，提供了细粒度的Sharding能力，细粒度Sharding主要加强了PG原生内核相对单机化的架构，计算存储相对耦合，不利于云化和分布式下弹性和扩展管理。通过细粒度Sharding，使得用户表在存储层实现一定程度上的隔离，支持在线的Shard迁移，进一步提升分布式的能力和云化弹性能力。
同时，通过统一化组件，将协调节点和data node合二为一，成为统一的DB Node，和数据库相关的功能在一个组件里面提供，使得云化部署和管理更加的简洁。最后通过分布式和Sharding能力的插件化，保持对社区版本的兼容，保证用户可以快速地升级。
至此，Polar DB开源项目通过三步演进，实现了对PG内核的分布式扩展，保证分布式一致性，同时兼容PG SQL能力和内核版本的升级，具备云化的弹性和管理的简洁性。当然，后续仍然有很大的优化空间和很多特性会持续推出，比如分布式计算的持续优化、混合负载、HTTP等。
（五）路线图小结
最后，用下图来小结我们路线图的目标和希望达成的方向。
我们期望开源PolarDB是一个高扩展分布式、细粒度、弹性、基于共享协议的高可用，以及易于兼容社区的插件化，每一个目标都反映了我们对云化数据库基础需求的理解。
开放问题
最后有三个相对开放的问题。
第一个问题是关于分布式和集中式数据库的市场的考虑，从个人角度来看，传统数据库以集中式为主，市场也是如此，将来在很长时间内集中式仍然会是主体。分布式在完善功能、构建生态上会不断地进步，可以占据一定的市场份额。如果分布式能够兼容集中式的模式，那么分布式产品既可以当做集中式来使用，还可以按需扩展成分布式，那么更多市场份额就可以期待，这也是我们为什么选择把开源产品做成分布式主要的原因。
第二个问题是关于分布式和计算存储分离的关系，个人理解二者是不冲突的，是垂直的关系。分布系统是可以使用集中式的存储，甚至更加广义地讲，很多云设施可以当成集中式来使用，比如云的块存储，对象存储等等。分布式可以通过自身的扩展性，更加有效地利用这些云存储的带宽和IOPS，所以我们的分布式开源产品将来也会做针对存储计算分离，或者是利用云存储这样的架构的优化跟提升。
第三个问题是关于扩展分布式数据库生态，我们既然已经有了分布式数据库，它天然就具备一致性、扩展性和分布式计算等能力。那么我们是否可以通过新的数据访问接口和引入新的用户定义计算功能，来扩展它所能支持的服务能力，比如将它扩展成其他服务的存储系统或计算执行系统，这些都是非常值得我们去思考的，但是前提条件是我们先打造出一个完整、功能完善、稳定的开源分布式数据库，这样在此基础上，我们就可以做更多更加有意思的多生态的工作。
