Java中JDBC层读写分离的核心是按SQL类型自动路由，主流方案为ShardingSphere-JDBC（嵌入式、无需中间件），其次可自定义AbstractRoutingDataSource；需关注主从延迟、健康检查、SQL解析边界及生效验证。

Java 中在 JDBC 层实现读写分离的基本路由，核心是让应用能根据 SQL 类型（如 SELECT 还是 INSERT/UPDATE/DELETE）自动选择主库或从库连接，而不改业务代码。最轻量、主流且无需额外服务的方式，是使用 ShardingSphere-JDBC ——它以 JAR 包形式嵌入应用，直接拦截 JDBC 调用，完成路由决策。

用 ShardingSphere-JDBC 配置读写分离

它把主从数据源封装成一个逻辑数据源，由框架自动识别 SQL 类型并分发：

• 所有 写操作（INSERT、UPDATE、DELETE、REPLACE、DDL 等）强制走主库
• 默认 读操作（SELECT）路由到从库；支持多个从库时可配置负载均衡策略（如轮询、随机）
• 事务内的读操作自动走主库，保障“写后读”一致性
• 通过 HintManager 可在代码中临时强制走主库，例如刚插入一条记录马上要查，避免从库延迟导致查不到

不依赖中间件：自定义 AbstractRoutingDataSource

若倾向完全自主控制，可用 Spring 的 AbstractRoutingDataSource 实现简易路由：

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

• 定义两个真实数据源：masterDataSource 和 slaveDataSource
• 继承 AbstractRoutingDataSource，重写 determineCurrentLookupKey()
• 在方法中判断当前线程是否标记为“读”或“写”，常用方式包括：
   – 基于 AOP 拦截 DAO 方法名（如含 “select”、“get”、“query”）
   – 基于自定义注解（如 @ReadOnly）
   – 基于 ThreadLocal 动态设置上下文（如开启事务时设为 master）

关键细节不能漏

无论哪种方式，以下三点直接影响稳定性：

• 主从延迟应对：从库同步有 lag，SELECT 可能读到旧数据。建议对强一致性场景（如订单创建后立即查详情）加 Hint 或注解强制走主库
• 健康检查与剔除：需配置从库心跳检测（如 ShardingSphere 的 load-balancer + health-check），自动下线延迟过大或不可用的从库
• SQL 解析边界：某些 SELECT 语句带 FOR UPDATE 或出现在事务中，必须路由到主库 —— ShardingSphere 内置识别，手写路由需显式处理

验证是否生效

上线前务必确认路由行为符合预期：

• 开启 props.sql.show=true，看日志里 SELECT 是否连的是从库地址，INSERT 是否连主库
• 用 Postman 或单元测试分别触发读/写接口，抓包或查数据库 processlist 确认连接来源
• 模拟从库宕机，观察是否自动切走、不报错，且写操作不受影响

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南