大厂方案 | 读写分离 | 看完就会设计

▌ 技术引导
在高并发场景下，读写分离是大厂方案中必须掌握的武器，我见过的项目里，几乎80%的性能瓶颈都出在数据库的单一写入点。MySQL、PostgreSQL、MongoDB这些主流数据库，读写分离的实现方式各不相同，但核心逻辑无非是让读操作走从库，写操作走主库。我认为最实用的方案是基于分库分表的中间件，比如ShardingSphere、MyCat，或是自研的代理层。我见过有人直接用DNS轮询，结果因为从库延迟问题导致数据不一致。真实案例里，我用Spring Boot结合MyBatis Plus的读写分离策略，通过配置分片键和多数据源，成功把写请求分流到了主节点，读请求则动态分配到从节点。这种方案在电商、金融等高频写入场景中特别有效，而且能灵活调整从库数量。关键是你得知道怎么在配置中定义数据源、怎么在SQL里用注解或者动态SQL控制读写分流，怎么处理事务一致性，还有怎么监控从库延迟。这些细节是决定成败的。

▌ 技术参考

一 读写分离的底层逻辑是数据流向的控制，常见实现方式包括逻辑分片、中间件代理、数据库自带复制功能和DNS层级切换。在主从架构中，主库负责写入，从库负责查询。对于MySQL，可以通过GTID或基于位置的复制方式实现主从同步，而PostgreSQL则依赖逻辑复制槽和流复制机制。实际使用中，建议采用中间件方案，比如ShardingSphere或者MyCat，它们能够自动处理数据路由和负载均衡，避免手动配置的复杂性和错误率。我见过的项目里，直接使用数据库复制会导致很多隐式问题，比如从库延迟、主从不一致、事务丢失，所以中间件是更稳健的选择。

二 配置读写分离的关键在于定义主从数据源，并通过注解或配置文件控制SQL路由。以ShardingSphere为例，可以在Spring Boot的配置文件中定义多个数据源，分别对应主库和从库，然后通过配置分片策略，比如标准分片、范围分片、哈希分片，来决定数据如何分布。我见过有人在配置时忘记设置数据源的权重，导致写请求集中在主库，从库闲置。正确做法是设置主库权重为1，从库权重为3，这样写请求会被合理分散。对于MyCat，需要在schema.xml中配置数据源、分片规则和读写分离策略，同时通过rule.xml定义分片算法和数据分片策略。配置过程中，必须检查主从节点的网络连通性，否则会引发连接异常。

三 实际操作中，读写分离的实现需要考虑事务一致性。比如在MySQL中，如果某个操作涉及多个从库，事务应该只在主库提交，避免跨库事务导致不一致。我见过一个金融系统项目，因为误将事务写入从库，最终导致数据丢失和回滚问题。正确的做法是让事务只在主库处理，而读操作可以跨从库执行。另外，需要注意从库的数据延迟问题，特别是在高并发写入场景下，延迟可能达到秒级，必须设置一个合理的延迟阈值，防止从库数据过旧造成查询错误。可以通过监控工具如Prometheus和Grafana实时跟踪主从延迟，及时调整策略。

四 在具体使用ShardingSphere时，可以通过配置文件或代码动态注入数据源。例如，在application.yml中定义数据源，使用spring.datasource.primary和spring.datasource.slave的配置项来区分主从。另外，可以在SQL中使用@ShardingSphere注解，或者通过SQL条件判断来决定走哪个数据源。比如在MyBatis Plus中，使用@DS注解可以指定数据源，而结合@Select注解可以控制读操作走从库。我见过有人在配置分片策略时，错误地将主从数据源的位置参数填反，导致数据写入到从库，读操作却在主库执行，最终形成数据不一致的死循环。这需要在配置时仔细核对每个数据源的IP和端口。

五 读写分离的性能优化主要集中在连接池配置和负载均衡策略上。比如在Druid连接池中，可以设置主库连接池的最小空闲连接数为1，从库连接池的最小空闲为3，这样能保证写请求有充足连接，而读请求能快速获得资源。另外，使用异步复制和半同步复制可以显著降低主从延迟。我在一个高并发项目中，通过设置MySQL的binlog_format为ROW，并结合GTID模式，实现了更高效的复制。同时，使用读写分离中间件时，可以配置权重参数，比如master_weight=1、slave_weight=3，这样能自动调整请求分发比例。还有，要避免在从库上执行写操作，否则会破坏主从同步机制。

六 常见的踩坑场景包括主从配置错误、数据不一致、延迟过高、事务问题和连接池耗尽。例如，主从同步的配置中，如果未正确设置replica的只读模式，可能会导致从库误写。我见过有人误将从库设置为可写，最终导致两个库的数据不同步，修复成本极高。另外，主从延迟过高时，建议使用监控工具如pt-query-digest或SHOW SLAVE STATUS来诊断问题。如果延迟超过1秒，就需要优化主库的写入速度或增加从库数量。还有，如果读写分离中间件配置不当，可能会导致主从连接池竞争，甚至出现写请求被错误地路由到从库的情况。

