一主多从怎么设计？什么时候加从库，什么时候加缓存？
先说结论
架构演进的顺序是：单库 → 一主一从 → 一主多从 + 缓存 → 分库分表。不是一上来就要最复杂的架构，而是随着业务增长逐步演进。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
读写分离是MySQL高可用架构的基础。但很多人的认知停留在“写走主库、读走从库”这一层。面试官想听的是“什么时候该加从库、什么时候该加缓存、急了怎么办”。今天把整个架构演进路径讲清楚。
阶段一：单库→一主一从
当你发现数据库的CPU经常超80%，而且多数压力来自SELECT查询时，就该加从库了。从库承担读压力，主库专注写。
实现方式：使用数据库中间件（如ProxySQL、MyCat）或应用层代码实现读写分离。我们在元宇宙社交App用的是应用层的注解方式，简单直接。
阶段二：加缓存（Redis）
从库加到一定数量后，维护成本和复制延迟都会增加。这时候该引入Redis缓存：
适合缓存的场景： 读多写少、数据不经常变化、允许短暂不一致。比如用户主页、商品详情、热门列表。
不适合缓存的场景： 实时性要求高、数据频繁变化。比如账户余额、库存数量。
缓存不一致问题怎么处理？
这是引入缓存后最大的挑战。常见策略：
Cache Aside（旁路缓存）： 读时先读缓存，没有再读DB并写缓存。写时先写DB，再删缓存（不是更新缓存）。
读流程：读R缓存 → 命中则返回，未命中则读DB→写缓存→返回
写流程：写DB → 删缓存（不是更新，避免并发下脏数据）为什么是“删缓存”而不是“更新缓存”？因为并发场景下，两个写请求可能导致缓存和DB的值不一致。删除缓存后，下次读会重新仏DB加载最新值。
实战经验：我们的架构演进
元宇宙社交App： 一主二从 + Redis缓存。主库处理写和关键读，两个从库承担普通读，Redis承担热点数据。
出海硬件公司： 主库用AWS RDS多可用区部署，两个从库分别给业务读和数据同步（Canal从库专用，不影响业务从库）。
总结
架构演进顺序：单库→一主一从→一主多从+缓存→分库分表。加从库解决读压力，加缓存解决热点读，分库分表解决写压力和存储量。面试时按演进顺序讲，说明每个阶段的触发条件和解决的问题，就很有架构思维。
第6-10篇完结。后续将继续聊深分页优化、Online DDL踩坑、连接池配置、数据迁移、MySQL 8.0新特性等实战场景。
你们生产环境的架构是什么样的？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长