开发者学堂课程【关系型数据库 ACP 认证课程：【视频】-RDS-云关系行数据库的解析与实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14620
【视频】PolarDB-云原生关系型数据库的解析与实践
（1）海量数据，快速查询
● PolarDB 采用计算和存储分离架构，支持数据库服务器的 CPU 、内存能够快速扩容，最快可增加15个只读节点，支持并行查询、读写分离等功能，使查询耗时指数级下降，解决计算量较大的查询、多表连接查询、日常报表查询等轻分析类业务需求。
● 并行查询： PolarDB MysQL 8.0重磅推出并行查询框架，在存储层将数据分片到不同的线程上，多个线程并行计算，将结果流水线汇总到总线程，最后总线程做些简单归并返回给用户，提高查询效率。
● 读写分离：最多可增加15个只读节点，通过控制台打开事务拆分功能，可把事务中的部分查询路由到只读节点，提升查询速度。
● 资源隔离： PolarDB MysQL 引擎可以设置多个连接地址 Endpoint 连到不同的节点上，提供给不同的业务使用，一般用于隔离 OLAP 负载，避免对在线业务造成影响。比如在正常情况下有一个主节点以及很多只读节点，若想让一些只读节点服务 AP 的请求，就可以将其绑定到 Endpoint 上，相当于把 AP 的请求隔离到这几个只读节点上，其查询无论耗费多少 CPU 资源或内存，都不会对 RW 节点即主节点造成影响。
一、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 的物理复制，其本质是对底层的文件快的配置维度进行更新和回访，他具备更高的性能，并且能够保证数据状态实时同步更新，同步实言就会相对低一点，相当于是可以真正实现主备集群的访问一致性，也就是说在主节点上，最新的数据斜路在几个毫秒之后，就能在指定节点上访问到。
