ShardingSphere-Proxy 与代理调优

• 透明分片（对应用无感知）
• 协议兼容（MySQL/PostgreSQL 协议）
• 分片规则与执行

ShardingSphere-Proxy 是一个独立进程的数据库代理，对客户端实现"透明分片"：应用像连接单库一样连接 Proxy，无需修改 SQL 或感知分片，由 Proxy 负责把逻辑 SQL 改写为分片后的实际 SQL 并路由到各后端分片库。透明性体现在：1）协议兼容——Proxy 实现 MySQL/PostgreSQL 的客户端协议，应用用标准驱动（JDBC/连接池）连接即可，像连普通数据库；2）逻辑库/逻辑表——应用面向逻辑库表，Proxy 按分片规则（分片键、算法）把查询改写与分发到真实物理表；3）聚合——跨分片的查询由 Proxy 做结果汇总（合并、排序、去重、聚合）。实现原理：Proxy 解析 SQL、识别分片键、按分片算法（如 hash_mod、range）计算目标分片、改写 SQL（表名、库名）、路由到对应后端、再合并结果。透明分片让应用无需改造即可获得分库分表能力，代价是 Proxy 成为性能与可用性上的中间层（需高可用部署）。

透明分片的核心是"逻辑分片 + 协议兼容 + 自动改写路由聚合"。Proxy 把分片复杂度从应用下沉到代理层，让应用以单库方式使用分布式能力。

• JDBC 形态（嵌入应用）与 Proxy 形态（独立进程）
• 性能、部署、适用场景
• 选型

ShardingSphere-JDBC 是"嵌入应用"的形态：以 jar 形式作为应用依赖，在应用进程内完成分片解析、改写与路由，直接连接各后端分片库。优点：性能好（无额外网络跳转）、部署简单、无独立进程运维；缺点：强耦合应用（多语言应用需多种实现）、扩展性受限（规则在应用内）、连接数随应用增多。ShardingSphere-Proxy 是"独立代理进程"形态：作为独立服务监听端口，客户端（任何语言）通过标准协议连接，Proxy 统一完成分片逻辑。优点：语言无关（多语言应用统一接入）、集中管理（规则集中在 Proxy）、便于扩展与治理；缺点：多一层网络跳转（性能略差）、独立部署与高可用运维成本。选型：单语言、性能敏感、应用内嵌 → JDBC；多语言、需集中治理、不想改应用 → Proxy。实践中常结合（Proxy 对多语言、JDBC 对单语言高效场景）。

JDBC 与 Proxy 的差异是"嵌入 vs 独立"：JDBC 快、耦合、单语言；Proxy 语言无关、集中管理、多一跳。按应用语言与治理需求选型。

• 连接池与代理的连接关系
• 连接数、复用与超时
• 代理对连接池行为的影响

在数据库前放代理（如 ShardingSphere-Proxy、ProxySQL）后，应用连接池（HikariCP）连接的是"代理"而非"数据库"，影响：1）连接数：应用连接池连接代理，代理再连接后端库；连接池的连接数（如 maximumPoolSize）现在对应"前端连接"，后端连接由代理管理（可复用），从而可降低后端连接压力；2）连接生命周期：代理后端连接可能被复用/复用受限，HikariCP 的 prefill、连接有效性校验（validation）会打到代理，若代理有会话状态限制，需注意；3）超时与排空：HikariCP 的 connectionTimeout、idleTimeout、maxLifetime 需与代理的会话/连接策略匹配，否则可能连接不够或代理端连接被复用导致状态串扰；4）事务/会话：HikariCP 默认连接池复用连接，若代理把连接复用给不同事务，可能破坏会话状态（HikariCP 有 isolation、readOnly 等属性在归还时重置）。总体上，代理充当"连接托管层"，让应用连接池连接代理，后端连接由代理池化复用，但需协调连接池参数与代理的会话/复用策略，避免超时、状态污染与连接数不匹配。

代理改变连接拓扑：应用池连代理、代理池连后端。关键是协调连接池参数（超时、生命周期、校验）与代理的复用/会话策略，避免状态串扰与连接不足。

• 代理保持客户端连接（故障时客户端不断连）
• 快速探活与后端重连
• 吸收重连风暴与事务回滚

