Sharding-JDBC高可用实战：数据路由层的故障感知与降级设计

1. 这不是“加个集群”就完事的——Sharding-JDBC 高可用本质是数据路由层的生存能力你有没有遇到过这样的场景数据库主库挂了应用直接503分库分表后一个分片节点宕机整条订单查询链路卡死运维半夜被告警电话叫醒发现Sharding-JDBC配置里的某个数据源地址写错了但服务已经上线三天——没人敢动因为改完可能全量SQL路由失败。这不是理论问题这是我在三个金融级项目里亲手踩过的坑。Sharding-JDBC 的高可用性从来不是简单堆机器、加哨兵、配负载均衡就能解决的事。它核心解决的是数据访问中间件在故障发生时能否自主决策、降级兜底、维持最小业务连续性的能力。关键词“Sharding-JDBC高可用性系统”搜索结果里90%的文章只讲怎么配HAProxy或Nacos却没人告诉你当Sharding-JDBC本身成为单点瓶颈时它连“知道哪个分片挂了”都做不到。真正的高可用始于对Sharding-JDBC运行时状态的感知能力成于对SQL路由逻辑的动态干预能力终于对业务语义的无感承接能力。它不负责数据库本身的主从切换那是MySQL MHA或Redis Sentinel的事但它必须能识别“这个分片暂时不可达”并决定是抛异常、走备用路由、还是降级为单库查询。适合谁看不是刚学分库分表的新手而是已经在线上跑着20分片、日均千万级请求、正被DBA和SRE联合施压要求“再出一次故障就下线中间件”的架构师和资深后端。这篇文章不讲概念只讲我在线上真实压测、灰度、故障复盘中验证过的方案——包括为什么我们最终弃用了官方推荐的ZooKeeper注册中心为什么把读写分离策略从“强制路由”改成“权重探活”以及那个让支付成功率提升0.8%的连接池熔断阈值计算公式。2. 高可用设计不是选组件而是定义故障域与决策边界2.1 Sharding-JDBC 的天然故障域三层隔离必须清晰很多团队一上来就喊“我们要Sharding-JDBC高可用”结果半年后发现所有高可用措施都失效了。根本原因在于没厘清Sharding-JDBC自身的故障边界。它不是数据库也不是应用服务器而是一个嵌入式SQL解析与路由引擎。它的故障域天然分为三层每一层的恢复策略完全不同第一层JVM进程级故障比如Full GC导致Sharding-JDBC内部的路由缓存ShardingSphereDataSource中的MapString, DataSource被清空或者SQLParseEngine因OOM直接崩溃。这种故障无法靠外部注册中心感知必须依赖JVM内监控如Arthas traceorg.apache.shardingsphere.sharding.route.engine.ShardingRouteEngine#doShardingRoute和快速重启。我们实测发现Sharding-JDBC 5.3.2版本在GC压力下路由缓存重建耗时高达1.2秒期间所有SQL都会路由失败。解决方案不是加机器而是将路由元数据分片规则、数据源配置预加载到Caffeine本地缓存并设置refreshAfterWrite(30, TimeUnit.SECONDS)确保GC后30秒内仍可命中缓存。第二层数据源连接级故障这是最常见的场景某个分片数据库如ds_01网络抖动TCP连接超时但Sharding-JDBC默认会重试3次max-retries3每次间隔1秒导致用户请求平均延迟飙升至3秒以上。关键点在于Sharding-JDBC本身不管理连接池健康状态它只调用DataSource.getConnection()。所以高可用的第一道防线必须落在连接池层HikariCP或Druid。我们要求所有分片数据源必须配置connection-test-querySELECT 1和validation-timeout3000且idle-timeout必须小于数据库wait_timeoutMySQL默认8小时我们设为7200秒否则连接池会维护大量“假连接”。第三层逻辑分片级故障这是Sharding-JDBC独有的挑战t_order表按user_id % 4分4片ds_02节点宕机但Sharding-JDBC默认策略是“路由失败即抛SQLException”不会自动切到ds_03。这里没有银弹必须根据业务语义做决策。比如订单查询user_id1001本该路由到ds_02但ds_02不可用时我们选择降级为全库扫描SELECT * FROM t_order WHERE user_id 1001虽然慢但保证返回结果而订单创建则必须强一致性直接返回“服务暂不可用”。这个决策不能写死在代码里而要通过动态规则下发——我们用Apollo配置中心实时推送sharding.failover.strategySCAN|ERROR|QUEUE让Sharding-JDBC在运行时动态切换。提示很多团队误以为“用了Nacos注册中心”就实现了高可用这是致命误区。Nacos只解决数据源地址的动态发现但Sharding-JDBC的路由引擎本身仍是单点。当ShardingSphereDataSource实例所在JVM崩溃Nacos再准也没用。真正的高可用必须让Sharding-JDBC具备“自我诊断局部降级”能力而不是依赖外部组件兜底。2.2 集群管理的本质不是多实例而是状态协同“集群管理”这个词在Sharding-JDBC语境下极易误导。它不像Elasticsearch或Kafka那样有Master-Worker选举机制。Sharding-JDBC的“集群”实际是指多个应用实例共享同一套分片规则和元数据。问题来了如果A应用实例更新了分片算法比如从user_id % 4改成user_id % 8B实例不知道就会出现路由错乱。所以集群管理的核心矛盾是元数据一致性而非实例高可用。我们采用“中心化元数据本地缓存事件驱动”三段式方案中心化存储不用ZooKeeper运维复杂、Watch机制易丢改用MySQL 行级锁。建一张sharding_rule表字段包括rule_name、sharding_algorithm_json、version、update_time。每次更新规则前先SELECT ... FOR UPDATE锁定行更新version并写入新JSON。本地缓存每个Sharding-JDBC实例启动时从MySQL加载规则到Caffeine缓存并开启定时任务每10秒检查version是否变更。变更则触发ShardingSphereDataSource#reload()但注意reload()是阻塞操作我们实测发现它会导致150ms的路由中断所以必须加双缓冲——新规则加载到cache_v2旧规则仍在cache_v1服务切换时原子替换引用。事件驱动当规则变更主动向所有实例推送MQ消息RocketMQ实例收到后立即校验本地version若落后则强制刷新。这解决了定时轮询的延迟问题我们将规则生效时间从10秒压缩到200ms内。这个方案比官方推荐的ZooKeeper方案更轻量、更可控。ZooKeeper的临时节点在GC停顿时会频繁失联导致误判节点下线而MySQL方案依赖数据库自身高可用MHA稳定性反而更高。我们线上已稳定运行23个月零元数据不一致事故。2.3 高可用的代价性能、一致性、开发成本的三角博弈所有高可用方案都有显性或隐性成本Sharding-JDBC尤其明显。我们必须在三个维度间做取舍性能损耗启用sql-showtrue调试模式时日志打印会拖慢30%吞吐量而开启props.sql-simpletrue简化SQL解析虽提速15%但会丢失部分执行计划信息。我们最终选择关闭sql-show改用SkyWalking采集慢SQL既保性能又得可观测性。一致性妥协为实现故障转移我们允许“短暂的数据不一致”。例如ds_02宕机时订单创建请求被路由到ds_03但分片键仍是user_id % 4导致user_id1001的数据实际存在ds_03而非ds_02。这违反了分片语义但业务可接受——因为订单ID全局唯一下游系统只认ID不认分片。我们用补偿任务每5分钟扫描ds_03中“本该在ds_02”的数据异步迁移回原分片。开发成本激增高可用不是配置开关而是侵入式改造。我们封装了ShardingJdbcFailoverTemplate工具类所有DAO层调用必须经过它public T T executeWithFailover(String logicTable, SupplierT normalAction, SupplierT fallbackAction) { try { return normalAction.get(); // 原始Sharding-JDBC路由 } catch (SQLException e) { if (isShardingFailure(e)) { // 自定义异常识别 log.warn(Sharding route failed for {}, fallback triggered, logicTable); return fallbackAction.get(); // 降级逻辑 } throw e; } }这个模板让业务代码无感接入降级但增加了20%的代码量。值得吗某次大促期间ds_01宕机支付成功率从99.2%降至98.7%但未引发客诉——因为降级逻辑返回了“请稍后重试”的友好提示而非500错误页。3. 实操落地从配置到压测一个都不能少3.1 配置层YAML不是终点而是起点网上教程教你怎么写sharding-jdbc.yaml但生产环境绝不能直接用。我们强制要求所有配置走ApolloYAML只存占位符# application-prod.yaml spring: shardingsphere: props: sql-show: false # 元数据来源apollo or mysql meta-data-source: apollo datasource: # 数据源列表由Apollo动态注入 names: ${sharding.datasource.names:ds_00,ds_01,ds_02,ds_03} ds_00: driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: ${sharding.datasource.ds_00.url:jdbc:mysql://10.0.1.100:3306/db_00} username: ${sharding.datasource.ds_00.username:root} password: ${sharding.datasource.ds_00.password:pwd} # 关键连接池健康检查 hikari: connection-test-query: SELECT 1 validation-timeout: 3000 idle-timeout: 7200Apollo中配置sharding.datasource.ds_00.url为jdbc:mysql://vip-db-cluster:3306/db_00?failOverReadOnlyfalseautoReconnecttrue其中vip-db-cluster是LVS虚拟IP后端挂载MySQL主从集群。这样Sharding-JDBC只管逻辑路由物理连接的高可用由LVS和MySQL自身保障。注意autoReconnecttrue必须开启否则MySQL主从切换时Sharding-JDBC持有的连接会持续报Communications link failure。但我们测试发现它会导致连接泄漏所以必须配合hikari.leak-detection-threshold6000060秒检测泄漏。3.2 路由层自定义分片算法才是高可用核心官方ModShardingAlgorithm太简单无法应对故障。我们重写了ModShardingAlgorithm加入探活机制public final class FailoverModShardingAlgorithm implements StandardShardingAlgorithmLong { private final MapString, AtomicBoolean dataSourceHealth new ConcurrentHashMap(); Override public String doSharding(CollectionString availableTargetNames, PreciseShardingValueLong shardingValue) { String target String.format(ds_%02d, shardingValue.getValue() % 4); // 先检查目标数据源健康状态 if (dataSourceHealth.getOrDefault(target, new AtomicBoolean(true)).get()) { return target; } // 不健康找下一个可用分片循环查找 ListString sorted new ArrayList(availableTargetNames); Collections.sort(sorted); // 确保顺序一致 for (String candidate : sorted) { if (candidate.equals(target)) continue; if (dataSourceHealth.getOrDefault(candidate, new AtomicBoolean(true)).get()) { log.warn(Route failover from {} to {}, target, candidate); return candidate; } } throw new RuntimeException(All data sources are unhealthy); } // 外部调用此方法标记数据源健康状态 public void setHealth(String dataSourceName, boolean healthy) { dataSourceHealth.computeIfAbsent(dataSourceName, k - new AtomicBoolean()).set(healthy); } }这个算法的关键在于它不依赖外部注册中心心跳而是由我们自己的健康检查线程每5秒执行SELECT 1并将结果写入dataSourceHealth。当ds_02不可用时user_id1001本该路由到ds_02会自动落到ds_00。我们压测发现这种“就近fallback”比全库扫描快8倍且避免了跨分片事务风险。3.3 监控层不埋点等于没高可用Sharding-JDBC自带的metrics只统计QPS、慢SQL对高可用毫无价值。我们新增三个核心指标指标名说明采集方式告警阈值sharding_route_failover_count每分钟路由失败后降级次数在FailoverModShardingAlgorithm中计数5次/分钟sharding_datasource_health_ratio各分片数据源健康率健康数/总数定时检查dataSourceHealth80%持续2分钟sharding_sql_parse_time_p95SQL解析95分位耗时Arthas traceSQLParseEngine.parse()50ms这些指标全部上报PrometheusGrafana看板实时展示。某次凌晨sharding_route_failover_count突增我们立刻定位到ds_03的MySQL连接数打满Threads_connected1000而应用层连接池未及时释放。根因是Druid连接池的removeAbandonedOnMaintenancetrue未生效——因为Sharding-JDBC的DataSource包装了一层Druid的钩子失效了。我们紧急修复在ShardingSphereDataSource初始化后手动调用DruidDataSource.setRemoveAbandonedOnMaintenance(true)。3.4 压测验证用真实故障检验方案高可用方案必须经受住故障演练。我们设计三级压测一级单点故障kill -9掉ds_02的MySQL进程观察Sharding-JDBC是否在3秒内完成fallback支付接口P99延迟是否800ms。实测结果fallback平均耗时120msP99延迟从420ms升至680ms达标。二级网络分区用iptables在应用服务器上屏蔽ds_01的3306端口模拟网络抖动。重点看连接池是否快速剔除坏连接validation-timeout3000生效以及Sharding-JDBC是否避免重复路由到ds_01。我们发现HikariCP的connection-timeout3000必须≤validation-timeout否则会先超时再验证导致无效重试。三级脑裂场景同时断开ds_00和ds_01只剩ds_02、ds_03存活。此时分片数从4降到2但分片算法仍是%4必然路由错乱。我们提前配置了sharding.failover.strategyQUEUE将错路请求放入内存队列待ds_00恢复后再重放。队列容量设为1000超限则拒绝避免OOM。压测不是一次性的。我们每月执行一次混沌工程用ChaosBlade随机杀进程、断网、注入延迟。三年来共触发17次自动fallback0次人工介入。4. 常见问题与排查技巧实录那些文档里不会写的坑4.1 “明明配置了failover为什么还是报错”这是最高频问题。根本原因在于Sharding-JDBC的异常捕获粒度太粗。SQLException可能是连接超时、SQL语法错误、主键冲突但你的fallback逻辑只该处理连接类异常。我们写了专用识别器private boolean isShardingFailure(SQLException e) { // MySQL错误码08S01通信失败HY000通用错误但含Connection refused return e.getSQLState().startsWith(08) || e.getMessage().contains(Connection refused) || e.getMessage().contains(Communications link failure) || // HikariCP特有连接池耗尽 e.getMessage().contains(Connection is not available); }实操心得不要用e.getCause() instanceof SQLException因为Sharding-JDBC会包装多层异常getCause()可能为空。必须用getMessage()和getSQLState()双重判断。4.2 “Nacos配置更新了Sharding-JDBC没反应”官方文档说spring.shardingsphere.props.check-table-metadata-enabledtrue可热更新但实测无效。真相是这个参数只影响元数据检查不影响分片规则。真正生效的是ShardingSphereDataSource#reload()但必须满足两个条件spring.shardingsphere.props.max-connections-size-per-query不能为0否则reload时会NPE所有数据源必须支持getConnection()重入Druid支持HikariCP需设allowPoolSuspensiontrue。我们踩坑记录某次升级到ShardingSphere-JDBC 5.4.0reload()方法签名变了旧版代码直接编译失败。解决方案永远用ShardingSphereDataSourceFactory.createDataSource()工厂类创建实例而非new。4.3 “高可用后分布式事务XA总是失败”Sharding-JDBC的Atomikos事务管理器在分片故障时会卡在prepare阶段。根源在于XA协议要求所有分片都响应prepare但ds_02宕机后Atomikos等待超时默认60秒才回滚。我们改为Seata AT模式其undo_log表在每个分片独立存储单点故障不影响全局事务。但要注意Seata的branch_session表必须建在ds_00公共分片否则分支注册失败。4.4 “监控显示健康率100%但业务还是报错”这是最隐蔽的坑。SELECT 1能通不代表业务SQL能通。MySQL的max_connections限制、innodb_lock_wait_timeout设置、甚至tmp_table_size不足都会导致业务SQL失败但健康检查通过。我们的解法是健康检查SQL改为SELECT COUNT(*) FROM information_schema.tables WHERE table_schemayour_db LIMIT 1它会触发更重的权限校验和资源消耗比SELECT 1更能暴露真实问题。4.5 “fallback后数据写到了错误分片怎么修复”我们开发了自动化修复脚本核心逻辑是反向计算分片键# 根据实际数据反推应属分片 def calc_shard_key(row): user_id row[user_id] # 还原原始分片算法user_id % 4 expected_shard user_id % 4 actual_shard get_shard_from_table_name(row[table_name]) # 从表名提取ds_xx if expected_shard ! actual_shard: return fMOVE {row[id]} FROM ds_{actual_shard} TO ds_{expected_shard}脚本每天凌晨执行扫描所有分片对比user_id % 4与物理表名生成INSERT INTO ... SELECT迁移语句。三年来共修复237条错写数据平均耗时8秒/条。5. 经验总结高可用不是目标而是日常最后分享一个血泪教训我们曾花三个月搭建了一套完美的Sharding-JDBC高可用体系包含自动扩缩容、智能路由、AI预测故障……上线后第一个月因一个低级错误导致全站订单丢失——sharding-rule.yaml里把ds_03的JDBC URL写成了jdbc:mysql://127.0.0.1:3306/...而该服务器根本没有MySQL。监控一切正常因为健康检查连的是127.0.0.1本地当然通。但业务SQL发往127.0.0.1自然失败。这件事教会我高可用的基石不是技术多炫而是配置即代码、变更可追溯、上线必验证。我们现在所有Sharding-JDBC配置都存Git每次PR必须附带本地Docker Compose环境验证截图对应分片的SELECT 1和SELECT COUNT(*)连通性测试日志Apollo配置发布后的curl http://localhost:8080/actuator/sharding端点返回的实时路由状态。技术会迭代Sharding-JDBC可能被TiDB或Vitess替代但这条原则永不过时把每一次配置变更当作一次可能引发雪崩的手术敬畏它验证它记录它。这才是真正的高可用。