采用“缓存抗读、队列抗写、连接复用、限流兜底”的组合策略，让请求在进入数据库之前就被层层消化，而不是把压力全压在数据库上。你不需要一步到位搞微服务，先从这四招做起，大部分QPS几千的业务场景都能扛住,下面展开讲具体怎么做。
高并发下数据库读写分离怎么做？
读写分离是高并发系统里最常见的第一板斧，行业共识认为，大多数业务系统的请求比例是读多写少，有些场景读请求能占到九成，如果把所有读请求都打到主库上，主库的CPU和IO容易被拖垮，写操作也跟着变慢,所以做法是把读流量分流到从库上。
实操步骤很简单：
- 搭建主从复制：用MySQL自带的主从同步，在主库开启binlog，从库配置change master，核心命令大致是
CHANGE MASTER TO MASTER_HOST='从库IP', MASTER_USER='repl', ...;然后START SLAVE;,这一步主要是运维操作。 - 调整应用层数据源：把读操作路由到从库，写操作仍走主库，如果项目用了MyBatis，可以配置动态数据源，用AOP注解切读写，比如
@ReadOnly标注方法走从库。 - 引入数据库中间件：当从库数量变多，应用层越来越臃肿时，改用ShardingSphere或MyCat,它们能自动做读写分离和分片。
读写分离有个坑：主从延迟，用户刚提交订单，立刻刷新订单详情，结果从库还没同步到，显示“订单不存在”,应对办法有几个：
- 对强一致要求的数据，强制走主库，比如支付结果查询,直接主库读。
- 遇到延迟，短暂休眠重试,比如从库查不到时等200毫秒再查一次。
- 用半同步复制（semi-sync），确保主从至少有一个从库收到binlog才提交,能大幅降低延迟概率。
业内专家指出，读写分离能扛住的并发量取决于从库数量和延迟容忍度，不解决全部问题,但确实是起步必做项。
服务器带宽和并发量怎么算才合理？
很多人以为“并发高=带宽大”，其实不是，带宽的单位是比特，实际的HTTP请求包里不仅有业务数据，还有TCP握手开销和请求头，如果每个请求返回给客户端的数据是50KB，并发2000个，瞬间就要传约100MB的数据，按带宽算下来需要 100MB×8=800Mbps,这恐怕比一般服务器默认的5M带宽高出百倍。
所以更合理的做法是，先算清楚业务平均响应体量,公式是：
所需带宽（Mbps） ≈ 每秒请求数 × 平均响应大小（KB） × 8 ÷ 1000
举个例子，一个接口单次返回20KB数据，希望每秒支撑500个请求，那理想带宽是 500×20×8÷1000 = 80Mbps，这是纯理想值，实际还会因为TCP重传、突发峰值而更高，所以要么提高带宽,要么减小响应体。
减小响应体是性价比最高的路：
- 开启HTTP压缩，比如gzip和brotli，能将HTML、JSON压缩掉60%到70%。
- 精简字段，接口只返回前端真正需要的字段,别把整个对象图都甩出去。
- 静态资源走CDN,让业务服务器只处理动态请求。
对于国内服务器，带宽成本普遍不低，尤其BGP多线带宽更贵，很多云厂商提供按流量计费的模式，适合突发型高并发，比如你做活动，平时带宽只有5M，活动时突发到100M，按流量付费就比固定带宽省不少，选带宽时别只盯着峰值,要结合请求体量和日常运营成本综合判断。
高并发请求处理方案中缓存和队列哪个先上？
这是一个具体对比问题，答案很明确：先上缓存，再上队列，缓存解决的是“重复查询同一份数据”的问题，队列解决的是“瞬间涌入大量写请求”的问题，多数情况下，读请求对实时性的容忍度较高,缓存能带来立竿见影的效果。
缓存优先：Redis如何承接读压力
把热点数据从MySQL搬到Redis后，一次查询的耗时可能从10毫秒降到1毫秒,实际落地要注意几个点：
- 缓存key要设计合理，避免热点key集中在某个分片，比如商品详情按
product:123这样的后等号加固定前缀,再对key做哈希分散。 - 设置过期时间，别让缓存和数据库长期不一致，读多写少的场景，缓存更新用“先更新数据库，再删缓存”更稳。
- 用多级缓存：本地缓存（如Caffeine）扛最热的数据，Redis扛次级热点,数据库兜底。
队列兜底：消息队列削峰填谷
当请求量超过系统处理能力时，队列能把突刺状的流量变成平缓的曲线，常见思路是，下单请求先进Kafka或RocketMQ，后台worker慢慢消费，再写数据库,这样数据库承受的压力就平滑很多。
队列和缓存的对比关系可以这样看：
| 维度 | 缓存 | 队列 |
|---|---|---|
| 解决的核心问题 | 读重复数据 | 写突发流量 |
| 数据流向 | 先查缓存，再落库 | 先入队，再异步落库 |
| 对实时性要求 | 容忍小延迟 | 可容忍秒级延迟 |
| 典型组件 | Redis、Caffeine | Kafka、RocketMQ |
缓存和队列并不对立，一个前端页面需要读到商品信息，另外一个动作要生成订单，前者走缓存，后者走队列，实际方案顺序是：先测一下当前瓶颈在哪，如果数据库读压力大就加缓存，如果写压力大就上队列，如果两者都大,都上。
连接池、限流和熔断：细节决定成败
这三种东西不像架构那么宏大,但恰恰是高并发场景下最容易踩坑的地方。
连接池不是越大越好
很多人以为把连接池调到1000，性能就上去了，实际上数据库连接池过大，反而让数据库线程调度开销激增，行业共识认为，MySQL连接池在10到20之间即可，配合合理并发，性能最优，比如用HikariCP，spring.datasource.hikari.maximum-pool-size=15就够了，Tomcat的Connector线程数，一般CPU核数+20比较合适,用压测工具试试就知道。
限流：给突发泼盆冷水
如果系统每秒能处理2000个请求，来了5000个，直接拒绝比崩掉好得多,限流算法主流有两种：
- 令牌桶：以固定速率往桶里放令牌，请求需要令牌才能通过,允许一定突发流量。
- 漏桶：请求以固定速率漏出，无论进来多少，处理速度恒定,适合保护数据库。
在Java里面用Guava的RateLimiter即可，或者用Sentinel做细粒度限流，限流规则按接口分组，比如秒杀接口单独限流,不能让秒杀压垮后面的普通接口。
熔断：别让一个慢服务拖死全站
当下游依赖响应变慢或报错，熔断器直接打开，不再调用下游，快速失败，给调用方一个降级响应，比如返回“稍后再试”，Netflix的Hystrix虽然已停更，但Sentinel依然活跃，实操时设置好超时时间和连续失败阈值,别让线程傻等。
从请求到响应的完整优化清单
这部分给一个可以直接照做的清单,按顺序排查：
- CDN：静态资源尽量不走源站，图片、CSS、JS都交给CDN,源站只处理动态请求。
- DNS解析：多地域用户，用智能DNS分流到最近节点,减少跨地域耗时。
- Web服务器：Nginx开启keepalive、调整worker_processes等于CPU核数,把默认的1024连接数调高。
- 应用框架：用异步非阻塞模型，比如Spring WebFlux，提升单线程利用率，同步模型下,线程一阻塞就浪费了一个并发名额。
- 缓存：先查本地缓存，再查Redis，最后查数据库，缓存未命中时，做好“缓存穿透”防护，比如对空值也缓存,或用布隆过滤器挡一下。
- 数据库：索引是否覆盖高频查询？慢日志有没有异常？用
EXPLAIN看执行计划,避免全表扫描。 - 监控：Prometheus + Grafana盯住CPU、内存、TP99延迟，TP99从200毫秒涨到500毫秒,通常意味着某个资源快打满了。
这个清单不需要一步做完，结合自己的业务流量，先从最高收益的缓存和读写分离开始，比如一个电商详情页，读请求占大头，那就把商品信息缓存到Redis，再做读写分离,性能就能翻不少。
高并发请求处理常见问题解答
高并发请求怎么压测出系统的真实上限？
用工具模拟请求，比如JMeter或wrk，先设置低并发（如50）跑5分钟，观察稳定延迟；再逐步增加并发，每次翻倍，直到错误率超过1%或延迟超过500ms，这里记录的就是该系统在该硬件和代码下的极限值，压测要在独立的测试环境或低峰期进行,避免影响线上。
服务器并发量多少算高？
如果只跑数据库，几百并发就能打爆；如果前置了缓存和队列，几千并发依然平稳，判断标准不是数字，而是看请求到数据库的最终落库速率，当单库TPS稳定在1000以内，你的架构就算合格；要超过这个数,就得考虑分库分表或者分布式数据库。
高并发请求处理方案中，如何选择云服务器配置？
大原则是CPU性能优先于核数，内存大于8G，网络带宽选择按流量计费，可以参考云厂商的型号，通用型的CPU往往比突发性能型稳定，适合高并发，数据盘用SSD，日志盘另挂云盘，避免IO争抢，地域上靠近用户群体，如果主要用户在国内，就选国内服务器节点,这样延迟更低。
高并发没有万能药，但万变不离其宗：把请求挡在越前面的层级，系统就越稳，先从读写分离、带宽估算、缓存、队列这几个基础动作做起，你的服务器就能比大多数人更能扛，搞清楚了这套逻辑，以后再遇到“服务器获取数据时如何高效处理高并发请求”这种问题,你心里就有底了。