部署与使用
网站并发量提升方法并不是简单地增加服务器数量。缓存可以减少重复查询和网络传输，扩容则能增加计算、连接和存储处理能力。两者解决的瓶颈不同，选错方案可能只是把压力从应用服务器转移到 Redis、数据库或网络出口。
先判断：瓶颈到底在哪里
建议先观察一次完整的高峰请求链路，至少记录应用响应时间、CPU 使用率、内存、磁盘 I/O、数据库连接数、慢查询和网络带宽。单机 CPU 长时间接近满载，通常说明计算能力不足；内存持续紧张或频繁回收，说明进程容量和缓存设置需要检查；数据库连接池耗尽，则可能是连接数、SQL 效率或事务时间的问题。
如果大量请求访问相同的商品详情、文章页面、配置文件或地区列表，且数据更新频率不高，缓存通常更有价值。若请求参数高度分散、每次都要执行复杂计算，或者写入请求占比很高，单纯增加缓存命中率往往有限。
缓存：适合消除重复工作
适用条件
- 相同资源在短时间内被大量重复读取。
- 数据允许存在几秒到数分钟的可接受延迟。
- 数据库查询或接口计算是主要耗时来源。
- 静态文件能够通过 CDN 或反向代理就近返回。
常见做法是先在应用层缓存热点查询结果，再根据数据变化速度设置过期时间。Redis 适合保存结构化结果、计数器和短期会话数据；Nginx 反向代理缓存更适合响应内容相对稳定的 GET 请求；图片、CSS 和 JavaScript 等静态资源则可考虑 CDN。缓存策略必须同时设计失效方式，涉及库存、余额、权限等数据时，不能只依赖较长的过期时间。
- 从访问日志中找出请求量高、响应慢且重复率高的接口。
- 确认数据是否允许短暂不一致，并定义缓存键、过期时间和空值处理规则。
- 先为少量热点接口启用缓存，观察命中率、源站请求量和错误率。
- 检查缓存击穿、雪崩及大对象占用内存等风险，再逐步扩大范围。
缓存的优点是改造速度通常较快，能够在不改变服务器数量的情况下减少数据库压力；缺点是会引入一致性、失效和内存管理问题。缓存命中率低于预期时，应先检查缓存键是否包含了过多变化参数，而不是盲目增加缓存容量。
扩容：适合资源上限已经明确的场景
水平扩容与垂直扩容的差异
垂直扩容是提高单台服务器的 CPU、内存、磁盘或网络规格，实施相对直接，适合应用暂时无法多实例部署，或瓶颈集中在单机资源的情况。它的局限是存在硬件规格上限，单点故障风险也不会自动消失。
水平扩容是增加应用实例，并通过负载均衡分发请求。它更适合无状态接口、读请求较多且连接可以被多个实例处理的系统。实施前要检查本地会话、上传文件、定时任务和连接池配置；如果这些状态仍保存在单机磁盘或进程内存中，新增实例可能造成登录失效、文件不可见或任务重复执行。
当数据库写入成为瓶颈时，增加应用实例未必有效。此时可先优化索引、减少无效查询、缩短事务，再评估读写分离、分库分表或提升数据库规格。扩容解决的是容量和吞吐，不能替代 SQL 优化，也不能修复错误的锁设计。
当前该选哪一个
可以用以下判断快速决策：重复读请求多、数据库读压力高，优先缓存；CPU 或连接数达到上限且请求可分散，优先水平扩容；静态资源占用带宽，优先 CDN；写入、锁等待或磁盘 I/O 已成为主要问题，则先处理数据库和存储瓶颈。
如果监控数据不完整，建议先做小范围验证，而不是同时大规模改造。对同一接口分别记录启用缓存前后的平均响应时间、P95 延迟、数据库查询量和错误率，观察时间可覆盖一个业务高峰。对于扩容，则在压力测试环境中逐步增加实例，确认负载均衡、连接池和共享存储能够正常工作。
需要远程主机资源评估、系统检查或持续运维支持时，可以了解德讯电讯是否适合当前的系统类型和响应要求；具体服务范围应在实施前确认。对已经同时存在应用、数据库和网络多重瓶颈的系统，缓存与扩容往往需要分阶段组合，而不是二选一。
实施时的优先顺序
- 建立监控，区分 CPU、内存、数据库、网络和外部依赖的耗时。
- 先修复明显的慢查询、重复请求和不必要的数据传输。
- 为稳定的热点读请求加入缓存，并设置可回滚的开关。
- 确认单机资源仍不足后，再增加应用实例或提升服务器规格。
- 上线后持续观察 P95 延迟、错误率、缓存命中率和数据库连接使用率。
常见问题
缓存是不是一定比扩容便宜？
不一定。缓存需要额外的内存、集群、失效逻辑和运维成本。只有当重复访问明显、数据适合缓存时，收益才更稳定。
增加服务器后，数据库压力会不会更大？
可能会。多个应用实例通常会创建更多数据库连接，因此扩容前要重新核算连接池、数据库最大连接数和查询效率。
缓存能解决突发流量吗？
能缓解热点读请求，但无法直接解决大量写入、复杂计算或第三方接口限流。突发流量还需要限流、排队和降级措施。
没有完整监控时应该怎么做？
先补充请求耗时、资源使用率、数据库慢查询和错误日志，再进行小范围压测。没有指标支撑时，不宜直接判断缓存或扩容更优。
归根结底，网站并发量提升方法应从瓶颈出发：重复读取优先考虑缓存，资源上限优先考虑扩容，数据库和写入问题则需要专项优化。通过监控、验证和分阶段上线，才能选择真正适合当前系统的方案。