在上篇中，我们深挖了高并发系统的首个瓶颈------数据库磁盘IO限制，并且通过缓存层设计，把大部分热点请求拦截在数据库之外，轻松撑起上万QPS。但随着流量继续攀升，系统会迎来第二个隐形硬瓶颈：带宽物理上限。解决了带宽问题，再把后端、存储层做成分布式集群，才能打造出稳扛高并发、容错率高的生产级架构。
一、带宽到底有多容易被打满？
很多开发者只关注后端、数据库、缓存的性能，却忽略了网络带宽。当并发突破每秒万级，或是页面包含大量图片、视频、静态资源时，带宽会先于服务器算力崩溃，成为系统卡顿、超时、宕机的元凶。
1. 带宽瓶颈的底层逻辑：物理通道有上限
带宽可以理解为网络传输的"马路宽度"，单位时间内只能通过固定大小的数据。普通服务器网卡多为千兆网卡（1Gbps），换算成实际传输速度约125MB/s；就算是万兆网卡，极限传输速度也仅有1.25GB/s，这是硬件层面的硬限制，无法靠代码优化突破。
我们用一个常见场景举例：单页面加载HTML、CSS、JS以及几张配图，总大小大概5MB。当每秒有10000次请求访问这个页面时，每秒需要传输的数据量为：
5MB × 10000 = 50000MB ≈ 50GB/s
这个流量需求，远超普通服务器的网卡上限，就算把内网带宽拉满，也会直接堵死，导致用户打不开页面、接口超时，此时就算缓存、数据库性能再好，系统也无法正常运转。
2. 不同并发量级的架构分水岭
并发量不同，系统瓶颈和适配架构完全不一样，盲目升级硬件只会浪费成本，贴合量级选型才是最优解：
| 并发量级 | 瓶颈 | 适用架构 |
|---|---|---|
| 1000以内 | 单机数据库磁盘IO | 本地缓存 + 单体服务 + 数据库 |
| 1万级 | 数据库IO、单机算力 | Redis缓存 + 单体服务 + 数据库 |
| 1万+（含大量静态资源） | 带宽不足、单机算力不足 | CDN分流 + 后端集群 + 缓存集群 |
| 10万+超高并发 | 全链路单点故障 | 分布式全架构，分库分表 |
并发破万、带静态资源，必须先解决带宽问题
二、前端与网络优化：剥离流量压力，突破带宽限制
解决带宽瓶颈，不是盲目加大带宽，而是分流、剥离、就近访问，把不占后端算力的静态资源，全部转移出源服务器，让后端只处理动态业务请求。
1. CDN：解决带宽瓶颈的最优方案
CDN全称内容分发网络，是高并发场景缓解带宽压力的标配手段，几乎所有大厂网站、电商、平台都在使用。
工作原理：把前端静态资源（HTML、CSS、JS、图片、音频、视频、安装包）同步到云服务商遍布全国乃至全球的边缘节点，用户发起请求时，系统会自动分配最近的节点响应数据，不用访问源站服务器。
优势：
-
源站带宽压力骤降，甚至能降到原本的10%以下，彻底避开带宽打满的问题
-
用户访问延迟大幅降低，就近获取资源，打开网页、加载资源速度更快
-
降低源站算力消耗，不用处理静态资源请求，专心处理动态接口
CDN只适用于静态资源，动态接口（比如登录、下单、查询数据）需要实时运算，必须回源到后端服务器，不能靠CDN缓存。
2. DNS负载均衡
如果暂时没法接入CDN，或是需要分流动态请求，可以用DNS负载均衡做流量分发。
工作原理：在DNS后台，给同一个域名绑定多个服务器IP，并且配置权重比例。用户访问域名时，DNS会按照权重，把请求分配到不同的服务器上，分散单台机器的流量和算力压力。
同时可以做架构拆分：把前端静态资源单独部署在多台前端服务器，后端服务部署在独立机器，各司其职，前端扛流量，后端做业务，避免互相拖累。
3. 自建本地DNS
针对超大流量、定制化调度需求的项目，可以自建本地DNS服务器。不用依赖公网DNS，自己编写调度程序，接收请求、解析协议、手动转发流量，灵活控制分发规则，能扛住海量并发请求，适合中大型企业级项目。
三、从单机到集群
带宽问题解决后，单机后端服务就成了新瓶颈。一台服务器算力有限、内存有限，还存在宕机风险，只要一台机器挂了，整个服务就瘫痪。解决办法很直接：用Nginx做网关，搭建Tomcat集群。
1. Tomcat与Nginx：各司其职，性能天差地别
后端服务常用的两个组件，定位和性能差距极大，搭配使用才能发挥最大效能。
| 组件 | 开发语言 | 职责 | 单机极限QPS |
|---|---|---|---|
| Tomcat | Java | 执行业务逻辑，处理数据运算 | 8G内存约4万；16G及以上约10万 |
| Nginx | C语言 | 请求转发，负载均衡，静态资源托管 | 500万以上，极限可达千万 |
性能差距：Tomcat基于Java运行，依赖JVM虚拟机，还要处理复杂业务逻辑、数据库交互，内存和算力开销大；Nginx用纯C语言开发，只做请求转发，不处理业务，纯内存运转，性能接近原生机器码，是Tomcat的几十倍。
2. Nginx + Tomcat集群
把Nginx放在最前端，作为整个系统的入口网关，承接所有用户请求，再均匀分发给后端的多台Tomcat服务器，形成集群架构。
架构优势：
-
杜绝单点故障：哪怕一台Tomcat宕机，Nginx会自动把流量分给其他正常机器，服务不中断
-
水平扩容：并发量上涨时，只需多加几台Tomcat服务器，就能提升整体算力，不用重构架构
-
负载均衡：可配置权重，把更多流量分给性能更强的服务器，资源利用更合理
常规生产环境，Tomcat集群至少部署2台，业务建议3台及以上
四、分布式存储：破解海量数据瓶颈，分库分表+集群
当业务持续增长，数据量破亿、单表数据达千万级别，就算有Redis缓存，数据库依然会拖慢整个系统。单机数据库的磁盘容量、IO能力、并发处理能力都有上限，必须走向分布式存储。
1. 分库分表：减小单表体积，提速数据库查询
数据库慢，原因还是单表太大，磁盘IO读取耗时久。分库分表的目的，就是把大数据量拆碎，降低单表压力。
分库：把一个数据库里的多张表，分散到多台数据库服务器。比如把用户表、订单表、商品表分别放在不同的数据库机器上，互不争抢资源。
分表：把一张超大表，拆分成多张结构相同的小表，严格控制单表行数。常规建议单表行数控制在500万以内，如果字段多、数据体积大，还要进一步缩减行数，让单表文件控制在百兆以内，大幅提升查询和写入速度。
分库分表只是优化手段，不能完全替代缓存，依然要配合Redis使用，挡住大部分查询请求。
2. 缓存容量与高可用问题
上篇提到，单台Redis适合数据量不大、高命中率的场景。当热点数据太多，单台Redis内存不够用，或是担心单机宕机丢失缓存，就需要搭建Redis集群。
Redis集群会把数据分散存储在多台节点，扩容方便，承载的数据量、并发能力成倍提升。就算其中一台节点故障，其他节点依然能正常提供服务，不会出现缓存全盘失效的情况。
3. 主从哨兵模式：所有存储的高可用标配
不管是Redis、MySQL，还是其他中间件，只要涉及数据存储，主从哨兵模式都是保证高可用的标准方案，能实现故障自动转移，不用人工干预。
逻辑：
-
一主多从：主节点负责处理写入、修改请求，从节点同步主节点数据，负责分担查询请求
-
哨兵监控：哨兵进程实时监测主节点状态，一旦主节点宕机，立刻自动切换一台从节点为新主节点
-
数据一致：写入主节点的数据，会同步到从节点，保证数据一致性，避免丢失
这套模式不用手动编写复杂代码，通过配置就能实现，是生产环境存储层的方案。
五、高并发架构完整演进路线复盘
从简陋的单体架构，到稳扛海量流量的分布式系统，整个优化路径循序渐进，每一步都对应解决一个瓶颈：
-
单体架构：前端→后端Tomcat→数据库，适合小流量、低并发项目，瓶颈在数据库磁盘IO
-
加入缓存：Redis→数据库，拦截大部分请求，支撑上万并发，解决数据库压力
-
带宽优化：CDN/DNS分流→剥离静态资源，突破网络瓶颈
-
后端集群：Nginx+Tomcat集群，杜绝单点故障，提升算力
-
分布式存储：分库分表+缓存集群+主从哨兵，支撑海量数据与超高并发
六、要点总结
-
先解决硬件硬限制，再做软件优化：磁盘IO、带宽、网卡速度是物理上限，先靠架构分流，再调代码配置
-
缓存优先：能放缓存的数据不查数据库，热点数据常驻内存
-
单点故障：组件必须做集群，单机再强也有宕机风险
-
组件各司其职：Nginx做转发、Tomcat做业务、Redis做缓存、数据库做持久化，不混用不越界
-
按需扩容，不盲目堆砌硬件：贴合并发量级选型，避免资源浪费
高并发系统优化，从来不是追求最复杂的架构，而是精准定位瓶颈，用最低成本解决问题。从单机到分布式，从缓存到集群。
实际生产中，还要结合监控、限流、降级等手段，进一步提升系统稳定性。