基于云原生数据库 PolarDB for PostgreSQL 分布式开源项目实现序列号生成和性能调优赛题解析 | 学习笔记

开发者学堂课程【第八届大学生创新创业大赛阿里命题数据库命题解析：基于云原生数据库 PolarDB for PostgreSQL 分布式开源项目实现序列号生成和性能调优赛题解析】学习笔记，与课程紧密连接，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1045/detail/15278

基于云原生数据库 PolarDB for PostgreSQL 分布式开源项目实现序列号生成和性能调优赛题解析

内容介绍：

一、PolarDB for PostgreSQL 分布式架构

二、比赛题目

一、PolarDB for PostgreSQL 分布式架构

1、PolarDB分布式是基于社区 pg 上面演进出的分布式架构，主要采用mpp架构，主要分两层，一层是协调节点，一层是存储节点，协调节点负责用户数据接入多个协调节点之间是彼此独立的，也就是每个cn节点都可以单独接受用户的查询请求，其他节点处理sql请求的时候，它会生成分布式plan，发到对应的DN进行执行，把执行结果返回给客户端，真正的表数据是在多个dn节点上存储，比如表的数据，它会根据分布k划分为多份数据，单独的一份数据会存储在单独的data node节点上，可以增加背景的形式保障它的可靠性，分布式事务采用的是2PC提交的方式，也用了 hnc 的四种协议保证一致性。

2、经过过去几个版本的迭代，演进出插件化的形态，在社区单机配件基础上提供分布式的插件，通过使用插件，就可以把单个 pg 扩展成分布式的集群，可以用代码部署单机节点，如果后续业务有需要，可以用插件的形态把单个节点继续扩展为分布式集群，内核组建相对更加统一，数据库节点没有那么多的类型，在兼容性方面可以做到兼容pg的最新版本，sql功能方面，尽最大的限度兼容单机的 sql 功能，但是分布式跟单机还是有一些区别，有的地方还是需要继续演进。

3.插件化的一种形态，在插件里面包含查询优化器，分布式事务的管理，以及连接池功能，比如用户的 sql 过来之后，在插件里面，社区编辑器有 hook 功能，利用 hook 在插件里面进行分布式的查询优化，把执行计划再分发给对应的data node，让它执行再收集结果，分布式事务方面，2pc结合的四种协议，2pc在commit时候，会先进行 prepare，完成之后，再进行连接，减少连接的负担，以及更好的管理 Cn和 dn 之间的 commit，在插件里面也维护了一个连接池 hlc 特性在 data node上需要有一些支持，但是没有进行插件化，在设计底层存储进行修改，在pg11版本上提供patch，用社区11版本再加上 planner patch，再加上插件，就可以得到完全的支持，分事务分布式的 pg 数据库。

4、交互流程，一个cn，底层有两个cn，假如用户连接到cn1上，开始执行sql，首先sql会分发到各个dn上，cn上自己当前的时钟，发送给dn1和dn2，dn1和dn2在收到时钟之后，它会跟自己的本地时钟进行比较，会把自己的本地始终更新为最大的值，当cn开始commit时候，开始2pc的过程，首先进行prepare，发送给各个dn之后，每个dn就会把自己的本地时钟往前推进，加一，把preparets回复给cn，cn会拿到所有dn的prepare ts之后，会从里面选择一个最大的prepare ts作为分布式事务的提交式检索，同时它也会把自己的本地时钟推进到最大的commit ts，进行加2PC的第二阶段，向各个dn发送commit，DN会把自己的本地时钟也会继续推进提交时间，完成两阶段的第二阶段，整个分布式事物就是简单的概要。

5、演示用代码和文档部署环境，文档和代码通过链接都可以找到，直接直接直接找到。

参考文档: htps://github.com/ApsaraDB/PolarDB· -for- PostgreSQL/tree/distributed#deployment-from-source code

