流量工程 · 缓存体系 · 写削峰 · CQRS · 异构存储 · 事件驱动 · 金融级稳定性设计
一、什么才是真正的“千万 QPS”？
先给出一个行业级结论：
千万 QPS 从来不是 MySQL 的能力，而是整个系统工程能力。 MySQL 在真正的千万 QPS 架构中，只承担 0.1%~1% 的请求量。
真实系统 QPS 分担比例模型：
| 层级 | 承担比例 |
|---|---|
| L1 本地缓存 | 60% ~ 80% |
| L2 Redis | 15% ~ 30% |
| L3 ES / ClickHouse | 3% ~ 5% |
| MySQL | 0.1% ~ 1% |
🔒【生产级增强说明】 如果你的 MySQL 实际 QPS 已经接近百万级，系统一定在“亚健康”状态：
- 锁冲突会指数上升
- 复制延迟无法控制
- 任何一次抖动都会导致雪崩
所以架构目标不是让 MySQL 扛住千万，而是让 MySQL 尽量无感。
二、整体架构全景总览
QPS 分流效果：
本地缓存 ≈ 70% Redis ≈ 25% ES/CH ≈ 4% MySQL ≤ 1%三、单机 MySQL 性能极限优化
目标：达到单机性能瓶颈（通常 2～10 万 QPS）
1. 硬件与 OS 优化
# 使用NVMe SSD替代SATA SSD # 内存至少128GB以上 # CPU核心数32+，开启超线程 # OS参数调优 echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf echo "net.ipv4.tcp_max_syn_backlog = 65535" >> /etc/sysctl.conf echo "vm.swappiness = 10" >> /etc/sysctl.conf🔒【生产级增强】
补充必须同时调整：
fs.file-max = 1000000 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1⚠【风险提示】 如果 file-max 和端口范围不调，大规模连接会直接触发：
- too many open files
- cannot assign requested address
2. MySQL 配置优化
# my.cnf关键配置 [mysqld] # InnoDB缓冲池（占物理内存70-80%） innodb_buffer_pool_size = 100G innodb_buffer_pool_instances = 16 # 日志优化 innodb_log_file_size = 4G innodb_log_buffer_size = 256M innodb_flush_log_at_trx_commit = 2 # 根据业务容忍度调整 # 并发配置 max_connections = 5000 thread_cache_size = 100 innodb_thread_concurrency = 0 # 禁用并发控制 # 其他优化 innodb_io_capacity = 20000 # SSD配置 innodb_flush_method = O_DIRECT🔒【生产级增强说明】
真实生产中，建议加：
skip_name_resolve = 1 performance_schema = ON innodb_print_all_deadlocks = 1用途：
| 参数 | 价值 |
|---|---|
| skipnameresolve | 防止DNS慢解析拖死连接 |
| performance_schema | 诊断锁、慢SQL |
| innodbprintall_deadlocks | 排查死锁 |
⚠【风险提示】 max_connections = 5000 只是上限，不是目标值。 实际生产推荐：
| 层级 | 推荐值 |
|---|---|
| 应用连接池 | 200~400 |
| MySQL max_connections | 500~800 |
连接越多 → 上下文切换越重 → 性能反而下降。
3. 架构与 SQL 优化
-- 1. 索引优化：覆盖索引、联合索引 CREATE INDEX idx_covering ON orders(user_id, status, created_at); -- 2. 查询优化：避免SELECT *，使用分页优化 SELECT id, name FROM users WHERE id > ? LIMIT 1000; -- 3. 分区表（MySQL 8.0+） CREATE TABLE logs ( id BIGINT AUTO_INCREMENT, created_at DATETIME, content TEXT, PRIMARY KEY (id, created_at) ) PARTITION BY RANGE COLUMNS(created_at) ( PARTITION p202401 VALUES LESS THAN ('2024-02-01'), PARTITION p202402 VALUES LESS THAN ('2024-03-01') );🔒【生产级增强】
分页查询在深分页场景要避免：
-- 错误示例（高 offset 会导致全表扫描） SELECT * FROM users LIMIT 1000000, 20;推荐写法：
SELECT id, name FROM users WHERE id > last_id ORDER BY id LIMIT 20;4. 本阶段核心结论
第一阶段不是为了“千万 QPS”， 而是为了让 MySQL 成为一个可靠、稳定、可控的底座系统。
它决定了：
- 后面所有缓存、分库、MQ 是否能跑稳
- 复制延迟是否可控
- 故障是否可恢复
第二阶段：读写分离
目标：读性能横向扩展，让 MySQL 从“单点瓶颈”变成“可扩展集群”。
🔒【生产级增强说明】
- Orchestrator：自动选主
- 中间件自动切换主从
- 目标：主库宕机 ≤ 5 秒恢复
一、复制策略选择
-- 1. 半同步复制（数据一致性要求高） INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; SET GLOBAL rpl_semi_sync_master_enabled = 1; -- 2. 并行复制（MySQL 5.7+） SET GLOBAL slave_parallel_workers = 8; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; -- 3. 多源复制（汇总多个业务库） CHANGE MASTER TO MASTER_HOST='source1', MASTER_USER='repl', MASTER_PASSWORD='pass' FOR CHANNEL 'source1';🔒【生产级增强】
建议配套参数：
slave_parallel_workers = 16 slave_parallel_type = LOGICAL_CLOCK slave_preserve_commit_orde
