开发者学堂课程【关系型数据库ACP认证课程：快速学习 PolarDB-云原生关系型数据库的解析与实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14620
PolarDB-云原生关系型数据库的解析与实践
内容介绍：
一、 PolarDB 的初步介绍
二、 PolarDB 的架构原理
PolarDB 的使用及相关操作
二、PolarDB 的架构原理
1、 PolarDB 架构解析
（1）PolarDB 架构
读写分离：如图， ECS 部署的即为应用的机器，相当于 Cache 以及 Proxy 层，代理做的是读写分离。 PolarDB 的上层暴露给客户的是一个 Proxy 层， Proxy 层可以做负载均衡以及读写分离，相当于充分运用读写节点、只读节点这些计算的实例来提升访问效率。
计算与存储分离：第三层为 DB 的计算层，因为 PolarDB 是存储计算分离，所以 DB 分为计算层和存储层，第三层为计算层，计算层有很多实例，一个实例为读写节点，剩下的N个实例，最多支持15个只读节点。
高速链路互联：RDNA 是一个高速互联网络，计算层和存储层就是通过 RDNA 这样的网络去连接。其效果是通过 RDNA 协议去节约计算层、计算节点上的 CPU ，因为 RDNA 的吞吐比较高，所以 CPU 瓶颈可以被节约掉。
一写多读：在计算层，包含一个主节点和最多15个只读节点，这是 PolarDB 一写多读主流的架构。
共享分布式存储：通过 Proxy 进来的流量读写请求全部由主节点来下发，读请求均由只读节点下发， PolarDB 的计算节点包括主节点和只读节点均无状态，其数据文件等存在底层分布式文件系统中，各个计算节点只需要同步原数据信息，极大的降低了主节点和只读节点的复制延迟，相比于 Binlog 来说，每个计算节点都存储于一份数据之中，这是 RDS 常用的方案， PolarDB 是各个计算节点共享的，降低了用户的存储成本；另外其底层存储容量可以在线平滑扩展，因为它是分布式的独立服务，不会受到单个数据库服务或者单个物理机器的容量限制，这样才可以应对上百的 TB 级别的数据规模。
数据多版本 Parallel-Raft 协议：底层的分布式文件系统，其存储节点采用三副本形式，确保数据的可靠性。 Parallel-Raft 协议是 PolarDB 自研的基于 Raft 协议做的变种，相比于普通的 Raft ，整个协议是类似的，但他提供了写入并发回放的能力，可以基于文件快的维度去做回放。
（2）PolarDB 的可用性管理
PolarDB 同时支持多节点架构和多可用区架构两种架构。多节点上面可以挂多个主节点、多个只读节点、多个计算层，挂在同一份分布式存储上面，当主节点出现故障的时候，你的厨房地址会自动的选择一个主节点升级为新的主节点，这个整个流程都是 PolarDB 管控内部来完成，对于用户来说可能只是感受到了大概20秒或者30秒的一些故障，只要有一个重试的机制，重连上来就会发现整个服务又恢复可用了。还有一个情况，因为可能会有一个跨空区的需求，假设整个可用区都发生故障， PolarDB 支持多可用区架构部署，如果主可用区所有的整个可用区故障，相当于所有的主节点、折节点都是不可用的，可以去切换 Standby 所在的被可用区来实现一个跨 AC 的容灾。
（3）GDN 全球数据库网络
可以去在基于 PolarDB 去做一个节点级别的容灾，以及可用区级别的容灾，现在提出一个新的概念，如果整个集群都挂了，就包括主可用区，里面的读写节点、只读节点，以及被可能区的 Standby 有可能也故障了，由此引入了 GDN 的概念，如果在极端的环境中的话，整个集群都失效了，全球数据库的其他集群是可以继续提供服务的，可以实现全球的容载。
GDN 就是指全球数据库网络，它是由分布在全球不同地域的多个 PolarDB 数据库集群组成的一张网络，网络中所有集群的数据是可以保持同步的，只有一个集群式集群有读写权限，从集群是 GDN 中从主集群同步数据的一个从属集群，这个集群只有两类服务，一类是读服务，一类是写转发服务，特点是如果业务有出海的需求，有海外部署，那么从集群就可以提供出海业务的一个就近读。比如有欧洲的业务，有美国的业务，有新加坡的业务，新加坡的那些业务的对应的用户就可以去从新加坡的从集群去直接去 local 的读取，但是另外一方面，因为当前的基金还是一个单写的架构，所以如果新加坡的用户有写请求，是路由到主节点去写。
这里有一个优势，就是整个 PolarDB 的 GDN 是通过 Proxy 管理的，相当于用户不用去担心 client 是写向新加坡集群还是向美国集群，因为它的内核会自动去判断当前的机电集群是从集群还是主集群，如果是主集群就会直接写入，如果是从集群的话，内核就会直接做转发，是不需要用户去考虑的。
另外一方面，主集群是可以随着业务做跨可用区迁移，甚至是跨国迁移，比如起初核心的业务，或者 ECS 在上海，如果上海故障了或者要签业务，要迁到新加坡，这个时候 DB 也可以通过 GDN 做一个整体的主从集群的一个互相切换，这相当于做跨国的迁移。
（4）PolarDB 的访问方式
如何去访问数据库，特别是一写多读这种架构下怎样充分的利用扩展性。
访问点是数据库的一个访问入口，也可以称为接入点，也就是 Endpoint ，每个集群提供了多个访问点，每个访问点可以连接一个多或多个实际的物理节点。
默认如果新购买一个 point 会给两个访问点，分别叫主地址、集群地址，主地址就是主节点的访问点，当发生故障切换之后，系统就会把访问点自动指向新的这个主节点，在集群地址上面是自动的，可以去整合集群下的多个节点，对外提供一个统一的读写地址，这个集群地址是通过那个数据库代理，就是 Proxy 去访问，具有自动弹性、读写分离、负载均衡以及一致性、协调这些能力。如果购买了新的折扣节点，它就会自动加到这个集群地址中。
另外 PolarDB 还可以根据业务的需求去创建最多三个自定义的集群地址，在自定义的集群地址上可以指定任任意几个节点，即可以选这个所有节点中的一个子集去定义那个集群地址。
（5）数据库代理
数据库代理： PolarDB 数据库代理是位于数据库和应用程序之间的网络代理服务，用于代理应用程序访问数据库时的所有请求，具有高可用、高性能、可运维、简单易用等特点，支持自动读写分离、负载均衡、一致性级别、连接池等高级功能。
您可以连接 PolarDB 集群地址使用数据库代理的各项功能。它负责把请求路由到各个数据库，这样就可以去根据请求的类型，把写请求转发到主库，这是 Proceed 内部做好的， Proxy 除了读写分离、自动负载均衡，它还具有连接池的功能，连接池是一个非常常见的需求，可以解决连接数过多或者短连接业务频繁建立新连接导致实力负债过高的问题。
Proceed 提供的另外一个关键的功能是一致性。一致性是访问点的一个属性，也就是 Endpoint ，它主要是指用户在主节点和只读节点上访问数据的一致性。有三个选项，分别是最终一致性、会话一致性和强一致性，默认的是最终一致性的配置，这个在控制台以及新创建的集群地址都是可以自动去配的。
（6）PolarDB 多主架构
①基础功能
支持不同数据库在不同计算节点并发写入
目前最多支持32个节点同时写入
支持数据库跨节点动态调度，秒级切换
计算节点故障秒级完成切换
②应用场景
SaaS 应用：满足高并发性能需求，实现租户间负载均衡
游戏：更好的性能和扩展能力，支持世界服架构
电商：满足高并发读写需求
PolarDB 最常用的主推的模式是一写多读，多种架构实现了一个从一写多读到多写多读架构的升级，它主要面向的就是多租户，像游戏、电商等高并发读写的应用场景。
它整体架构的上面也有一个代理层，它可以把不同数据库请求转发到不同的主实例上，不同的主实例可以同时提供读写服务，底层还是用同一个分布式文件系统，因为它每个数据库数据只有一份并且共享存储，这样就可以保证不同节点上能访问到一致的数据，目前多主架构最多是支持32个节点的同时泄露，和之前一写多读的架构相比，它支持的是数据库跨节点的动态调度秒级切换，如图，如果一个DB从写入点1切换到写入点2是不需要做任何的搬迁数据，因为所有数据都在同一份共享存储上。
2、PolarDB 核心技术解析
（1）物理复制介绍
物理复制是 PolarDB 自主研发的一个技术，它是通过 InnoDB 里面产生的 Redo log 进行数据同步。
长期的情况下，一般都是 Bin log 的同步，但物理复制适用于 Redo log 的同步， Redo log 可以把主节点的数据列修改，产生的这个日志同步到从节点之后，从节点去解析回放，然后修改应用到自己对应的数据页上，这样就实现了配置级别的数据同步。
从节点有两种，一种是 RO ，还有一种是 Standby 节点，这两个节点都可以通过一部异部去回放，然后把 Apply 到对应的 Page 上面，这样读到的数据是可以对齐的，让用户可以在只读节点上面去访问到最新的一个写入数据。
（2）物理复制和逻辑复制的对比：
原生 Binlog 实现的数据同步机制是通过记录用户的一个写事务以及具体的各种SQL的信息，然后通过网络同步到备份的只读节点，只读节点收到这个 Binlog 后，需要对这些事物进行回放或者 SQL ，重复的去执行，不管 Binlog 是 Statement 类型还是 Ro 类，最终执行完成以后才能达到数据同步的目的。
逻辑复制对大数以及 GDR 这个语句会造成复制延迟，这是不可控的，另外一方面是其失误回放速度，因为本身SQL是比较复杂的，同步时延也相对较大，回放就有可能会变慢，无法在备份节点上去提供实时一致的访问，尤其是很多业务对一致性以及备份实言都非常敏感，这就相当于 RO 节点就只能做一个冷备，并没有意义，浪费了资源，像 PolarDB 的物理复制，其本质是对底层的文件快的配置维度进行更新和回访，他具备更高的性能，并且能够保证数据状态实时同步更新，同步实言就会相对低一点，相当于是可以真正实现主备集群的访问一致性，也就是说在主节点上，最新的数据斜路在几个毫秒之后，就能在指定节点上访问到。
（3）历史库引擎 X-Engine
X-Engine 是阿里自研的一个存储引擎，其目标是面向大规模的海量数据存储，提供一定高并发的一些事务处理能力，同时最重要的是能够降低存储成本。
首先，X-Engine 的热数据层和数据更新都是适用内存存储的，使用了一些内存数据库的技术。第二点是 X-Engine 做了流水线的事务处理机制，可以把整个受处理的几个阶段并行起来通过，然后把整个吞吐提升上去。第三点是 X-Engine 可以把访问频度低的数据逐渐淘汰，或者是合并到一个持久化的存储存储层中，然后结合多层次的存储设备，最好的是 NVM 非易失性内存， SSD 、HDD 一类的普通硬盘进行存储，因为 LSM TREE 是一个分层的架构，特别适合冷热数据区分的一个分层存储，另外对性能影响较大的 Compaction 过程做了很大的优化， Compaction 是 X-Engine 本身的一个流程，需要把这个分层的数据去做 merge ，但我们做的优化可以把整个 X-Engine 的数据存储力度做一个拆分，尽量的去利用数据更新、热点较为集中，然后再合并，合并过程中复用数据以及去精细化的控制， X-Engine 处理的这个形状最核心的其实就是为了减少 Io 和计算代价去缓解合并过程中的写空间放大的问题。另外还使用更细力度的访问控制和缓存机制，去优化读的性能。
（4）并行查询
● 有效利用多核 CPU ，大幅提升长査询的查询性能
● 并行查询支持大部分 SELECT 语句
● 适用轻分析类业务、离线分析场景等
主要适用于大表查询，多表链接计算量比较大的 SELECT 语句，适合场景:一个场景是轻分析报表类的查询，它 SQL 相对复杂，相比在线 tp 业务也会多耗时间，但通过并行查询可以加速单次查询的效率；另外一个场景是有些只读节点系统资源相对空闲，并行查询可以利用更多的系统资源，如果有充足的 CPU，充足的内存，就可以使用并行查询，把整个资源利用率和查询效率都提升起来。
第三块是在离线混合的场景，主要是隔离的场景对应上图：PolarDB 上不同业务去使用不同的连接地址，底层连接到不同的实际的物理数据库节点上，互相就可以不影响。
例如：可以把某个单节点去开启并行查询执行 OLTP 类型的请求，所有这些请求就只会通过单节点的地址下对应的只读节点去访问，相当于复杂且耗时的 SQL 就不会影响核心业务。
并行查询的关键是利用多核的 CPU 并行处理能力，当查询数量达到一定阈值之后，阈值会提前通过某些算法进行预估，会自动启用并行查询框架，但是可以提前定义好并行查询可以用多少个线程数，对于相关的请求存储层就会把数据分到不同的线程上面，把多个线程做并行计算，最后把结果流水线汇总到总线程，总线程做多个流水线的归并返回给用户可以提高查询效率。有一些分析型场景下测试会有10倍的性能提升。
My SQL 是一个 SQL 请求只会用一个线程，但是 PolarDB 并行查询上相当于在内核里孵化多个线程充分把资源利用起来，这个功能在开源的 My SQL 或者 RDS 是没有办法实现的。