云厂商 RDS Proxy（如 AWS RDS Proxy）通过代理层优化故障转移时间：1）保持并复用客户端连接：故障切换时，代理保持客户端连接不断开，客户端无感知故障，避免了应用层重连延迟；代理在后端切换后，把同一客户端连接透明地重连到新主库，客户端无需重新认证与建连。2）快速探活与后端重连：代理主动探测后端健康状态，检测到主库故障后快速将连接切换到新主库，缩短恢复时间。3）吸收重连风暴：故障时若大量客户端同时重连会造成"重连风暴"（压垮新主），代理通过保持连接 + 复用连接池，避免客户端集体重连，缓解风暴。4）自动回滚中断事务：故障发生时在途事务被中断，代理检测到连接中断后自动回滚未完成事务，保证一致性，避免客户端拿到中间状态。代理还维护连接池（复用后端连接），减少建连开销。综上，代理把"故障转移"从"客户端重连"变成"代理内部透明切换"，显著降低 RTO 与重连风暴风险。

RDS Proxy 优化故障转移的核心是"代理变透明切换层"：保持客户端连接、快速后端重连、吸收重连风暴、自动回滚事务，让故障对应用近乎无感。

• 连接排空（draining）机制
• 新主连接预热
• 防止雪崩与失败

主从切换时，代理层通过两机制防止连接雪崩与请求失败：1）连接排空（draining）：在切换前，代理停止向旧主发放新连接/新请求，等待已在途请求与事务完成（优雅排空），再关闭旧主连接；避免切换瞬间旧连接仍在处理导致数据不一致或请求失败。排空期间，新请求被路由到新主，旧连接逐步清理。2）新主连接预热（pre-warming）：切换后，代理主动预先建立到新主库的后端连接池（预热连接），避免大量客户端在切换瞬间同时触发冷连接建立（连接风暴）导致新主被压垮；预热连接让客户端请求能立即使用已就绪的后端连接。3）吸收连接/请求风暴：通过连接池复用 + 预热，避免切换瞬间的密集建连与请求集中打向新主。4）请求失败控制：排空期间对受影响的在途请求做优雅处理（如返回重试提示或自动重试），平衡"如果主从切换"的请求成功率。综合，排空 + 预热 + 连接池复用，把切换瞬间的连接压力平滑化，防止雪崩与大面积请求失败。

防雪崩的核心是"切换前优雅排空旧连接，切换后预热新主连接"。排空避免旧连接混乱，预热避免新连接风暴，两者配合让切换平稳。

• SQL 审计日志
• 字段级脱敏机制
• 与访问控制结合

代理层（ShardingSphere-Proxy、ProxySQL 等）可实现 SQL 审计与字段级脱敏：1）SQL 审计：记录每个查询的 SQL、来源 IP、用户、时间、耗时、影响行数等，形成审计日志，用于安全合规、安全告警与排查；可对敏感操作（如 DDL、DELETE、全表扫描）特别审计。2）字段级脱敏：在返回结果前对敏感字段（如手机号、身份证、银行卡）做脱敏处理（如掩码 138****1234），或对查询参数做脱敏，防止敏感数据泄露。实现：代理在解析 SQL 与路由后，对匹配的字段/查询应用脱敏规则（配置脱敏算法与字段映射），改写 SQL 或对结果集脱敏。审计与脱敏结合：审计记录"谁在何时查了哪些数据"，脱敏保证"返回的数据不泄露明文"。设计要点：脱敏规则要精确（避免误脱敏业务数据）、审计日志要安全存储（防篡改）、性能开销可控（脱敏/审计不能拖垮吞吐）。代理层的审计与脱敏是"数据安全中台"在数据库访问题下的落地。

代理层审计与脱敏的核心是"统一在数据库入口做安全管控"。审计记录访问，脱敏防止泄露，两者结合让敏感数据在代理层被治理，无需改应用。

• DistSQL 的概念
• 在线增删改分片规则
• 热更新与生效