代码 : htps//github.com/ApsaraDB/PolarDB-for- PostgreSQL/tree/distributed

在一台机器上部署两个CN和两个DN的分布式集群，用阿里云的ecs，把代码下载好，首先直接从编译开始，编译也提供了脚本，bash里面需要注意的地方就是要安装的目录需要指定，包括安装的时候，有bug或者之类的一些选项，默认情况下，什么都不加就可以，编译好之后，可以看配置下环境变量，后面操作会更方便一点，路径跟bash中对应的，准备部署文件，对pgxc ctl工具进行改造，用prepare distributed命令可以直接直接把SHOME/polardb/ polardb_ paxos . conf配置文件准备好，配置文件的默认就是在一台机器上进行两个dn，一个sql进行部署，内容里面格式跟查询社区是一样的，可以有两个cn，也会有两个dn，包括端口号，如果有需要修改的，可以自己修改，用默认的就可以，清理集群就是可以把上一次部署的一些目录进程全部清空掉，有配置文件，用命令可以初始化集群，首先会把commit 和datanode initdb拉起来，因为插件本质上在polarx基础上进行修改，可以看到每个插件每个节点都会进行poreign data wrapper polarx添加的操作，这时已经拿到两个cn，两个dn的节点，可以看到状态，15，16是两个cn，18，19是两个dn，可以连接上看，select*from pg foreign_ server可以看到两条cn，两条dn，端口号，比如随便插两条数据，分布式数据最终会到底层的两个dn上，可以查到两条数据，

cn1，cn2也可以查询到数据，连接到某一个dn，18和19是dn，可以看到插入的两条数据，1和100，1落在dn1上，在另一个节点，100数据，整个集群搭建好。

二、比赛题目

1、序列号的生成，序列号在单机里面比较容易实现，用一些进程间通信就可以实现，因为分布式的网络通信的开销会大，单机本身的复杂度也比分布式要低，所以现在的目标就是在分布式的集群里面，设计跟单击数据库里面sql效果差不多的东西。

2、可以看单机sequence的实现，一些用法，语句和语法是兼容的，有extval，setval，currval，lastval操作，默认从start1开始，nextval是2，之后是3，不管多少个sequence连接到数据库里面，每次顺序都是单调递增的。

3、但是在分布式环境里面的情况就会变得复杂，客户端可以连到不同的cn，不同的cn之间需要产生全局有序的序列号，要求就是在介绍的分布式数据库的项目上实现功能实现nextval，setval，currval，lastval操作，在实现的方式上，有几条路径可以选，需要在功能和性能上有平衡，比如用最严格的方式，比如跟单机的效果是一模一样，也就是产生sequence一定是全局单调递增，在不同的session之间要生成严格有序的序列号，不管多少个客户端连到不同的cn或从全局上看不可能出现有两个一样的序列号，比如cn1上next1，cn3上next得到3，中间的2被缺掉是不行的，方式是严格有序，但是方式的性能会有一些影响，所以可以用另外一种路径，可以分批进行分配，可以在每个session上或者每个cn一批一批的进行分配，比如session获得1到100，另一个session获得101到200，一定是递增的，但是不一定是严格有序的，可能中间会缺一些东西，但是能换来性能上的一些的改进，在全局范围内也不会出现两个一样的sequence。

4、第二个题目是性能调优的题目，因为在数据库场景里面经常会看sql跑得慢或者性能比较差，经常做性能调优的事情，在单机数据库里面可以通过常见的命令或者在数据库里面采集函数级别的信息做事情，但是在分布式上面，题目是开放性的，比如一台机器的节点，有方法可以做性能的查看和诊断，但是包括业界没有好用的工具，在分布式跨了几个节点或是在场景下有全局的统计，内部的一些汇总，buffer命中率，cpu的利用率，每个节点上的热点函数，希望profile性能调优的工具最后是一种图形化的形式进行展现或者让开发人员方便的获取整个数据库内部的热点瓶颈等形式。