高并发系统设计核心精华总结
核心逻辑：高并发问题本质是 “读”“写” 压力的分配与缓解，需先按业务场景分类，再针对性用 “分流、缓存、异步、分片” 四大核心思路解决，最终通过读写分离实现高效承载。
一、先分类：高并发系统的 3 种核心场景
- 高并发读：读请求远多于写（用户多、写少、响应要求快），比如搜索引擎、电商商品详情 / 搜索。
- 高并发写：写请求密集（需实时处理、数据一致性要求高），比如广告扣费、短信发送。
- 读写双高：读写请求均密集（实时性 + 一致性要求高），比如秒杀 / 库存、支付、IM / 朋友圈。
二、高并发读：核心是 “少算、多存、快取”
核心策略：用空间换时间，减少读时计算量，多做数据冗余。
- 加缓存 / 读副本：数据库扛不住时先加缓存（本地缓存 / Redis），复杂查询用 MySQL 主从分离（Slave 分担读压力），静态资源（图片 / JS）用 CDN 加速。
- 并发读优化：无依赖的多接口调用用异步 RPC（并行执行省时间）；长尾延迟问题用 “对冲请求”（超时后重发请求，取最快结果）。
- 重写轻读：把读时的复杂计算提前到写时完成。比如微博 Feeds 流，用户发微博时异步推送给粉丝收件箱，读时直接取现成列表；多表关联查询提前生成宽表或存入搜索引擎。
- 本质：读写分离（CQRS 架构），读和写用不同数据结构，写实时更新主库，读从缓存 / 宽表 / 搜索引擎获取（最终一致性即可）。
三、高并发写：核心是 “分流、异步、批量”
核心策略：拆分压力、错峰处理，避免同步阻塞。
- 数据分片：把数据拆到多台机器 / 数据库，比如分库分表、Redis Cluster、ES 分布式索引，并行承载写压力。
- 异步化：非核心流程异步处理，主流程快速响应。比如短信验证码存入消息队列后立即返回，后台异步调用短信平台；订单支付成功后，异步拆单、通知卖家。
- 批量写：合并多次小额写操作，减少数据库交互。比如广告多次点击合并成一次扣费；MySQL 小事务合并（10 次扣 1 个合并为 1 次扣 10 个）。
- 写内存 + 日志：先写内存（如 Redis 扣库存）保证快响应，同时记录日志（WAL），避免数据丢失，后续异步同步到数据库。
四、核心总结
- 场景决定策略：读多写少侧重 “缓存 + 重写轻读”，写多侧重 “分片 + 异步”，读写双高需 “读写分离 + 实时一致性控制”。
- 四大核心思路：缓存（读加速）、分片（压力拆分）、异步（错峰解耦）、重写轻读（转移计算）。
- 一致性权衡：读场景可接受最终一致性（如商品价格延迟几秒更新），写场景（支付 / 库存）需保证实时一致性或极小延迟。