DistSQL（Distributed SQL）是 ShardingSphere 提供的 SQL 再管理接口，用于在线管理分片规则、数据源、权限等配置，无需重启 Proxy。通过 DistSQL 可：1）创建/删除逻辑库与数据源（CREATE DATABASE、ADD RESOURCE）；2）在线定义/修改分片规则（CREATE SHARDING RULE、分片算法、分片策略）；3）查看当前规则（SHOW SHARDING RULES）；4）在线调整配置并热生效（DistSQL 变更直接加载到运行配置，无需重启）。在线管控的优势：规则变更（如新增分片、调整分片算法、改写分片列）可动态下发，实现"配置即代码"的运维，支持灰度逐步调整。DistSQL 与 RESTful API 是 ShardingSphere 的两种管理与 bootstrap 方式，DistSQL 更贴近 SQL 习惯、便于脚本化。设计要点：DistSQL 变更需谨慎（分片规则变更影响数据路由），变更前应校验一致性、评估影响，必要时配合数据迁移。在线管控分片规则让 Proxy 的配置管理从"重启生效"变为"热更新"。

DistSQL 的核心是"用 SQL 在线管理分片配置并热生效"。它让分片规则、数据源等可动态调整、无需重启，是 Proxy 运维灵活性的关键。

• Prepared Statement 的机制
• 代理的透传 vs 本地处理
• 参数化与性能

代理对 Prepared Statement（预处理）的处理有两种：透传（pass-through）与本地处理。透传：代理把客户端的 prepare、execute 请求直接转发给后端数据库，由后端完成 prepare 与参数绑定，代理只做透传（不解析具体参数）。这样可复用后端预编译计划，减少重复解析，性能好；但代理无法对参数做分片路由判断（因为参数在 prepare 阶段未知）。本地处理：代理在 prepare 阶段解析 SQL、确定分片路由（生成分片计划），按参数分片后将参数化的执行分发给对应后端。对分片场景，代理常采用"本地 prepare + 参数化执行"：把 prepare 的 SQL 按分片规则生成各分片的参数化语句，execute 时按参数路由。透传 vs 本地处理的权衡：透传简单、后端预编译高效，但分片路由需在 execute 时决策；本地处理可精确分片但代理需解析。代理实现上常"预编译透传 + 参数化路由"结合，保证分片正确性与执行效率。设计要点：处理好参数化、缓存分片计划、以及不同类型后端（MySQL/PostgreSQL）的协议差异。

Prepared Statement 透传的核心是"prepare 与 execute 的处理方式"。透传利于后端预编译复用，分片场景则需参数化路由，代理需权衡透传与本地处理。

• 前端连接池与后端连接池
• 连接复用与生命周期
• 会话状态约束

Proxy 管理两层连接：前端连接（客户端 → Proxy）与后端连接（Proxy → 数据库）。前端连接池：维护客户端连接，处理连接建立、认证、会话。后端连接池：维护到各后端分片库的连接，供前端连接复用，降低后端连接数。连接管理要点：1）后端连接复用：多个前端请求可复用同一后端连接（若无会话状态冲突），减少建连开销；2）连接生命周期：回收空闲连接、超时清理、处理后端连接异常（重建）；3）会话状态约束：有事务、会话变量、临时表、锁的请求不能复用后端连接（需独占），Proxy 需识别并隔离这些请求；4）连接数控制：按后端设置连接池大小，避免连接数打爆后端；5）负载均衡：后端连接按权重/健康分配到多个后端。设计要点：连接池参数（最大/最小连接数、空闲超时）、健康检查、以及"会话状态 vs 复用"的权衡。Proxy 通过连接池治理，让"应用连接数"与"后端连接数"解耦，提升连接效率与稳定性。

Proxy 连接池管理的核心是"前端/后端连接池 + 复用与隔离"。后端连接复用减连接数，但事务/会话状态需独占连接，两者需平衡。

• 联邦查询的概念
• 跨库/跨源的数据合并
• 实现与限制

联邦查询（federation query）指在一处查询能访问并合并多个数据源（多个库、多种数据库）的数据。ShardingSphere-Proxy 的联邦查询能力：当查询需要跨多个分片库或跨异构数据源（如 MySQL + PostgreSQL + 其他）时，Proxy 将该查询分解为对各数据源的子查询，分别下发执行，再在 Proxy 端合并结果（排序、去重、聚合、join）。实现：1）解析查询，识别涉及的库/表；2）按数据源分区子查询，路由到各数据源；3）收集各源结果，在 Proxy 端做合并/join/聚合。能力与限制：跨库 join 可行但代价高（需拉取数据到代理端合并，网络与内存开销大）；跨异构源需统一类型与语义；复杂查询（子查询、复杂 join）可能无法完全下推。联邦查询适合"少量跨源数据关联、低频确权/汇总"场景，不适合高频大表 join。设计要点：联邦查询的合并逻辑在代理端，性能受限于数据量与并行度，应尽量下推过滤与聚合，减少代理端处理。

