开发者学堂课程【如何使用 PolarDB-X：如何使用 PolarDB-X】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/983/detail/14926
如何使用 PolarDB-X
发现连接出错：
不能用 localhost ,换为 localhost 的 IP
点击提交，连接成功：
进行安装程序：
安装成功：
初始化完成，登录：
安装插件：
该插件可以对 WordPress 站点进行压测，包括数据库进行压测
找到该插件：
该插件功能的基本介绍：
可以测机器本身的计算能力
测 MySQL 的连接，连接完成后会做100万次的编解码
连接上数据库后会做基本的操作，模拟向该站点大量的写博客的内容
安装该插件：
安装完成后启用，在左边的工具菜单中点击 WP Performancr Tester
然后一键测试
完成后结果为：
以上内容演示完成
演示内容可总结为：首先，将 PolarDB-X 当作 MySQL ，从 WordPress 的官方的镜像仓库将 WordPress 的镜像写入本地，然后根据官方教程在本地启了一个博客站点，然后用 PolarDB-X作为数据库取代 MySQL，该站点搭建完成，上面可以正常那个的发表内容，同时选择了一个对数据库进行样测的工具，可以顺利执行。
四、如何选择应用端链接池
1.背景
当应用程序连接 PolarDB-X 实例执行操作时，从 PolarDB-X 实例的角度看，会有如下两种类型的连接:
·前端连接:由应用程序建立的，到 PolarDB-X 计算节点(CN)中逻辑库的连接。
·后端连接:由 PolarDB-X 计算节点建立的，到后端数据节点(DN)中物理库的连接。
PolarDB-X 是分成计算层和存储层，是存储计算分离的架构，应用端首先是与计算层 CN 连接（连接池 TCP 的连接都是连接到 CN ），CN 和 DN 之间也会 TCP 建立连接。称为后端连接，这里主要讨论前端连接。
其中后端连接由 CN 管理，通过私有协议实现 TCP 连接与后端连接解绑，对用户透明。前端连接由用户创建和管理，本文主要讨论前端连接管理的最佳实践。
说明为了简化描述，下文中的"连接"均代指“前端连接"。
2.QPS/RT 与连接数的关系
（通常，在一个数据库中，一个请求的 RT 会用毫秒作为单位来进行描述。如果其 RT 是某个值，则单个连接到 CN 的TCP 连接其 QPS 的上限为 1000/RT。一个应用连接上 CN ，单个 CN 处理的 QPS 等于单个连接的 QPS 上限*连接数）
每秒查询请求数(Query Per Second，QPS)和响应时间(Response Time，RT)是衡量应用对数据库性能需求的基本指标，QPS 代表应用并发访问数据库的需求，RT 代表单条语句的处理性能。 RT 的高低与执行的SQL是否复杂和扫描的数据量紧密相关，OLTP 系统中查询 RT 较低，通常以毫秒为单位。
PolarDB- X兼容 MySQL 协议，请求在单个连接上串行执行，不同连接上的请求可以并行执行，由此得到以下公式:
· 单个连接的 QPS 上限= 1000/RT
· 应用访问单个 CN 的 QPS 上限=单个连接的 QPS 上限*连接数
按照平均 RT 为5ms计算，单个连接的QPS上限为200，假设应用预估需要的 QPS 为5000，则至少需要建立25个连接。
3.连接数限制
PolarDB-X 中前端连接仅与网络连接绑定，连接的数量理论上仅受限于 CN 可用的内存大小和网络连接数。但在实际的场景中，应用创建连接是为了执行查询，连接数需要与执行线程的数量相匹配才能达到最佳性能。
如上图所示，应用发起连接请求后，首先由网络模块进行权限认证，认证通过则创建连接对象。与 MariaDB 相似， PolarDB-X 计算节点收到后续查询请求后，会尝试从线程池中分配一个执行线程，用于处理查询请求。单个 CN 节点默认维护一个1024大小的线程池，如果并发查询数量超过线程池大小，后续请求会排队等待。由此可以得到以下公式:
· 应用访问单个 CN 的 QPS 上限=单个连接的 QPS 上限 *MIN （连接数,线程池大小)
（如果在单个 CN 上，配置的常连接的数量大于1024，此时为1024*单个连接 QPS 的上限）
· 应用访问数据库的 QPS 上限=单个连接的 QPS 上限 *MIN (连接数,线程池大小) *CN 数量
我们通过以下两个示例来进行公式的实际应用:
示例1
问:查询的平均RT为10ms，理想情况下两节点 CN 能提供多少 OPS?
答:平均 RT 为10ms，则单个连接的 QPS 上限为100。理想情况下( CPU 不成为瓶颈)，包含2个 CN 节点的 PolarDB-X 实例默认能够提供的 QPS 上限为100*1024*2 = 204800。这里需要注意，CN 节点能够同时处理的查询数量与 CN 规格和查询复杂度有关，实际场景下通常不能做到1024个线程完全并行，QPS 上限会低于204800。
示例2
问︰在CN规格为16C的 PolarDB-X 实例上压测，CPU 刚好跑满时，某查询的平均 RT 为5ms。仅考虑 CN 节点，支撑40w的 QPS 应当如何选择实例和设置应用端连接池?
答:平均 RT 为5ms，则单个连接的 QPS 上限为200。应用端连接池大小设置为400000/200 = 2000可以将额外开销降到最低。保持单个 CN 节点上的并行度不超过1024，需要两个16C节点构成的32C的 PolarDB-X 实例。
4.连接池
数据库连接池是对数据库连接进行统一管理的技术，主要目的是提高应用性能，减轻数据库负载。
· 提高系统响应效率︰连接的初始化工作完成后，所有请求可以直接利用现有连接，避免了连接初始化和释放的开销,提高了系统的响应效率。
· 资源复用∶连接可以重复利用，避免了频繁创建、释放连接引入的性能开销。在减少系统消耗的基础上，增强了系统的平稳性。
· 避免连接泄漏∶连接池可根据预设的回收策略，强制回收连接，从而避免了连接资源泄漏。
如果是 Java 程序，推荐使用 Druid 连接池，版本要求1.1.11及以上（对分布式系统比较友好）。
Druid 的Spring 标准配置如下：
5.注意
通常，分布式系统或数据库在前端会有负载均衡这样一个组件来负责应用的接入，但是负载均衡的一些算法可能对 CN 节点不是非常友好。
连接池模式（ TCP 长连接）效率更高，但部分场景下对分布式负载均衡不友好，可能导致CN 负载不均匀
场景：
（1）突发创建连接,导致分布不均
如果应用存在突发创建大量连接的情况，负载均衡设备无法及时刷新统计信息，可能出现部分 CN 上连接较多，结合连接池化，最终导致部分 CN 压力高于其他 CN，影响系统总体性能。
（2）负载均衡探活异常。导致分布不均
负载均衡通过主动探活来判断 CN 节点是否正常，当探活出现偶发异常时，可能导致部分CN 上连接较少，结合连接池化。最终导致部分 CN 压力低于其他 CN 。影响系统总提性能。
Druid 连接池增加了phyTimeoutMillis/phyMaxUseCount 参数，定期（例如执行10000次或者10分钟）刷新连接池中的连接，可以在解决上述问题的同时保持性能基本不变，建议默认添加这两个配置。
（简单来说，当 TCP 连接异常时，会有一个超时机制，即使一直在正常使用，但是使用一段时间后要将其端开，让其重新连接。另一个策略是一个 TCP 不间接能够处理的请求数量有上限，例如其处理了一万次请求，则强制将其断开。这样的好处是，使得负载均衡和 CN 之间 TCP 长连接不会永远被占用，总有一个达到一定程度会被断开进行再次连接。如果出现连接全部被路由到一个CN 的情况，时间过长后，其他连接会在参数的连接机制下，会有断开再重新连接的过程，在下次连接时可能被分配到其他 CN 上。总体看，会使负载均衡与 CN 的连接数量保持相对均衡。）
· 应用线程数与连接池
应用程序访问数据库的一种常见模式，是在应用程序中创建多个线程，每个线程获取一个到数据库的连接并执行查询。为了减少创建/释放线程的开销，通常会使用"线程池"来管理线程，线程池的一个重要参数是"最大线程数"，需要根据实际情况调整。
理想情况下，查询的 RT 波动不大，可以应用上文介绍的公式，根据 RT 计算出合理的连接池大小，并按照"每个线程一个数据库连接"的思路确定最大线程数。实际场景中，查询RT受到热点、锁、数据倾斜等多种因素的影响，可能出现突发 RT 增长，甚至部分连接失去响应。如果完全按照理想情况连接池/线程池，可能由于部分慢查询耗尽连接池/线程池，导致应用失去响应，影响关联系统。因此。建议按照"理想情况"的1.5到2倍来设置最大连接数/线程数。
