往期分享
RDS MySQL
RDS PostgreSQL
RDS SQL Server
PolarDB
Redis
MongoDB
概述
PolarDB集群原生支持读写分离方式接入业务，但是在真实业务中，经常出现节点上负载不均情况，严重的话可能导致单节点承担大量的流量被拖跨，最终整个集群雪崩影响业务。
本文主要描述PolarDB代理的配置方法以及流量不均时如何定位。
数据库代理
基本信息
在RDS MySQL产品中，数据库代理需要单独购买并配置，而在PolarDB M集群中，默认即开启数据库代理功能，同时功能也比 MySQL的数据库代理更为强大。
- 主地址：读写，直接指向主节点，只能配置连接名，无法配置代理功能
- 集群地址：读写方式可配置，支持标准代理配置，不可删除
- 自定义地址：读写方式可配置，支持标准代理配置，可删除
地址配置(ENDPOINT)
只读类型
在选定读写模式是【只读】类型的情况下，配置项比较少，需要注意的是只读类型的endpoint如果只使用单节点，尽量不要应用在生产环境中。
另外可调整的参数是【并行查询】，此配置只在只读endpoint中可配置，在PolarDB 8.0 中支持了并行查询，如果只读endpoint承接一些AP类业务流量，可以单独提供只读节点给此endpoint，并且尽量和TP业务节点不要重合，同时对并行查询的并行度单独调整，以充分利用CPU资源执行并行查询。
读写类型
读写类型中需要注意的点主要是
- 一致性级别
- 最终一致性：不考虑数据的同步情况，按负载进行节点请求的调度，会出现写入的数据未同步完成，只读节点上读取不到的情况，抽象如图：
- 会话一致性：简单理解就是指在同一个连接里的前后请求，一般在写入后立即请求数据时使用，也是PolarDB推荐的一致性配置，抽象如图：
- 全局一致性：每一个会话都要判断只读节点是否已经同步到最新数据，对一致性要求最高的场景下启用，抽像如图：
- 以上三种一致性级别，需要根据业务需求配置。
- 主库不接受读：满足一致性需求的前提下，将读请求全部分流到只读节点执行，如果不满足一致性需求（只读同步完成），流量还是会路由到主实例。
- 事务拆分：将事务头部的读取语句拆分到只读节点上以承担主节点压力，如图：
- 连接池
- 会话级连接池：用以缓存连接信息，主要是连接风暴的场景下使用，例如PHP大量短连接的场景下，无法控制连接到实例的总连接数
- 事务级连接池：标准连接池方案，对长连接进行复用，类似Druid等连接池中间件，控制连接实例的总连接数
注意
- endpoint配置读写模式时，系统表查询会被路由到主节点，即使节点没有配置在当前endpoint，可能对一些业务场景有影响，例如：
select * from information_schema.processlist;- 读写模式下，即使没有配置主节点，写请求会自动路由到主节点
- 如果对一致性有要求，推荐使用会话一致性，可以满足大部分业务场景，如果小部分业务的一致性要求不能在同一会话中完成（dml ->select)，可以考虑使用hint方式强制读主节点，例如：
/*FORCE_MASTER*/ select * from information_schema.processlist;流量定位
有时观察实例性能，会发现实例的流量不均匀，需要定位原因，防止流量倾斜导致的实例性能问题。
常见问题
- 主节点负载高， 只读节点负载低的情况
- 场景一：都是业务侧直接连接了主地址导致只读没有分流，特别是在【RDS一键迁移PolarDB】的最终切换过程中，默认原RDS地址会切换到PolarDB的主地址上，这种情况下会导致流量全部流转到rw节点。此类问题需要业务侧调整连接地址为集群或自定义地址。
- 场景二：使用的是读写分离地址，但业务上有大量的写，在代理层会把所有的写流量路由到主节点。此类场景可以尝试打开【主库不接受读】和【事务拆分】，尽可能让只读节点承担一些读流量
- 只读节点负载高，主节点负载低
- 此类场景一般是预期内的只读节点承截流量，例如配置了主不接受读和事务拆分，同时大量的请求都是读请求时，此类场景是比较理想的PolarDB流量分配，即使只读节点资源不够，也可以通过快速添加新的只读节点以分担负载，监控曲线例如：
以上两种都是预期内的负载分配，但有可能负载情况不在预期，如集群地址中有多个只读节点，但只有某个节点负载非常高，此类情况就需要定位是否有流量异常或者实例性能异常的情况。
异常定位
- 实例复用
- 由于PolarDB可以自定义多个endpoint，不同endpoint之前节点也可以复用，就有可能造成流量交叉导致实例负载不平均，例如TP业务和 AP业务不同的地址，但配置了相同的只读节点，如果出现交叉使用的节点负载异常，有很大可能就是不同业务之间的资源争抢，可以尝试将问题节点从某个地址中摘除，再对比负载情况。
- 另外不建议节点交叉部署。
- 实例本身性能问题
- 在某些情况下，实例可能是由于自身问题导致资源负载高，例如在《PolarDB MySQL CPU高问题》 一文提到的AHI问题，不同节点分配的流量会导致AHI的分配也不相同，可能会导致某个节点上出现争抢问题，此时就要定位具体原因以优化节点性能。另外代理层是按负载情况分配的，如果单节点负载高，流量也会自动向负载低的节点倾斜，可能导致集群性能整体出现问题。
- 来源定位
- 目前PolarDB还未完全接入DAS历史数据诊断，如果需要定位异常流量来源，只能观察当前连接请求的情况，在一键诊断->会话管理 入口，可以查看用Hosts维度会话的统计，以确认是否有非预期的业务来源访问。同时可将正常节点与异常节点做对比以定位异常流量来源