联邦查询的核心是"分解 + 下发 + 合并"。代理把跨库查询拆成分源子查询、并行执行、再合并结果，能力有限且代价高，适合低频跨源汇总。

• 代理层限流（QPS/并发）
• 熔断（后端故障/过载）
• 与后端保护联动

数据库代理的限流与熔断用于保护后端数据库：1）限流：按用户、库、SQL（digest）、IP 等维度设置 QPS/并发上限，超限则排队或拒绝，防止突发流量打爆后端；代理可基于"流量整形"平滑突发。2）熔断：当后端数据库过载、故障或响应超时达阈值时，代理熔断（快速失败）该后端的请求，避免请求堆积拖垮后端与代理；熔断后周期探测恢复，恢复后逐步放量。3）与后端资源保护联动：代理监控后端健康（连接数、延迟、错误率），据此动态调整限流/熔断策略（如后端连接到达上限前提前限流、后端延迟升高时触发熔断）；代理的限流/熔断是"前端保护"，后端的连接池、慢查询、资源监控是"后端保护"，两者联动形成端到端保护。配置要点：限流/熔断阈值要合理（过低会误伤正常流量，过高防不住过载）、熔断恢复要平滑（半开状态逐步放量）、监控与告警配合。代理通过限流/熔断把"后端过载风险"在入口拦截，避免连锁故障。

限流防"突发超量"，熔断防"后端过载/故障"。代理基于后端健康联动调整策略，形成"前端入口保护 + 后端资源保护"的端到端防护。

• 异构数据源统一接入
• 统一查询与协议
• 屏蔽差异

Proxy 可将异构数据源（MySQL、PostgreSQL、Oracle、SQL Server、甚至 NoSQL 等）统一接入，价值在于：1）统一接入入口：应用通过一个 Proxy 连接（统一协议/地址）访问多个异构数据源，屏蔽各数据源的差异（协议、驱动、地址）；2）统一查询语义：应用用统一 SQL 查询，Proxy 做语法/语义适配，把查询改写为各源可执行的语句；3）统一治理：对异构源统一做权限、审计、限流、监控、路由；4）降低改造成本：多语言/多数据源应用无需分别适配，通过 Proxy 统一接入。实现：Proxy 提供统一协议（如 MySQL 协议），内部维护各数据源连接与方言适配，路由查询到正确源并合并结果。价值体现：异构改造（迁移、混合架构）、多租户统一接入、数据统一报表。代价：Proxy 需适配各源方言与类型，异构查询/join 受限，性能开销更大。设计上，异构统一接入适合"多源并存、统一入口、统一治理"的场景。

异构统一接入的价值是"用统一入口/协议/治理屏蔽数据源差异"。它让多源应用统一接入、统一治理，但需方言适配且异构 join 受限。

• 代理层权限模型（用户/角色/库表）
• 审计日志设计
• 访问控制边界

代理层权限模型：在代理层建立用户（或映射到后端用户），定义用户可访问的库、表、以及可执行的 SQL 类型（SELECT/INSERT/UPDATE/DELETE/DDL），实现"在代理层统一鉴权"，可覆盖后端权限的粗粒度或补充细粒度控制。审计日志设计：记录查询的 SQL、来源、用户、时间、目标库表、耗时、影响行数、是否命中脱敏等，支持安全审计与追踪；敏感操作（DDL、跨库、全表扫描）单独审计；审计日志需安全存储、防篡改、可检索。访问控制边界界定：代理层是"应用访问数据库的统一入口"，其边界是"在代理层支持的应用访问控制 + 审计"，但后端数据库本身的权限（如用户、表级权限、存储过程权限）仍由数据库管理，代理与后端权限需协同（代理不能绕过后端权限，反之亦然）。设计要点：代理层权限与后端权限职责划分（哪些在代理层管控、哪些在后端管控）、权限最小化、审计完整性、以及代理层鉴权失败的错误处理。代理层化的权限/审计是"数据库访问安全中台"的落地。

代理层权限/审计的核心是"在统一入口做集中鉴权与审计"。边界在于：代理管控应用层访问与审计，后端管控数据库内部权限，二者协同、避免绕过。

