“如果有 1000 万并发，你的系统怎么设计？”

这大概是后端面试中最经典，也最让人无语的问题之一。

作为一个在中小厂摸爬滚打多年的普通开发者，我常常看着自己负责的系统——QPS（每秒查询率）峰值不到 50，日活几千人——陷入沉思：我这辈子真的能遇到千万级并发吗？

今天我们就来戳破这个泡沫，聊聊并发的真相，以及作为普通开发者，我们真正应该关心什么。

一、 别被“并发”忽悠了

首先，我们要厘清几个被混淆的概念。

1. 网页资源多 = 并发高？

有人告诉你：“一个网页加载要请求 50 个图片、CSS、JS，如果有 1 万个人访问，那就是 50 万并发啊！”

这是典型的偷换概念。

  • CDN 的存在：现代 Web 开发，静态资源（图片、CSS、JS）通常都放在 CDN 上，根本不会打到你的后端服务器（API Server）。
  • 浏览器限制：浏览器对同一个域名的并发连接数是有限制的（通常 6-8 个）。
  • 长连接：HTTP/1.1 和 HTTP/2 复用了 TCP 连接。

所以，前端资源的请求量，跟后端服务的并发压力，完全是两码事。

2. 用户量大 = 并发高？

“我们系统有 100 万注册用户！” 听起来很吓人。
但 100 万注册用户，日活可能只有 10 万。这 10 万人分布在 24 小时内访问，平均每秒可能只有几个人在操作。

真实的并发计算：
假设日活 10 万（DAU），平均每人每天调用 100 次接口。
总请求量 = 100,000 * 100 = 10,000,000 (一千万请求/天)。
平均 QPS = 10,000,000 / (24 * 60 * 60) ≈ 115 QPS。

你看，日请求量一千万的系统，平均 QPS 也就 100 出头。一台 4核8G 的服务器跑个 Java 或 Go 服务，绰绰有余。

二、 普通开发者的真实世界

对于 99% 的公司和开发者来说，真实的并发进阶路线是这样的：

阶段一：QPS < 100（绝大多数项目）

这是常态。内部管理系统、ToB 业务、初期创业项目。
你应该关心：

  • 代码可维护性：写出人能看懂的代码，比写出高性能的代码更重要。
  • 数据库设计：范式是否合理？索引加对了没？SQL 别写太烂。
  • 业务逻辑正确性：别把钱算错了，别把数据存丢了。

阶段二：QPS 100 ~ 1000（成功的项目）

恭喜你，你的产品已经活得很好了，可能有几十万日活。
你应该关心：

  • **缓存 (Redis)**：这是解决性能问题的一号银弹。把热点数据塞进 Redis，数据库压力瞬间减半。
  • 简单的负载均衡：一台机器扛不住，就两台，前面挂个 Nginx。
  • 异步解耦：发邮件、生成报表这种慢任务，扔到消息队列（RabbitMQ/Kafka）里去慢慢跑。

阶段三：QPS 10,000+（大厂/独角兽）

这时候你才需要考虑“面试题”里的那些技术：

  • 分库分表：单表数据量过亿，读写都慢，必须拆。
  • 微服务架构：拆分服务，独立部署，互不影响。
  • 极致的熔断降级：某个服务挂了，别把整个系统拖死。

真相是： 大部分开发者，终其一生都在阶段一和阶段二之间徘徊。这不可耻，这是商业规律。

三、 拒绝“拍脑袋”：服务器配置选型指南

很多时候，比写代码更难的，是老板问你：“上线这套系统，需要几台服务器？什么配置？”

如果你直接报一个“8核16G”，老板问你“为什么不是4核8G？”，你答不上来，那就尴尬了。这里有一份基于经验的“起步配置对照表”，供你参考（以云服务器为例）：

1. 配置对照表

业务阶段 预估日活 (DAU) 应用服务器 (API) 数据库 (MySQL/PG) 缓存 (Redis) 策略建议
入门/MVP < 500 2核 2G (x1) 同机部署 同机部署 也就是常见的“99元/年”活动机。适合个人项目或验证想法，需开启 Swap。
起步期 500 ~ 5,000 2核 4G (x1) 2核 4G (独立) (可选) 与应用同机 业务正式上线，数据库独立以保证数据安全和性能。
发展期 1w ~ 5w 4核 8G (x2) 4核 16G 2核 4G (云实例) 应用做负载均衡，数据库由于吃内存，建议内存是核数的4倍。
爆发期 10w+ 8核 16G (xN) 8核 32G (主从) 4核 16G (集群) 此时瓶颈通常在数据库，需要读写分离。

2. 选型核心逻辑

  • CPU vs 内存：
    • Web 应用（Java/Go/Python）：通常是计算密集型（逻辑处理）+ IO密集型（等数据库）。2核4G 或 4核8G 是性价比最高的“黄金比例”。Java 应用因为 JVM 的存在，内存建议 4G 起步。
    • 数据库：吃内存！吃内存！吃内存！ 内存越大，缓存的索引和数据越多，速度越快。所以数据库服务器的内存通常要是 CPU 核数的 4 倍甚至更多（如 4核16G）。
  • 磁盘：
    • 别省那点钱，必须上 SSD（高效云盘/ESSD）。机械硬盘的 IOPS 会是数据库的噩梦。
  • 带宽：
    • 初期 5Mbps 足够抗住几百并发（前提是图片走 CDN）。带宽是云服务里最贵的资源，建议按量付费或者设一个较小的固定带宽，不够再加。

一句话原则：利用云的弹性，先买小的，不够随时升。 只要不是物理机托管，千万别一次性买顶配，那是给老板浪费钱。

四、 真遇到了高并发，该怎么做？

如果你运气爆棚，真的遇到了流量暴涨（比如老板突然要去央视打广告），作为普通开发者，千万别去搞什么“重构架构”、“上 Kubernetes”。

你要做的是“保命三板斧”：

  1. 扩容 (Scale Out)

    • 最快：花钱买机器。云服务器按量付费，开 10 台机器，挂在负载均衡后面。只要你的服务是无状态的（Session 存 Redis 了），这招立竿见影。

  2. 缓存 (Cache)

    • 最狠：把所有能缓存的数据全塞进 Redis。甚至可以直接做页面静态化（把动态页面生成 HTML 文件），让 Nginx 直接返回，请求都不进后端代码。

  3. 限流 (Rate Limiting)

    • 最稳：承认系统的极限。如果系统只能抗 1000 QPS，那就把第 1001 个请求直接拒绝（返回 “系统繁忙”）。
    • 保护数据库：数据库是最后一道防线，一旦数据库挂了，整个系统就完了。所以宁可拒绝用户，也不能让数据库崩盘。

五、 总结

面试官问“千万级并发”，考察的不是你有没有做过，而是你有没有眼界。他想知道你是否了解技术的天花板在哪里。

但作为普通开发者，我们在工作中：

  • 不要过度设计：为了根本不存在的“未来流量”，引入复杂的分库分表和微服务，是给自己挖坑。
  • 关注基础：SQL 优化、Redis 使用、日志监控、异常处理。把这些地基打牢，比空谈架构更有价值。

下次再有人忽悠你“网页资源多并发就高”，你可以自信地回他一句：
“那叫流量，不叫并发。我的后端很稳，因为我加了索引，还用了 Redis。”