开发者学堂课程【PolarDB-X 开源分布式数据库进阶课程 ：PolarDB-X 读写分离与 HTAP】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1202/detail/18343
PolarDB-X 读写分离与 HTAP
内容介绍：
一、PolarDB-X 简介
二、课程介绍
一、PolarDB-X 简介
PolarDB-X 其实是一款分布式数据库，是一个存储计算分离的架构。对整个 PolarDB-X 架构来说有四个角色
·一个是 GMS 其实相当于提供一个全局授时服务；
·还有维护 Global Meta保存一些云信息；
·计算节点 CN，主要是基于无状态节点的 SQL 引擎提供分布式服务以及处理分布式事物的协调者；
·DN 是来存储数据基于故事协议的它可以保证数据的高可靠；
·日志节点，提供兼容 MySQL 生态的 binlog 协议。日志节点，提供的 binlog 兼容 MySQL 的 binlog 协议是整个业界分布式数据库为此一家。
用 PolarDB-X 数据库可以享受单机 MySQL 一样的体验
二、课程介绍
这次的开源是 V2.2版本，相对于之前的 V2.1版本提供的是国产化和企业级的特性，包括我们对国产化芯片、国产化系统都有一个方位的适配然后在提供内核能力上性价比更优，然后也提供原生 HTAP，除此之外相对于 V2.1还提供了很多产品的特性，可以说 V2.1可能是全内核的能力的一个开源，V2.2除了内核的进步开源以外还有一些产品能力的一些配套设施的开源。可以从相关的一些网站来体验是怎么来完成一些 PolarDB-X来提取的轻量化部署和运维。
除了这次课程以外，PolarDB-X 社区有很多开源的一些建设。比如说网站，包括有专门的支付专栏还有所有的开源代码。除此之外左下角是钉钉社区交流群有兴趣的同学可以扫描关注 ，右下角是微信开源交流群，两个群都比较活跃，也欢迎热爱开源数据库的同学一起共建 PolarDB-X 社区。
1、什么是数据库的读写分离
·使用场景
·业界方案
回归正题，本次的主题还是讲 PolarDB-X 如何在读写分离场景和 HTAP 场景的一个实践。
2、典型的读写分离场景:
首先讲读写分离，什么是分离顾名思义就是分离读库和写库的操作 。读写分离的场景主要是分为三种：读多写少的场景、超高并发的场景、高稳定性场景。这些场景主要是比如对电商的一些业务，它是典型的一个写少读多的场景，为了不让数据库的读成为业务瓶颈，同时也为了保证写库的成功率，一般都会采用读写分离的技术来保障。
业界是怎么解决读写分离的？目前业界的方案相当于是主要基于一些数据库代理上，例如 Router、MyCat 等这些东西，基于这样的数据库代理它的优点和缺点其实都是显而易见的。
比如它的优点就是引入数据库代理层，业务上不需要改动更多的代码，还是比较透明的。缺点也是比较的明显，相当于路由到请求无法保证读到最新的数据，叫弱一致性读。意思是比如说我们在主库上写一行数据，这种代理层去实现可能读到数据不一定是最新的，或者说刚写入的数据不一定能马上读到。同时无法基于从库的可用性做流量均衡路由，比如说某个从库挂了或者延迟比较大，这个时候业务还是会仅需路由的，其实对业务是一种有损的方案。
3、透明的强一致读写分离
·PolarDB-X 读写分离架构
·读写分离的使用
·可用性测试
PolarDB-X 提供的是一个透明的强一致的读写分离
4、PolarDB-X 读写分离特点
·高度透明化：应用不需要引入代理层或者改造代码，PolarDB-X 提供的是 Native 读写分离能力，应用连上 PolarDB-X 数据库直接就可以用。
·强一致性读：无论什么场景不用担心“备副本或只读副本”读不到最新的数据，因为它提供的是强一致的读写能力，可以确保成功写入数据，一定可以读到。
·灵活多变的配置策略：支持全局级别的多种读写配置策略；支持副本异常，流量自动切回主库的配置策略；某个副本延迟高，支持流量调度到低延迟副本的路由策略。
从这几个关键特点可以概括出本次读写的特点是高度透明化，就是用了 PolarDB-X 之后能享受它提供的 Native 读写分离能力，应用连接上 PolarDB-X 之后直接就可以享用读写分离这个能力；
强一致性读就是刚才提到的主库写入到的数据备库或者只读库读不到，那么我们提供的强一致性读一定能保证主库写入备库只读库是一定能读到的。除此之外相对于中间件模式还提供灵活多变的配置策略，比如说支持全局的、Session、Query 级别的多种读写配置策略；支持副本异常，流量自动切回主库的配置策略；以及某个副本延迟高，支持流量调度到低延迟副本的路由策略，这样一个丰富灵活多变的配置策略，其实可以很大程度满足我们业务场景的一个诉求。
在了解了读写分离特点后，看一下是怎么做的。
上图是整个读写分离的架构图，橘黄色可以理解成是主库部分，灰色是从库部分，那么主库和从库之间采用的是基于Paxos 协议的 Binlog 融合提供了一个 Consterlog 来提供一次性复制的，里面其实会维护一个叫类职位点，叫LogIndex 相当于主库每次写入最新的数据同时也会维护当前主库最新的类职位点，从库基于这种位点做一次性复制的过程中也会不断更新自身的全局类职位点，那么真正在读的过程中录入到从库的话会不断地比较主库和从库的一个类职位点的差异，确保我们从库更新的类职位点跟主库及时保持同步，整体是读写分离的一个大体的实现。
来看一下是怎样完成的，首先客户端把请求发送给 CN,CN 首先根据路由策略做判断，判断给只读 DN 的查询，首先会从主 CN 节点获取最新的 LogIndex,CN 把 LogIndex+TSO 请求一起发送给只读的 DN，只读 DN 根据接收到的LogIndex 判断当前位点的事务状态放到相应位点，根据 TSO 判断数据可见性然后给 CN 返回结果，通过这样的机制可以保证读到跟主库一致的数据，做数据开发不用太深入了解。后面有一个详细的测试来说明这样的一个能力。
在我们一个公用云的一个读写操作的交互页面上，我们其实用户购买的一个实力，主实力控制管理的一个页面我们可以配置读写分离的一个权重，然后是否要开启数据读一次性的能力，包括我们只读可用性，比如说，如果只读实力挂了，是否切回主实力的能力。
那么对开源用户，目前也会有相应的交互页面。除了上述的白屏操作以外，我们也提供了黑屏的操作。
PPT 的左上角可以看到，每个只读 DN 的负载包括延迟情况。PPT 的左下角就是全职的一个读写分离权重的配置，中间 session 的读写分离权重配置，右下角是支持 query 的读写分离权重配置，这是一个实用。
如果对这个能力做了两方面的测试，一个是正确性测试，一个是性能方面的测试。正确性测试构成的是一个先写后读的场景，如果我们把强一致性读开和关分别做一次测试，再强一次性读关闭的情况下，我们先写后读的场景下可能会出现少量的，并不是最新鲜的蔬菜最新鲜的数据，我们判断他是不一致的情况下。再强一致性读开始的情况下
并没有发生不一致次数写入数据一定能读到，这是正确性的一个测试。在性能上做了一个比对，其实把读写分离这样的一个权重珍珠裤做了一次性能再强一次性的情况下把只读库做了一次性能对比，发现其实在同等规格的情况下从库的性能衰减大概是主库的70%。
这是可以理解的，因为我们在读从库的过程中其实会获取全局意识累点有两三行的一个延迟，后续可能会演示，如果有多个从库的话，读写分离也持水平扩张的能力。
在下一个混合服在场景的实践之前，对于上次的读写能力做一个实操。
考虑到它配置比较低，这里已经准备了一些实例来做演示。开始之前先看一下这次实例的一些情况，介绍一下这里后面会说明的带了 s 就是主库，r 就是从库。我们先把读写的路由权重全部调成主库百分之百。
从这里看路有百分之百是主库的，那么 PolarDB-X 只是一个需要确实的命名可以看到我们上一次的查询到底是陆游的主库还是从库。
从这个命名可以看到当我们把权重设置陆游百分之百的时候其实是我们的陆游全部给主库的。
如果我们把主库设置成零在看到他的路由情况，这次路由全部给了只读库，是符合预期的，这里是一个全局的配置，把一个所有的权重的路由给只读库了，在这个基础上，我们再设置一个筛选的变量，相当于我们又把这个权重设置成了100。再做一个简单的查询，大家可以看到这个时候用路由给主库了，在这个基础上，我们又把实例全部设为了主库，再体验一下执行这样一个点查操作，虽然我们当前的配置是百分之百路由给主库，可以把流量又迁回只读库。
接下来我们在演示一下读写分离和性能看一下当前整个调查的qbs大概是60,000不到，然后我们把读写分离设置成50%，相当于这个时候我们既可以同时享受主库的资源也有从库的资源。这个时候再跑一下点查看性能是不是有提升刚才60,000不到，现在是130,000了，相当于读写分离场景下能够同时运用主库和只读库的资源，默认情况下我们是强一次性读，如果我们把强一次性关掉的话，看性能是不是又有提升？150000了，我们的强一次性涂对性能其实是有损的但是在业务允许的范围之内。
接下来在模拟一个比较有意思的场景，刚才说到我们之时当只读延迟过大或只读实例挂的时候自动切回主库的一个能力，先把强一次性读打开，把流量全部切给只读库，这个时候我们在开一个窗口，这时只读库目前是没有延迟的，那我们这个时候找一个大表，这个时候只读库是有延迟，延迟如果超过3秒可能需要等待等待超过3秒就会报错，怎样才能不报错我们设一个变量，就相当于延迟过大自动切换主库。执行成功了，切回主库执行。这个也是符合预期的。
接下来还有一个场景模拟一下只读实例挂了自动恢复，他其实也是高可用的，只读实例挂了有一个备用实例自动拉起，但不好演示，那么在云起实验室有一个环节，配置了一下只读实力挂了自动切回主库的一个能力，就不演示了。
5、混合负载场景的实践
·业界方案
·PolarDB-X 混合负载架构
·性能测试
讲完了读写分离的实践，再讲一下 PolarDB-X 现在混合负载场景的实践。
我们先看一下业界的方案目前其实是两个主流的发一个室内食材用的 Lambda 相当于 TP 数据库通过 AP 导到 AP 数据库去做分析，这是一个方案。那么另外一项 TIDB 就是一套数据库提供的 HTAP 能力，这里可能图有点老。
就相当于 PolarDB-X 目前也是这样一个设计提供一个混合负载的架构。把我们的 TB 流量路由给我们的主实例，AP 路由给只读实例。在这个基础上，根据我们刚才所说的 LSN+TSO 我们也可以提供再 HTAP 的架构下提供强一致性读的能力。基于只读实例我们提供的是一个物理隔离，这样可以确保 TP 和 AP 的流量不相互干扰，除此之外我们还有其余 cost 的负载，业务其实不需要太多的去识别什么是 TP 和 AP 流量，我们会基于 Coast 做一些判别，也可以减少很多业务的负担。
在这个混合复杂的场景下，我们也做了一些测试，首先开启一个 TPC -C 流量，我们把 HTAP 关闭的时候，会发现TPH 这个时候对 TPC 流量其实有一个大的影响。在这个时间段开启 HTAP 之后，TPC-C 和 TBH 混合跑的时候其实都可以到达一个物理隔离满足 TP 和 AP 的稳定性。
除此之外再看一个基于代价的选择执行模式，PolarDB-X 提供 Cost 的一个指令，可以看一下每条 circle 估算出来的worklod 到底 TP 还是 AP 这里可以看到是一个简单的点查，判断它是一个基于 cost 的模型，去判断它是一个 TP。对一个 ADG 的复杂查询基于 cost 判断它是一个 AP，除此之外提供了一个指令可以看到基于 AP 和 TP 到底跑的是什么执行模式。
再演示一下混合负载的一个能力，先把环境恢复可以看到它是一个简单的查询，因为它判断为 TP，从这里可以看到我们的 cost 会有四个维度一个是 net、memory、cpu、io。
这样一个简单的查询，看一下它选择的这些模式，执行模式 TP-LOCAL 是一个单机的 TP 的执行模式。
这里可以通过一个构造复杂查询，是两个大表，这个大表是 E 级别的一个大表，先做 join 再做 countdistinct，因为这两个 join 的条件是不对齐的所以这个复杂查询数据量应该是 E 级别的。在我们这个 HTAP 加速情况下，其实相对于之前的 TP-LOCAL 大概有三到四倍的性能提升。