• 连接复用的原理
• 后端连接数减少
• 对后端资源的影响

代理层的连接复用（multiplexing）让"多个前端（客户端）连接共享少量后端连接"：客户端连接代理，代理在后端连接池中复用连接服务不同请求，从而把"应用连接数"与"后端连接数"解耦，显著降低后端连接总数。原理：1）客户端连接池连接代理，代理维护一个后端连接池；2）前端请求按需分配到可用的后端连接，请求完成后连接回到池中供其他客户端复用；3）对无会话状态（无事务、无会话变量、无临时表）的请求可复用同一后端连接。收益：后端连接数大幅降低（否则每应用实例多连接会打爆后端连接上限）、减少建连开销、提升后端稳定性。约束：事务/会话状态请求需独占连接（不能复用），代理会为这类请求分配独立连接并隔离。设计上，连接复用需权衡"复用率"与"会话隔离"，通过配置（如每用户最大连接、复用策略）控制。对高并发、多租户场景，连接复用是保护后端连接的关键。

连接复用的核心是"前端/后端连接解耦，共享后端连接池"。复用降低后端连接数、减少建连开销，但事务/会话状态需独占连接，需权衡。

• 每连接一线程 vs 线程池
• 线程模型对吞吐的影响
• 高吞吐设计

代理的线程模型决定其并发处理能力与吞吐。常见模型：1）每连接一带线程（thread-per-connection）：每个客户端连接分配一个线程，实现简单、隔离性好，但连接数多时线程数暴涨，上下文切换开销大，吞吐受限；2）线程池（thread pool）：连接与执行线程解耦，连接事件（读/写）交给线程池中的工作线程处理，线程数受控，避免线程爆炸，适合高并发；3）事件驱动/异步（基于事件循环、非阻塞 IO，如 Netty）：用少量线程处理大量连接的 IO 事件，异步处理，吞吐高、资源占用低，是现代代理（如 ShardingSphere-Proxy 采用 Netty）的主流。吞吐与线程模型的关系：线程数过多导致上下文切换与缓存失效，过少则无法利用多核；事件驱动 + 固定线程池能高效利用多核、处理大量长连接。设计要点：线程池大小（如 CPU 核数的倍数）、阻塞操作（如后端同步 IO）是否阻塞线程、监控线程与队列。代理的吞吐 = 事件驱动/异步 IO + 合理线程池 + 流水线化处理。

线程模型的核心是"如何处理并发连接与任务"。事件驱动异步 + 受控线程池避免"每连接一线程"的线程爆炸，提升高并发吞吐。

• 事务边界的识别（BEGIN/COMMIT）
• 会话状态的保持（变量、临时表）
• 连接复用与状态隔离

代理需要正确处理事务边界与会话状态，以保证正确性：1）事务边界：代理识别 BEGIN/START TRANSACTION、COMMIT、ROLLBACK 等语句，标记请求处于事务中；事务期间的所有请求必须保持在同一后端连接上（不能复用给其他客户端），直到事务结束；事务跨库/跨分片时，代理需协调各分片的事务（分布式事务，如 XA、两阶段提交）。2）会话状态：SET 会话变量、临时表、USE、锁、LAST_INSERT_ID 等会话级状态，绑定到特定后端连接；代理需识别这些语句，保持连接与会话状态一致，防止复用导致状态串扰。3）连接复用与状态隔离：对无状态请求可复用连接，对含事务/会话状态的请求独占连接，并在事务/会话结束后归还连接（清理状态）。设计要点：代理需解析语句识别状态影响，维护"后端连接 ↔ 会话状态"的映射，处理分布式事务的一致性与提交。正确保持事务边界与会话状态，是代理保障数据一致性的关键。

代理保持事务/会话的核心是"识别状态影响 + 绑定连接 + 隔离复用"。事务与会话状态请求需独占连接，代理需正确识别并协调分布式事务。

• 代理延迟的测量
• 开销分解（网络/解析/路由/合并）
• 排障方法