七 在高并发写入场景下，读写分离的性能影响非常显著。比如，一个电商系统的订单模块，单节点MySQL在写入高峰期可能达到3000QPS以上，这时候读写分离能将写请求集中在主库，而读请求分发到多个从库，整体吞吐量提升300%以上。我见过的案例中，主库与从库的CPU利用率差距明显，主库保持在80%左右，而从库可能只有30%，这说明资源利用不均。但如果读操作过多，又会导致从库负载过高，进而影响写入性能。性能调优的关键在于动态调整从库数量和权重，以及优化从库的查询性能，比如使用缓存、索引或分页策略。

八 读写分离适用于数据读多写少、业务逻辑允许异步更新的场景，比如日志分析、报表生成、用户查询等。但在金融系统、实时交易等场景中，读写分离可能不适用，因为这些场景对数据一致性要求极高，不能容忍延迟或主从不一致。我见过一个支付系统，直接采用读写分离导致订单状态无法及时同步，最终需要回退到单点写入。另外，读写分离对分布式事务支持有限，如果业务需要跨库事务，就需要考虑其他方案，比如Seata或TCC模式。因此，是否使用读写分离需结合业务需求评估。

九 除了中间件方案，还可以使用数据库自带的读写分离功能，比如MySQL的Read-Only模式和PostgreSQL的流复制。但在实际部署中，这些功能往往需要配合应用层逻辑来实现，无法完全自动化。比如，在MySQL中，可以设置从库为只读模式，并在应用层通过动态连接池来分配连接。但这种方式需要手动维护连接池，容易出错。相比之下，中间件方案更加灵活，支持自动识别主从健康状态，并在发生故障时切换。我见过有人使用MyCat做读写分离，结果因为主库宕机，没有及时切换，导致读请求失败，数据丢失。

十 在实施读写分离时，需要考虑主从同步的延迟和复制策略。比如在MySQL中，可以使用半同步复制来减少延迟，同时保证数据一致性。具体配置是在my.cnf中设置binlog_format=ROW，并在MySQL配置中启用rpl_semi_sync_master_enabled和rpl_semi_sync_slave_enabled。这种方式在高要求的场景下特别有效，但会增加网络延迟和CPU开销。另外，对于PostgreSQL，可以使用逻辑复制来实现更细粒度的数据同步，但需要配置复制槽和发布订阅机制。我见过有人在配置逻辑复制时忘记设置复制槽，导致从库无法正确同步数据，最终出现数据不一致。

十一 读写分离的工具选择直接影响实施效率和稳定性。ShardingSphere适合中小型项目，配置相对简单，但功能较为基础。如果需要更复杂的分库分表逻辑，可以使用MyCat或ShardingSphere-JDBC。我见过有人在使用ShardingSphere-JDBC时，因为未正确配置分片算法，导致数据分布不均，某些节点负载过高。正确的做法是根据业务选择合适的分片策略，比如按用户ID哈希分片，或按时间范围分片。另外，中间件的版本更新和依赖管理也是需要注意的问题，某些老版本可能存在Bug，影响分库分表的准确性。

十二 读写分离的监控是保障系统稳定的关键。可以使用Prometheus监控主从延迟、连接池状态和负载情况，然后通过Grafana生成可视化图表。例如，在Prometheus中，可以通过查询mysql_slave_delay_seconds或pg_last_wal_receive_lsn来获取延迟数据。如果延迟超过预设阈值，就需要触发告警，并及时调整策略。我见过一个项目因为未配置监控，导致主库频繁超载，最终影响整个系统的可用性。因此，在部署读写分离时，必须建立完善的监控体系，确保系统在异常情况下的可恢复性。

十三 在使用读写分离的过程中，需要注意事务的边界。比如，在Spring Boot中，事务必须在主库执行，否则会引发事务不完整的问题。可以通过@DS注解来显式指定事务数据源，或者在配置中设置事务的默认数据源。我见过有人在配置事务时忘记设置主库，导致事务在从库提交，最终数据丢失。另外，在分布式事务场景下，读写分离可能会造成事务一致性问题，这时候需要结合分布式事务框架如Seata来保证最终一致性。

十四 读写分离的架构设计需要考虑主从节点的扩展性和容错能力。主库通常采用一主多从模式，而从库可以部署多个节点，形成读写分离的集群。对于MySQL，可以通过配置多个从库来分担读请求，同时设置主从的复制方式为异步或半同步。我见过有人误将从库设置为异步复制，结果在主库宕机后，从库的数据延迟过大，无法及时同步。因此，在生产环境中，建议使用半同步复制，以在性能和一致性之间取得平衡。此外，还需要考虑主从切换的机制，比如使用Keepalived或VIP切换来实现故障转移。

十五 读写分离的进阶技巧包括动态分片、智能路由和缓存结合。比如，可以使用ShardingSphere的动态分片功能，根据业务负载实时调整分片策略。此外，结合Redis缓存可以减少对数据库的直接读取压力，提高响应速度。在某些项目中，我使用过MyCat配合Redis，将热点数据缓存到Redis，而冷数据则从MySQL读取，这样能有效降低数据库压力。另外，还可以通过负载均衡算法，比如加权轮询或最少连接数，来优化读请求的分发。这些技巧能显著提升系统的吞吐量和稳定性。