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 实现简易路由：
- 定义两个真实数据源：
masterDataSource和slaveDataSource - 继承
AbstractRoutingDataSource，重写determineCurrentLookupKey() - 在方法中判断当前线程是否标记为“读”或“写”，常用方式包括：
– 基于 AOP 拦截 DAO 方法名（如含 “select”、“get”、“query”）
– 基于自定义注解（如@ReadOnly）
– 基于 ThreadLocal 动态设置上下文（如开启事务时设为 master）
关键细节不能漏
无论哪种方式，以下三点直接影响稳定性：
立即学习“Java免费学习笔记（深入）”；
- 主从延迟应对：从库同步有 lag，SELECT 可能读到旧数据。建议对强一致性场景（如订单创建后立即查详情）加 Hint 或注解强制走主库
-
健康检查与剔除：需配置从库心跳检测（如 ShardingSphere 的
load-balancer+health-check），自动下线延迟过大或不可用的从库 -
SQL 解析边界：某些 SELECT 语句带
FOR UPDATE或出现在事务中，必须路由到主库 —— ShardingSphere 内置识别，手写路由需显式处理
验证是否生效
上线前务必确认路由行为符合预期：
- 开启
props.sql.show=true，看日志里 SELECT 是否连的是从库地址，INSERT 是否连主库 - 用 Postman 或单元测试分别触发读/写接口，抓包或查数据库 processlist 确认连接来源
- 模拟从库宕机，观察是否自动切走、不报错，且写操作不受影响