测量代理引入的延迟开销：对比"直连数据库"与"经代理"的相同查询耗时，差值即代理开销；或在代理层记录各阶段耗时（接收、解析、路由、下发、后端执行、结果合并、返回），分解代理开销。开销来源：1）网络往返（多一跳）；2）SQL 解析与分片改写；3）路由决策；4）结果合并（跨分片聚合/join）；5）连接池/线程调度。瓶颈定位排障方法：1）用代理的监控指标（QPS、延迟分位、连接数、CPU、线程池、队列）定位是代理还是后端；2）看后端执行耗时 vs 代理处理耗时，区分瓶颈在代理运算还是后端；3）用慢查询/日志分析耗时分布；4）压测（对比直连与代理）量化开销；5）针对解析/合并热点优化（如缓存分片计划、减少跨分片查询、优化连接池）；6）资源监控（CPU/内存/GC）定位代理自身瓶颈。设计要点：建立"代理端到端延迟"的分解监控，区分网络、解析、路由、后端、合并各环节，从而精确定位并优化瓶颈。

测量代理延迟的核心是"对比 + 分解"。对比直连量化总开销，分解各阶段（解析/路由/后端/合并）定位瓶颈，再针对性优化。

• 网关与 DB 代理的职责
• 分层职责划分
• 避免职责重叠

多层代理架构中，网关（API 网关/流量网关）与 DB 代理（ShardingSphere-Proxy、ProxySQL 等）职责不同，需明确划分：1）网关（网关层）：面向应用入口，负责流量治理（认证、限流、路由、灰度、负载均衡、协议转换）、安全（WAF、鉴权）、可观测（监控、日志）；它以"应用/HTTP 流量"为维度，不感知数据库；2）DB 代理（数据库层）：面向数据库访问，负责数据库语义（分片、读写分离、SQL 优化、预处理、连接池）、数据库安全（SQL 审计、脱敏、权限）、数据库治理（限流/熔断、健康检查、故障转移）。职责划分原则：网关管"应用流量与安全"，DB 代理管"数据库访问与语义"。避免重叠：网关不做数据库分片/路由（无数据库语义），DB 代理不做应用级鉴权/HTTP 路由；两者通过"应用 → 网关 → DB 代理 → 数据库"的链条分工。设计要点：明确各层职责边界、避免重复限流/鉴权造成浪费与混乱、监控要分层（网关看应用流量、代理看数据库流量）。合理分层让每层职责单一、可独立扩展。

多层级代理的核心是"职责单一、分层清晰"：网关管应用流量与安全，DB 代理管数据库语义与治理。避免重叠，各层独立扩展。

• SSL 终止（proxy 终止 TLS）
• 后端连接加密
• 安全与性能权衡

代理的 SSL 终止与后端加密涉及"双向 TLS 的职责划分"：1）SSL 终止（TLS termination）：代理在"客户端 → 代理"段终止 TLS（解密），客户端与代理之间用加密连接；代理把明文（或再加密）转发给后端。这样让代理承担证书管理与加解密，减轻后端负载（后端不做 TLS），但客户端到代理是加密的，代理到后端需另外处理。2）后端加密：为防止"代理 → 后端"段的明文泄露，代理与后端之间也启用 TLS（后端加密），即"全链路加密"（客户端→代理→后端 三段加密）。这样即使代理到后端被窃听也安全。实现：代理配置 TLS 证书（客户端段）与后端连接启用 SSL（后端段），可配置"两端都加密"。安全与性能权衡：TLS 加解密消耗 CPU（尤其握手），代理承担两段 TLS 会增大 CPU 开销；但全链路加密保障数据在途安全。设计要点：按合规与安全要求决定是否全链路加密；代理证书管理（轮换、SSRF/信任链）；对性能敏感场景可只在敏感段启用 TLS。代理的 SSL 终止与后端加密是"数据在途安全"的落地。

代理 SSL 的核心是"分段 TLS 职责"：终止客户端段 TLS 承担加解密，后端段再加密实现全链路安全。权衡是 CPU 成本与安全性。

• 主库探活机制
• 自动切流（failover 路由）
• 与后端切换协同

代理层的主库探活与自动切流：1）探活：代理定期探测主库健康（如 SELECT 1、ping、检查复制状态），记录主库状态（健康/故障）；探活参数（间隔、超时、失败阈值）影响故障判定速度与误判风险。2）自动切流：当检测到主库故障，代理停止把写流量路由到旧主，自动切换到新主（failover）；若配合后端切换（如从库提升为主），代理需感知新主并更新路由（写路由到新主、读路由更新）。3）切换流程：探活失败 → 标记旧主不可用 → 触发切换/等待后端 failover → 更新主机组路由 → 把写流量切到新主 → 恢复后重新纳入。4）与后端协同：代理的切流依赖后端（如 MySQL 主从切换、MGR、Operator）完成"数据层面"的切换，代理负责"路由层面"的切换；两者需同步（先后端切主，再代理切流）。设计要点：探活要准（避免误判导致抖动）、切流要平滑（配合排空/预热防雪崩）、切流后要验证新主可写。代理层的主库探活与自动切流是"路由层故障转移"的关键。

