在高并发、大数据量的业务场景中，单体架构的性能瓶颈会从数据库开始逐步显现，这是由硬件的物理特性决定的，而非简单的代码或配置问题。想要搭建能支撑高并发的系统，首先要找准性能瓶颈的根源，再通过合理的缓存层设计，将请求压力从数据库剥离，这是高并发优化的基础。
一、高并发下，数据库为何会成为第一个瓶颈？
对于长期 QPS 100 + 甚至几百的网站，业务数据会持续增长，单表数据量从几十万逐步攀升到几百万、上千万，即便为数据库建立了合理的索引，性能瓶颈依然会如期而至，这是高并发场景下最先出现，也最的性能卡点。
1. 索引无法解决的底层问题
索引是存储在硬盘上的文件，存在固定的大小限制。当执行数据库查询时，流程并非直接读取数据，而是先将索引文件加载到内存，再根据索引的指向，从硬盘中读取对应的数据行 ，整个过程的每一步，都完全依赖磁盘 IO操作。
2. 磁盘 IO 的物理传输上限
数据从硬盘到内存的传输，需要通过硬件总线完成，而这条传输通道存在不可突破的物理带宽上限。这是硬件层面的硬限制，无论怎么优化索引、调整数据库配置，都无法改变这一事实。
当系统并发达到几百 QPS，且单表数据量迈入千万级时，硬盘到内存的传输通道会被直接打满，数据库的处理速度会瞬间下降。这也是为什么说：并发到几百的时候，最先卡住的一定是数据库。
二、缓存层设计
在数据库前增加缓存层，思路就是将高频访问的热点数据 存储在内存中，让请求优先访问内存中的缓存数据，避开磁盘 IO 的慢速度，从根源上减少数据库的访问次数。缓存主要分为本地缓存 和Redis 缓存两种，二者各有优劣，需根据业务场景针对性选择。
1. 本地缓存：性能最快的 "单机解决方案"
本地缓存是部署在应用服务器本地的缓存，以 Java 技术栈为例，是高并发场景下单机服务的最优缓存选择。
- 实现方式 ：两种主流方式，一是直接通过
static HashMap实现，将热点数据存储在静态哈希表中，所有线程可共享访问；二是使用MemberCache等专用库，其底层本质也是 Map 结构，封装了更完善的缓存操作逻辑。 - 优势 ：性能是所有缓存方案中最快的。因为本地缓存的数据直接存储在当前服务器的内存中，请求访问时无任何网络传输开销，数据读取直接在内存中完成，延迟极低。
- 明显缺点 ：
- 占用当前应用服务器的内存资源，缓存数据量受服务器内存大小限制
- 无法跨服务器共享，这是本地缓存的致命问题。在集群环境下，每台服务器的本地缓存相互独立，易出现数据不一致的情况，比如 A 服务器更新了数据，B 服务器的本地缓存仍为旧数据。
- 适用场景：单台服务器部署、并发量 1000 以内的业务场景，无跨节点的数据共享需求，追求极致的单机访问性能。
2. Redis 缓存：分布式场景的 "统一缓存层"
Redis 是一款纯内存的键值数据库，也是分布式高并发系统中最常用的缓存中间件，完美解决了本地缓存无法跨节点共享的问题。
- 实现方式：独立部署为专门的 Redis 服务器，与应用服务器分离，所有应用服务器均可通过内网访问，底层同样基于 Map 结构，支持丰富的缓存操作指令。
- 优势 ：
- 支持分布式共享，所有应用服务器访问同一套 Redis 缓存，从根本上解决了集群环境下的缓存一致性问题
- 抗并发能力强，能作为整个系统的统一缓存层，拦截大部分数据库请求
- 相比数据库，性能提升显著，且支持持久化、过期策略等丰富功能。
- 局限性 ：
- 基于内存存储，容量有限，适合存储热点数据，几十万条数据完全无压力，若要存储几百万条则需要扩容 Redis 服务器的内存
- 存在网络 IO 开销，因为应用服务器需要通过内网访问 Redis 服务器，相比本地缓存，性能略有下降。
- 适用场景：分布式集群部署、并发量上千甚至上万的业务场景，需要统一的缓存层保证数据一致性，是高并发系统的主流缓存选择。
3. Redis 不能部署在公网
Redis 本身没有严格的权限体系，默认配置下安全性极低，一旦暴露在公网，极易被黑客攻击、植入挖矿程序甚至直接删库，造成不可挽回的损失。
生产环境中 Redis 的正确部署方式：内网专属部署 + 防火墙限制访问 + 复杂密码验证 + 服务器 IP 白名单，四重保障，确保 Redis 的访问安全。
三、内存与磁盘的性能差距
缓存之所以能大幅提升系统性能，原因是内存与磁盘的访问速度存在天壤之别，这也是 Redis 相比数据库性能优势的根本来源。
1. 速度量级的差异
- 内存（Redis） ：与 CPU 的交互是纳秒级，普通操作仅需几十纳秒，复杂操作也仅上百纳秒，纯内存操作几乎无延迟
- 磁盘（数据库） ：数据访问是毫秒级，常规读取至少需要 5 毫秒，若读取大文件，耗时可达几百毫秒甚至 1 秒
1 毫秒 = 100 万纳秒 ，仅 5 毫秒的磁盘访问，就相当于 500 万纳秒，与内存的几十纳秒相比，理论性能差距达上万倍，甚至百万倍。
2. 实际性能差距：为何 Redis 仅比数据库快 10~100 倍？
为什么实际使用中 Redis 仅比数据库快 10~100 倍？原因是网络 IO 开销的存在。
在分布式架构中，应用服务器访问 Redis 和数据库，都需要通过内网传输，内网的单次请求往返耗时约1 毫秒，这是固定的网络开销：
- Redis 侧 ：内网传输 1 毫秒，Redis 自身的纯内存处理耗时仅几十纳秒，可忽略不计，总耗时约 1 毫秒
- 数据库侧 ：内网传输 1 毫秒，数据库需要进行磁盘 IO + 内存处理，耗时约 30 毫秒，总耗时约 31 毫秒
正是因为网络 IO 的存在，拉平了内存与磁盘的理论性能差距，让 Redis 在实际场景中比数据库快 10~100 倍，但即便如此，这个性能提升也足以让 Redis 成为数据库的 "高效挡箭牌"。
如果是本地数据库（应用与数据库同服务器），无网络 IO 开销，Redis 的性能优势会更接近理论值，这也从侧面说明：网络传输是 Redis 性能的主要限制因素。
四、Redis 的性能优化
Redis 自身的处理能力极强，单机极限状态下可扛几万～几十万 QPS ，但如上文所说，其性能瓶颈并非自身的处理速度，而是网络 IO 传输。
1. 基础硬性优化要求
这是优化 Redis 性能的前提，也是保障 Redis 稳定运行的基础：
- 内网专属部署：如前文所述，既保证安全，也能降低网络延迟（公网延迟远高于内网）
- 加大内网带宽：网络带宽是数据传输的 "通道宽度"，带宽越大，单位时间内可传输的数据越多，能有效减少数据传输的阻塞
2. 优化手段：Pipeline 批量请求
（1）普通请求的问题
如果采用常规的循环单条请求方式，比如要处理 1 万个数据，需要向 Redis 发送 1 万次请求，每次请求都有一次网络往返，相当于1 万次网络 IO，大量的时间都消耗在网络传输上，Redis 的处理能力完全被浪费。
（2）Pipeline 批量请求的优势
Pipeline 支持一次性向 Redis 批量发送多个请求 ，比如一次性发送 300、500 甚至 1000 个请求，仅需一次网络往返，完成原本成百上千次的网络 IO 操作，大幅减少网络传输的次数。
（3）性能提升效果
使用 Pipeline 批量请求后，Redis 的网络 IO 开销会降到最低，性能能实现几百倍、几千倍甚至几万倍的提升。
3. Redis 的性能特性：处理快，传输是唯一限制
Redis 的处理速度极快，真正限制它性能的永远是网络传输，而非自身的处理能力。
Redis 的底层是纯内存的 HashMap 结构，且由 C 语言开发，直接操作内存，性能接近原生 C 语言的循环速度。比如 1 万次的加一操作，Redis 处理耗时不到 1 毫秒；而如果让数据库执行同样的操作，即便做了批处理，也需要几十毫秒甚至数秒，二者的处理能力不在一个量级。
五、单台 Redis + 数据库：
在理想条件下 ，单台 Redis + 数据库的组合，就能支撑每秒上万的并发请求，无需过度设计。
1. 单台 Redis 的性能
单台 Redis 服务器，在极限状态下可扛住每秒上万的并发请求 ，这是经过实际测试的性能基准，但这有一个前提：数据总量不大。
2. 缓存命中率
Redis 的内存容量有限，无法存储系统的全量数据，只能存储高频访问的热点数据，而缓存命中率，就是决定单台 Redis 能否支撑上万并发的因素。
- 高命中率（90%~95%）：Redis 存储了 90% 以上的热点请求数据，此时 90% 以上的请求会直接被 Redis 拦截，仅 5%~10% 的请求会落到数据库，数据库的磁盘 IO 不会被打满，整个系统能平稳支撑上万并发
- 低命中率：如果数据总量过大，Redis 无法存储足够的热点数据，缓存命中率大幅下降，大量请求会 "穿透" Redis，直接打向数据库，数据库的磁盘 IO 瓶颈会立刻显现，系统并发能力会骤降
3. 单台 Redis 的适用场景
当业务数据总量不大、缓存命中率能稳定在 90% 以上时，单台 Redis + 数据库的组合完全足够，无需搭建 Redis 集群，能以最低的架构成本，支撑每秒上万的并发请求。
只有当数据总量持续增长，缓存命中率无法保证，请求开始大量穿透 Redis 打向数据库时，才需要考虑搭建 Redis 集群，将数据分散存储，提升缓存的整体容量和命中率。