ShardingSphere-Proxy、内核与扩容

ShardingSphere-Proxy 作为独立数据库代理暴露 MySQL 或 PostgreSQL 协议，适合多语言客户端和集中治理；ShardingSphere-JDBC 少一次网络跳转，适合由 Java 团队统一升级依赖。选型取决于组织和运行成本，不是功能清单越长越好。

Table of contents

两种模式的边界

一条 SQL 的主线是解析语法、绑定元数据、按规则路由、改写逻辑表名、并发执行、归并结果。排障时沿这条链问：解析是否支持、条件是否包含分片键、路由了几个节点、改写后的 SQL 是什么、归并是否放大内存。

扩容不是修改一个数字

把 4 张表改成 8 张表后，旧数据不会自动出现在新路由位置。安全迁移通常包含：

1. 冻结规则版本并建立容量基线。
2. 创建新节点并做全量迁移。
3. 捕获迁移期间的增量变更。
4. 按主键范围校验行数、校验和与业务抽样。
5. 在短暂停写或受控双写窗口追平差异。
6. 灰度切换读流量，再切写流量。
7. 保留旧数据和回退规则，达到观察期后再清理。

双写不是天然一致：任意一边失败都会产生差异。必须有幂等写、失败队列和后台对账。

观测与回滚

为规则版本打标签，监控路由扇出、SQL 解析失败、连接池等待、归并内存和各分片倾斜。上线前从当前 ShardingSphere 参考文档核对 SQL 限制与迁移能力，不要套用旧版本属性名。

下一步

继续阅读08-10 分布式事务模式，处理一次业务跨越多个数据所有者的问题。