代理层切流的本质是"探活 + 路由切换"。探活判定主库故障，切流把写流量路由到新主，与后端数据层切换协同完成故障转移。

• 读流量权重分发
• 主从延迟与读一致性
• 读路由决策

代理层读流量按权重分发：为每个从库配置权重（如从库 A 权重 3、B 权重 1），代理按权重比例把读请求分发到各从库，实现读负载均衡（如 write_weight/read_weight 或主机组权重）。实现：代理按权重随机/轮询选择从库，加权负载均衡。主从延迟下的读路由决策：核心是"读一致性"与"延迟容忍"的权衡。1）主从延迟感知：代理定期检查从库复制延迟（Seconds_Behind_Master 或 PG 复制延迟），延迟超过阈值的从库从读路由摘除（避免读到过期数据）；2）读一致性分级：对"强一致读"（如刚写后读自己）路由到主库，对"可容忍延迟读"路由到从库；3）延迟敏感查询：可按规则（如特定表、特定用户）把读路由到主库保证一致性；4）动态权重：根据从库延迟/负载动态调整权重。决策要点：权衡"读负载均衡"与"读一致性"，对延迟敏感数据读主、对其他读从库，并用延迟阈值摘除滞后从库。主从延迟下的读路由是"读写分离的正确性保障"。

读权重分发解决"读负载均衡"，主从延迟感知解决"读一致性"。按延迟阈值摘除滞后从库、按查询分级路由（强一致读主），是正确读路由的关键。

• 慢查询拦截/限流
• 误拦截风险
• 业务影响控制

代理层慢查询拦截与限流：1）慢查询拦截：代理识别慢查询（按 SQL digest、耗时、扫描行数），对"超出阈值"或"已知高危"的查询进行拦截（拒绝执行、重路由、或告警）；2）限流：对高频慢查询/超量查询按用户、SQL、库限流，防止慢查询拖垮数据库。实现：代理解析 SQL、记录耗时与资源使用，按规则（慢查询阈值、某 SQL 的频率）触发拦截/限流。误拦截与业务影响控制：1）误拦截风险——拦截规则过严会误伤正常业务（如把"本来就慢但必需"的查询拦掉），需精确配置（白名单、按用户/表细分）；2）业务影响控制——拦截应"可回退、可观察、可调"，先告警后拦截、渐进式（如先限流再拦截）、对核心业务放行；3）兜底——拦截规则错误时能快速关闭，避免影响扩大；4）压测验证——发布拦截规则前压测，确认不误伤。设计要点：拦截规则要有"观测 → 告警 → 限流 → 拦截"的渐进路径，配白名单与灰度，确保业务不因误拦截而中断。代理的慢查询治理是"保护数据库 + 保护业务"的平衡。

慢查询拦截/限流的核心是"保护数据库"，但必须控制误伤业务。通过渐进式策略（先告警后拦截）、白名单、可回退与压测，实现"有效治理 + 不误伤"。

• 单元化架构
• 代理的路由角色
• 单元路由与数据一致性

单元化（异地多活）架构把业务按"单元"（如同城/异地多活单元）划分，每个单元有独立的数据与流量，实现隔离与多活。代理在单元化中的路由：1）单元路由：代理根据请求的特征（如用户 ID、租户编码、路由键）把请求路由到对应单元（该单元的主/库），实现"流量随数据走"；2）单元标识：请求携带或代理计算单元标签（如用户 ID 哈希到单元），路由到该单元的数据源；3）单元隔离：各单元数据独立，代理确保跨单元访问受限（大部分流量单元内闭环），跨单元仅限特定场景（如全局数据）；4）多活切换：单元故障时，代理把流量整体切到其他单元（容灾切换），并处理数据同步（如单元间复制）。实现：代理基于路由键（如分片键）映射到单元 + 单元内的分片，两级路由；配合单元级数据复制与全局唯一标识。设计要点：路由键的选择要保证单元内数据自洽、跨单元流量可控、切换时的一致性（同步复制或异步复制权衡）。代理在单元化中承担"应用 → 单元 → 数据"的路由中枢，是异地多活的关键。

