云服务器
针对“高并发场景下支持 10 万日活（DAU）”的 Nginx + MySQL 架构选型，首先需要明确一个核心概念：10 万 DAU 在技术界属于中小规模流量，通常被称为“入门级高并发”。
如果处理得当，单机甚至双机即可承载；但如果业务逻辑复杂（如大量实时计算、频繁写操作），则可能需要集群。以下从流量估算、架构分层、硬件选型及关键优化策略四个维度提供详细方案。
一、流量与负载估算（基准分析）
在选型前，必须先量化需求。假设 10 万 DAU 的分布特征如下：
- 活跃时段：通常集中在早晚高峰，峰值 QPS（每秒查询数）可能是日均值的 5-10 倍。
- 用户行为：假设人均每日访问 20 次页面，总 PV 约 200 万/天。
- QPS 估算：
- 平均 QPS ≈ 200 万 / (86400 秒) ≈ 23 QPS。
- 峰值 QPS（按 10 倍系数）≈ 200~300 QPS。
- 读/写比例：通常为 9:1 或 10:1。
结论：对于纯静态资源或简单 API，单台高性能服务器即可轻松应对；瓶颈通常不在带宽或 CPU，而在数据库连接数、慢 SQL 或缓存穿透。
二、架构选型方案
根据成本预算和扩展性要求，推荐两种主流方案：
方案 A：极简高可用版（推荐起步）
适合初创团队、MVP 阶段或业务逻辑不复杂的场景。
- Nginx 层：部署 1 台 高性能服务器（作为负载均衡器或直接对外服务）。若担心单点故障，可配合 Keepalived + VIP 做主备切换，或使用云厂商的 SLB（负载均衡）。
- MySQL 层：部署 1 台 主库（Master）。
- 注意：10 万 DAU 对数据安全性要求较高，建议开启 半同步复制（Semi-Sync） 到一台从库（Slave），或者使用云数据库（RDS）的主备版。
- 缓存层：必须引入 Redis。这是解决高并发读的核心，能拦截 90% 以上的数据库请求。
方案 B：标准集群版（稳健型）
适合业务增长快、对可用性要求极高（SLA > 99.9%）的场景。
- Nginx 层：2 台 Nginx 做 LVS/Nginx 双机热备，后端挂接多个应用服务器（Tomcat/Go/Node.js）。
- MySQL 层：
- 主从架构：1 主 2 从（读写分离）。写操作走主库，读操作从从库分流。
- 中间件：引入 MyCat 或 ShardingSphere（虽然 10 万 DAU 可能暂时不需要分库分表，但提前规划好读写分离中间件是加分项）。
- 缓存层：Redis 哨兵模式（Sentinel）或 Cluster 模式。
三、硬件配置建议
基于上述估算，以下是具体的硬件选型参考（以 Linux 环境为例）：
| 组件 | 推荐配置 (方案 A – 单机/轻量) | 推荐配置 (方案 B – 集群/稳健) | 说明 |
|---|---|---|---|
| CPU | 8 核 ~ 16 核 (Intel Xeon Gold 或 AMD EPYC) | 每节点 16 核 + | Nginx 主要吃 IO，MySQL 主要吃 CPU 进行排序/索引扫描。 |
| 内存 | 32GB ~ 64GB | 每节点 64GB+ | 关键指标。MySQL 需预留大量内存给 Buffer Pool（建议 60%-70% 物理内存）。 |
| 磁盘 | 2TB NVMe SSD (RAID 10) | 2TB NVMe SSD x2 (RAID 10) | 拒绝机械硬盘。NVMe 能显著提升随机 I/O 性能，降低延迟。 |
| 网络 | 10Gbps 内网，公网带宽按需 | 10Gbps 内网，带宽弹性伸缩 | 10 万 DAU 通常不需要超大带宽，重点在于内网低延迟。 |
| 操作系统 | CentOS 7 / Rocky Linux 8 / Ubuntu 22.04 LTS | 同上 | 保持内核参数优化（见下文）。 |
云厂商替代方案：
如果不想运维物理机，直接使用阿里云/AWS 的 RDS（MySQL）+ SLB（负载均衡）+ Redis 实例。
- 优势：自动备份、主备切换、监控完善。
- 成本：对于 10 万 DAU，云数据库的成本通常在几千元/月，性价比极高且稳定。
四、核心优化策略（比硬件更重要）
在 10 万 DAU 级别，软件调优往往比加机器更有效。
1. Nginx 优化
- Worker 进程：设置为
auto或等于 CPU 核心数。 - Keepalive：开启长连接，减少 TCP 握手开销。
- Buffer 设置：调整
proxy_buffer_size和proxy_buffers以适应大响应体。 - Gzip/Brotli：开启压缩，减少传输流量（节省带宽）。
- 限流：配置
limit_req_zone防止恶意刷接口导致雪崩。
2. MySQL 深度调优
- Buffer Pool：
innodb_buffer_pool_size设为物理内存的 60%-70%。 - 日志配置：关闭
sync_binlog=1和innodb_flush_log_at_trx_commit=1（除非X_X级强一致性要求），改为2或0以提升写入性能（牺牲少量丢数据风险换取速度）。 - 索引优化：严格执行“最左前缀原则”，避免全表扫描。
- 慢查询日志：开启
slow_query_log，定期分析并优化 Top 10 慢 SQL。 - 连接数：调整
max_connections，避免连接池耗尽。
3. Redis 缓存策略
- 热点 Key：防止单个热点 Key 击穿数据库。
- 缓存预热：系统启动时加载常用数据。
- 过期策略：合理设置 TTL，避免缓存雪崩（随机过期时间）。
4. 应用层优化
- 读写分离：代码层面区分 Master/Slave 路由。
- 异步处理：非核心业务（如发送短信、生成报表）放入消息队列（RabbitMQ/Kafka）异步处理。
- 静态资源分离：图片、CSS、JS 全部推送到 CDN，减轻源站压力。
五、总结与建议
对于 10 万 DAU 的场景：
- 不要过度设计：不需要一开始就上 K8s、分库分表或复杂的微服务架构。
- 首选方案：Nginx (1-2 台) + MySQL (主备或云 RDS) + Redis。
- 核心投入：将预算优先投入到 SSD 存储 和 内存 上，而不是盲目增加 CPU 核数。
- 监控先行：务必部署 Prometheus + Grafana 监控体系，关注 QPS、RT（响应时间）、Error Rate 和 数据库连接数。
最终决策路径：
如果是创业初期，直接购买 云服务器（ECS/RDS） 的 2 核 4G/4 核 8G 组合 + Redis 基础版，配合 CDN，即可支撑 10 万 DAU 且拥有极高的稳定性。随着业务增长，再逐步扩容为读写分离集群。