1. 为什么选择ShardingSphere-JDBC当你的业务量级从几百QPS飙升到上万QPS时数据库往往会成为第一个瓶颈点。我去年负责的一个电商项目就遇到过这种情况——大促期间订单表单日数据量突破2000万条查询响应时间从50ms飙升到2秒以上。这时候就需要考虑数据层架构的横向扩展能力。ShardingSphere-JDBC作为轻量级Java框架相比中间件方案如MyCat有三大优势无代理架构直接嵌入应用进程减少网络跳转开销。实测在1000并发下比MyCat方案延迟降低40%兼容性强完美支持MySQL/PostgreSQL等主流数据库我们项目从MySQL迁移到PostgreSQL时分片配置只需改JDBC连接串功能全面除了基础的分库分表还提供读写分离支持权重负载均衡分布式事务XA/Seata数据加密敏感字段自动加解密影子库压测不影响生产数据特别适合像yudao-cloud这样已经使用Spring BootMyBatis的技术栈。我在集成时发现它和Dynamic Datasource的兼容性很好只需要调整数据源配置就能无缝切换。2. 环境准备与依赖配置2.1 版本匹配要点踩坑记录去年用Spring Boot 2.7 ShardingSphere 5.3.2时遇到事务失效问题后来发现是版本冲突。推荐组合Spring Boot 3.1.x ShardingSphere 5.4.1yudao-cloud 2.3.0实测稳定MySQL 8.0必须开启GTID复制在yudao-dependencies模块添加核心依赖注意排除冲突包!-- 主POM中声明版本 -- properties shardingsphere.version5.4.1/shardingsphere.version /properties dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version${shardingsphere.version}/version !-- 排除旧版HikariCP -- exclusions exclusion groupIdcom.zaxxer/groupId artifactIdHikariCP/artifactId /exclusion /exclusions /dependency2.2 多模块配置技巧在yudao-spring-boot-starter-mybatis中需要额外配置!-- 支持YAML配置解析 -- dependency groupIdorg.yaml/groupId artifactIdsnakeyaml/artifactId version1.33/version /dependency !-- 分布式事务支持 -- dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-transaction-xa-core/artifactId version${shardingsphere.version}/version /dependency重要提示如果项目中有多个模块使用数据源建议在根pom的dependencyManagement中统一管理版本避免ClassLoader冲突。3. 数据源与分片规则配置3.1 动态数据源切换在application-local.yaml中关键配置spring: datasource: primary: sharding # 关键指定主数据源 dynamic: druid: initial-size: 10 # 分库分表需要更大连接池 max-active: 50 sharding: driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver url: jdbc:shardingsphere:classpath:sharding-sphere-config.yaml3.2 分库分表示例以订单表order_info为例配置2库4表根据用户ID分库按订单时间分表rules: - !SHARDING tables: order_info: actualDataNodes: ds_${0..1}.order_info_${2023..2024}${1..12} databaseStrategy: standard: shardingColumn: user_id preciseAlgorithmClassName: com.xx.config.UserIdHashModAlgorithm tableStrategy: standard: shardingColumn: create_time preciseAlgorithmClassName: com.xx.config.MonthRangeAlgorithm配套的自定义分片算法public class MonthRangeAlgorithm implements StandardShardingAlgorithmLocalDateTime { Override public String doSharding(CollectionString tableNames, LocalDateTime createTime) { return order_info_ createTime.getYear() (createTime.getMonthValue() 6 ? A : B); } }避坑指南分片键选择要满足高离散度我们曾用性别作为分片键导致严重数据倾斜。建议对userId、orderId等字段做哈希取模。4. 读写分离实战4.1 主从同步检查在配置前先用SQL验证主从状态-- 主库执行 SHOW MASTER STATUS; -- 从库执行 SHOW SLAVE STATUS\G确保Slave_IO_Running和Slave_SQL_Running都是Yes且Seconds_Behind_Master04.2 负载均衡配置rules: - !READWRITE_SPLITTING dataSources: order_ds: writeDataSourceName: write readDataSourceNames: - read01 - read02 loadBalancerName: weighted_round_robin loadBalancers: weighted_round_robin: type: WEIGHT props: read01: 2 read02: 1这个配置会让读请求按2:1的比例分配到两个从库。我们在压测时发现给配置更高的从库分配更大权重可以提升整体吞吐量15%左右。5. 验证与监控5.1 集成测试要点事务测试跨分片更新要加ShardingTransactionType注解性能基准用JMeter对比分片前后的TPS异常场景模拟从库宕机验证自动剔除故障节点5.2 监控配置在Prometheus中添加抓取规则- job_name: shardingsphere metrics_path: /actuator/shardingsphere static_configs: - targets: [localhost:8080]关键监控指标shardingsphere_request_totalSQL请求量shardingsphere_latency_seconds分片延迟shardingsphere_connection_active连接池状态6. 生产环境建议灰度发布策略先对非核心表如操作日志进行分片索引优化每个分片表都需要单独建立索引历史数据迁移用ShardingSphere-Scaling工具做在线迁移连接池参数根据实际吞吐量调整maxPoolSize我们生产环境设置的是CPU核心数×2遇到过一个典型问题某次大促后发现分片表的自增ID耗尽。后来改用Snowflake算法生成分布式ID解决了这个问题。关键配置keyGenerators: snowflake: type: SNOWFLAKE props: worker-id: ${server.port} # 用端口号作为workerId整个集成过程最耗时的是分片策略的调试建议先在测试环境用影子库验证。现在我们的订单系统可以支撑每秒3万的写入查询P99稳定在80ms以内。