单元化路由的核心是"按路由键把流量与数据路由到对应单元"。代理做"单元 + 分片"两级路由，配合单元数据复制与容灾切换，实现多活。

• 代理故障的影响
• 高可用部署与快速摘除
• 容灾与降级

代理故障对应用的影响：代理是"应用访问数据库的统一入口"，若代理故障，所有经代理的数据库访问中断，导致应用不可用（单点故障）。影响程度取决于代理部署方式（单点 vs 高可用集群）。快速摘除与缓解：1）高可用部署：代理本身多实例（集群、负载均衡后端），单个代理故障时流量快速切换到健康的代理实例，避免单点；2）快速摘除：通过负载均衡/健康检查，检测到代理实例故障后快速从服务池摘除，避免请求打到故障实例；3）应用降级：应用可配置"代理故障时直连数据库"的降级路径（绕过代理），保证核心可用；4）代理无状态化：代理尽量无状态/可水平扩展，故障时快速重建；5）监控与告警：监测代理健康，故障快速告警与自动重启。设计要点：代理要避免成为单点（多副本 + 健康检查 + 摘除），应用要有降级与重试机制，代理故障的恢复时间要短。代理的可用性直接影响应用可用性，需重点保障。

代理故障影响的核心是"单点风险"。通过多副本高可用、健康检查摘除、应用降级与快速恢复，避免代理成为可用性瓶颈。

• 服务网格的概念
• 代理与 Sidecar 的职责分工
• 共存方式

服务网格（如 Istio、Linkerd）通过 Sidecar 代理（如 Envoy）实现微服务间的流量管理（负载均衡、重试、熔断、可观测、安全）。数据库代理（ShardingSphere-Proxy、ProxySQL）与 Sidecar 共存时需明确职责：1）Sidecar（服务网格）：处理"应用间 HTTP/gRPC 流量"的治理（服务发现、路由、熔断、mTLS、可观测），不感知数据库语义；2）数据库代理：处理"应用 → 数据库"的访问（分片、读写分离、SQL 优化、连接池、数据库审计），意识到数据库语义。共存方式：应用 → Sidecar（网格流量）→ 应用 → 数据库代理（数据访问）→ 数据库。职责划分：Sidecar 管应用间流量与安全，DB 代理管数据库访问与治理；两者协作时，Sidecar 的熔断/重试针对服务调用，DB 代理的限流/熔断针对数据库访问，避免重复。共存时注意：两层代理的延迟叠加（需评估）、监控分层（网格看应用流量、DB 代理看数据流量）、避免职责重叠导致的重复治理。设计上按"网格管服务、代理管数据"的分层，让各层专注。

代理与 Sidecar 共存的核心理念是"分层职责"：Sidecar 管服务间流量（HTTP/gRPC），DB 代理管数据库访问（SQL）。避免重复治理，各自专注。

• 灰度发布（分批/渐进）
• 配置热更新
• 回滚与验证

代理的灰度发布与配置热更新：1）灰度发布：代理（或代理配置）的变更采用"灰度"策略——先在部分流量/实例上验证，再逐步扩大，避免一次性全量变更带来的风险。实现：在代理集群中对部分实例（如 10% 流量）应用新配置/新版本，用流量调度（权重、金丝雀）逐步放量，观察监控指标（延迟、错误率）后再全量。2）配置热更新：代理配置（分片规则、路由、限流、用户）支持热更新（无需重启），如 ShardingSphere 的 DistSQL、ProxySQL 的 LOAD TO RUNTIME，变更即时生效。3）回滚与验证：灰度发布需支持快速回滚（遇到问题立即回退旧配置/旧版本）；每次变更前准备回滚方案，灰度中持续监控验证（错误率、延迟、功能正确性）。设计要点：灰度要有"放量比例控制 + 监控 + 自动/手动回滚"，配置热更新要保证原子性与一致性（避免部分生效），变更要有审计记录。代理的灰度发布与热更新让"运维变更"低风险、可逆、可持续。

灰度发布与配置热更新的核心是"低风险变更 + 可回滚"。灰度控制放量、热更新即时生效、回滚兜底，配合监控验证，实现安全运维。