Apache 本身不是数据库中间件，真正实现读写分离与高可用需依赖 ShardingSphere-JDBC 或 ShardingSphere-Proxy，配合主从部署；ShardingSphere-JDBC 通过 ReadwriteSplittingDataSource 自动路由 SELECT 至从库、DML 至主库，支持随机/轮询/权重负载均衡及主库熔断降级。
Apache 本身不是数据库中间件，也不直接提供读写分离功能；Java 生态中常被误称为“Apache 高可用架构”的，实际多指基于 Apache ShardingSphere（原 Sharding-JDBC）或 Apache Commons DBCP / Tomcat JDBC Pool 等组件构建的数据库访问层方案。真正实现读写分离与高可用，需依赖 ShardingSphere-JDBC 或 ShardingSphere-Proxy，配合主从数据库部署。
ShardingSphere 对读写分离的原生支持
ShardingSphere-JDBC 是轻量级 Java 框架，以 JDBC 驱动形式嵌入应用，无需代理服务即可实现 SQL 路由、读写分离和负载均衡。
- 通过
MasterSlaveDataSource（旧版）或ReadwriteSplittingDataSource（5.0+）配置主库（write）和多个从库（read），自动识别SELECT走从库，UPDATE/INSERT/DELETE走主库 - 支持多种负载均衡策略：随机（
Random）、轮询（RoundRobin）、权重（Weighted），可按从库性能差异分配读流量 - 内置主库故障自动探测与熔断机制（需配合
DatabaseDiscovery或外部健康检查），主库宕机时可临时降级为只读（需业务容忍）
高可用的关键补充：故障转移与数据一致性保障
仅靠读写分离不能解决高可用问题，必须叠加数据库层与应用层协同机制：
- MySQL 主从复制建议使用 半同步（semi-sync） 模式，降低从库延迟，避免读到过期数据
- ShardingSphere 支持 强制走主库（通过 Hint API 或 SQL 注释
/* !shardingSphere: hint: writeRouteOnly() */ SELECT ...），用于强一致性场景（如刚写完立即查） - 从库异常时，ShardingSphere 默认跳过故障节点并尝试其他从库；若全部从库不可用，可配置
readwrite-splitting.load-balancer.type=failover实现自动切回主库读取（需评估主库压力）
与连接池协同提升稳定性
ShardingSphere 底层仍依赖 JDBC 连接池。合理配置连接池能显著增强高可用表现：
立即学习“Java免费学习笔记（深入）”；
- 推荐使用 HikariCP（非 Apache 系但事实标准），开启
connection-test-query和validation-timeout，及时剔除失效连接 - 避免使用已停更的 DBCP；Tomcat JDBC Pool 可用，但需显式设置
testOnBorrow=true与validationQuery=SELECT 1 - 主库与从库应使用独立连接池配置（如不同最大连接数、超时时间），防止从库慢查询拖垮主库连接资源
不依赖 Apache 组件的轻量替代方案
若项目约束严格，不愿引入 ShardingSphere，也可基于标准 JDBC + 自定义路由实现简易读写分离：
- 封装
AbstractRoutingDataSource（Spring 提供），重写determineCurrentLookupKey()，结合 ThreadLocal 控制读/写路由 - 用 AOP 拦截 DAO 方法名（如含 “select”、“find”、“get” 前缀走从库），配合注解（
@ReadOnly）显式声明 - 缺点：无自动故障转移、无负载均衡、不解析 SQL 语义（如 SELECT FOR UPDATE 会被误判为只读），仅适合低复杂度场景
