干运维这些年，我见过太多团队把 Redis 当成"内存大一点就行了"的东西，结果上线第一天晚上就出事。要么是内存算少了，跑到半夜 OOM 被系统杀掉；要么是网卡先炸，Redis 本身 CPU 才用了两成，业务方那边已经全超时了；还有一种是开了 AOF 却没算 fork 开销，一次 bgsave 直接把内存顶到物理上限。电商大促、社交热搜、游戏战力榜、票务抢票——这些场景有个共同点：读写热点极其集中，几万到几十万 QPS 全压在缓存层，缓存崩了，后面的数据库一秒内就被打穿。这篇文章不讲虚的，我把内存怎么算、带宽怎么估、持久化要不要开、主从还是集群、该租独享物理机还是直接买云 Redis，一条一条拆给你看，能代公式的给公式，能给算例的给算例。
核心结论先摆在这：
1. 内存不是按"数据量"买，是按"数据量 × 碎片余量 × 复制/持久化余量"买，实操上物理内存至少要按数据量的 1.6–2 倍预留。
2. 高并发 Redis 最先被打满的往往不是 CPU，而是网卡和内存。千兆网卡在 1KB 级别的 value 下，十万 QPS 量级就会见顶，这个量级以压测为准。
3. 纯缓存场景就该果断关掉持久化，把省下来的内存和 fork 开销还给业务；要落地的场景再谈 RDB/AOF/混合。
4. 数据量能塞进单机内存 60% 以内、QPS 在十万量级以内，主从加哨兵就够了；超过这个水位再上 Redis Cluster，别为了"显得高级"提前上分片。
5. 长期稳定跑、QPS 高、数据敏感的业务，租独享物理机（裸金属）比买同规格云 Redis 更划算，还不用担心邻居抢内存带宽。
Redis 的内存消耗从来不等于你塞进去的数据字节数。每一个键值对，除了 key 和 value 本身，还要算上字典条目、SDS 字符串头、过期时间、对象头、以及 jemalloc 分配器按 size class 向上取整带来的浪费。小 key 多的场景，这些结构开销能占到 30% 甚至更高；大 value 的场景则主要吃在 value 本身和分配器碎片上。
我常用的估算公式是这样的：
所需内存 ≈ 键数量 × 单键平均占用 × (1 + 结构开销系数) × (1 + 碎片余量) × (1 + 复制与持久化余量)
逐项解释一下：单键平均占用 = key 长度 + value 字节数，再加约 50–100 字节的基础结构开销（简单字符串类型取低值，哈希/有序集合等复合类型取高值，因为它们内部还要维护编码结构）。结构开销系数一般取 0.2–0.4，小 key 密集取高值。碎片余量取 0.2–0.3，用来吸收长期运行后的 mem_fragmentation_ratio 上升。复制与持久化余量这一项，如果开了 RDB/AOF 或者有从库，取 0.3–0.5——因为 fork 之后的写时复制（COW）会在 bgsave 期间额外吃掉一块内存，写越密集吃得越多，极端情况接近翻倍。
算完之后还有最后一道红线：maxmemory 不要设成物理内存的 100%。单机跑纯缓存、无持久化无从库，可以设到物理内存的 70–75%；开了持久化或挂着从库，建议压到 60–65%，剩下的留给 fork 的 COW 峰值、复制缓冲区和客户端输出缓冲区。这条线守不住，你迟早会见到 OOM killer 的日志。
算例一：电商商品详情缓存，5000 万键 × 平均 1KB。裸数据是 5000万 × 1KB ≈ 47.7GB。加 80 字节/键的结构开销（5000万 × 80B ≈ 3.7GB），得 51.4GB。乘 1.25 的碎片余量，得 64.3GB。再乘 1.3 的复制与持久化余量，得 83.6GB。结论：这台机器选 128G 内存，maxmemory 设 80–85G 比较稳。选 64G 的话，平时看着够用，一到 bgsave 或者全量同步就翻车。
算例二：社交用户关系缓存，2000 万键 × 平均 4KB，热点 key 需要打散。裸数据 2000万 × 4KB ≈ 76.3GB，结构开销相对占比小，取 0.15，得 87.7GB；碎片余量 1.25 得 109.6GB；复制余量 1.3 得 142.5GB。结论：上 256G 内存，或者干脆做分片——2 个分片各 128G，每个分片承担 1000 万键。顺带说一句，4KB 级别的 value 已经算偏大了，同一个 key 如果被高频读取，单键就能吃掉相当可观的一块带宽，这类 key 建议用"逻辑 key + 随机后缀"拆成 8–16 份，读的时候随机挑一份，写的时候全量更新，能把热点压力摊平。
算例三：游戏积分榜小键海量，2 亿键 × 平均 100 字节。裸数据 2亿 × 100B ≈ 18.6GB，但小键场景结构开销系数要拉到 0.4，得 26.1GB；碎片余量 1.3（小键更容易产生碎片）得 33.9GB；复制余量 1.3 得 44.1GB。结论：64G 内存勉强够，128G 更从容。这种场景最容易被低估，很多人一看"才 18G 数据"，结果 32G 的机器跑两天就满了。另外提醒一句，2 亿键这种量级，key 本身的长度一定要压缩，能用 hash 结构聚合就用 hash，或者开启 ziplist/listpack 紧凑编码，省下来的都是真金白银。
maxmemory 是必须的，不管你觉得自己内存多充裕。没设 maxmemory 的 Redis 就是一颗定时炸弹——它会一直吃内存直到系统 OOM，进程被杀，缓存全丢，然后所有流量砸到数据库上。
淘汰策略这块，选择逻辑其实很清晰：
allkeys-lru：纯缓存场景的默认答案。所有 key 一视同仁，内存满时按最近最少使用淘汰。电商商品、社交动态、排行榜这类"丢了能从数据库重建"的数据，直接用它，省心。
volatile-lru：只有设了过期时间的 key 参与淘汰，没设 TTL 的 key 不会被踢。适合那种"一部分是配置类常驻数据、一部分是临时缓存"的混合场景。代价是如果你漏给某些 key 设 TTL，它们会永久占位，直到把内存撑爆。
noeviction：内存满了不淘汰，直接返回写错误。这个策略只在你把 Redis 当"必须可靠的存储"时才用，比如某些任务队列、幂等令牌。选它之前先想清楚：业务代码能不能优雅处理写失败？处理不了就别选。
另外还有 allkeys-lfu / volatile-lfu（按访问频率淘汰），适合那种"有些 key 偶尔被扫到但长期价值低"的场景，比如爬虫去重、短时热榜。Redis 4.0 之后才有，老版本没有。
跑一段时间后去看 INFO memory 里的 mem_fragmentation_ratio，这个值是 used_memory_rss 除以 used_memory 的比值。1.0–1.5 之间算健康；长期高于 1.5 就该重视；超过 2.0 基本可以判定碎片严重或者 RSS 里有异常占用。碎片高不代表 Redis 坏了，但它意味着你花了钱买的物理内存，有一部分被分配器浪费掉了。
解决办法有两条。温和的一条是开启自动碎片整理：activedefrag yes，配合 active-defrag-ignore-bytes（比如 100mb）和 active-defrag-threshold-lower（比如 10）设个触发阈值，让 Redis 在 CPU 空闲时慢慢搬移对象。注意这会消耗额外的 CPU，别在高峰期跑满。激进的一条是重启或者主从切换后重建实例——碎片是分配器层面的历史包袱，重启能一次性清零，代价是缓存需要预热。
还有个老生常谈但确实管用的点：把 Transparent Huge Pages（THP）关掉。THP 会让 fork 的 COW 粒度从 4KB 变成 2MB，一次 bgsave 期间的内存暴涨可能被放大好几倍。同时把 vm.overcommit_memory 设成 1，避免 fork 时因为内核的启发式检查直接失败。
先给个量级概念，别当精确基准：Redis 6.x 之后开启多线程 IO（io-threads）的情况下，单个实例处理简单 GET/SET 的 QPS 大致在数万到十几万这个量级；不开多线程、纯单线程模型下通常在数万到十万量级。具体数字取决于 CPU 主频、网卡、value 大小、命令类型和客户端连接数，一切以你自己的压测为准。我给的都是"量级"而不是"数字"，因为不同业务之间差个两三倍太正常了。
但 CPU 通常不是瓶颈。真正的天花板在网卡。千兆网卡理论上限 125MB/s，扣掉协议开销，实际可用大概 110MB/s 上下。一个 1KB value 的 GET，加上请求行、RESP 协议头、返回体的额外字节，网络层大约要传 1.1–1.3KB。换算下来，千兆网卡在 1KB value 场景下，大约十万 QPS 量级就摸到顶了。这个数字不精确，但量级是对的——你按十万去规划千兆，不会差太远。
万兆网卡把这个上限抬到百万 QPS 量级，但那时候先出问题的大概率是 Redis 实例本身（单线程命令执行）或者客户端的连接处理能力。所以高并发场景的常见做法是：上万兆网卡 + 多实例分片，而不是死磕单实例性能。
big key 是带宽杀手，杀伤力远超很多人想象。举个例子：一个 value 是 1MB 的 key，哪怕每秒只被读 100 次，也就是 100MB/s 的流量——千兆网卡直接干满。换算成 QPS，1MB 的 value 只要一万次每秒就能吃光千兆。这就是为什么有些业务"QPS 才几千，网卡却跑满了"。
判断标准我在项目里一般这么定：字符串类型 value 超过 10KB 就要盯一下，超过 100KB 必须整改；哈希、列表、集合、有序集合的元素数超过 5000 就该考虑拆分。查 big key 用 redis-cli --bigkeys 扫一遍，或者用 MEMORY USAGE key 精确看单个键的占用。整改办法不外乎三种：把大对象拆成多个小 key、把大 hash 按 field 哈希拆成多个 hash、或者干脆不缓存这么大的东西（序列化成本和网络成本都不划算）。
热 key 是另一回事。某个 key 被几十万 QPS 集中访问，它的压力全落在单个实例的单个 CPU 核上，分片都救不了——因为分片是按 key 路由的，同一个 key 永远落在同一个槽。解决办法是在客户端做本地缓存（热点数据本地内存兜一层），或者用"key 打散"：写的时候把 hot:item:1001 拆成 hot:item:1001:0 到 hot:item:1001:15 共 16 份，读的时候随机取一份，读压力就摊到 16 个 key 上；如果做了分片，这 16 个 key 还能落到不同实例上。代价是更新时要写 16 次，一致性窗口变长。
pipeline 是提升吞吐最直接的手段，没有之一。原理不复杂：把 N 条命令打包成一个 TCP 往返发出去，把 N 次网络往返压缩成 1 次。单次网络往返在同城机房大概零点几毫秒，跨城可能几毫秒，在高频小命令场景下，往返时间才是主要开销，而不是 Redis 的执行时间。合理使用 pipeline（比如每次打包 50–200 条，具体条数以压测为准），吞吐提升几倍很常见。
但 pipeline 别贪多。一次塞几万条命令，Redis 会被这个连接独占处理，其他客户端的延迟立刻飙升，看起来就像"卡住了"。我一般建议单批控制在百条量级，并且客户端侧要限制并发 pipeline 的数量。
批量命令 MGET/MSET 也是同理，一次取 100 个 key 比循环 100 次 GET 快得多。不过要注意，MGET 在 Cluster 模式下如果 key 跨槽会报错或者退化成多次网络往返，需要用 hash tag 保证相关 key 落在同一个槽，或者让客户端做拆分。
这是租用环节里最实际的成本问题，也是很多人踩坑的地方。分三种情况说：
同机房内网（内网 IP 互通）：绝大多数 IDC 服务商的内网流量不单独计费，但会限制端口速率——比如给你一个千兆内网口或者万兆内网口，跑多少流量都不额外收钱，但跑不过端口速率。所以内网带宽的成本，本质上体现在"你买的机器带多大内网口、是不是独享"上。
公网出入流量：这个通常计费，或者以"带宽上限 + 不限流量"的形式打包。常见的套餐写法是"100M BGP 独享不限流量"，意思是端口速率 100Mbps，跑满也不加钱。签合同前一定要问清楚：是按 95 计费峰值算、按流量算、还是不限流量限速？跨机房、跨地域的流量是否单独计价？
云 Redis 场景：公有云的 Redis 实例，内网访问一般免费，但公网访问（为了本地调试开公网地址）往往按流量收费，而且安全风险不小。生产环境我不建议给 Redis 开公网。
租物理机做缓存时，我通常会要求内网至少万兆、公网给 100M–200M 独享，并且确认内网交换机不超售。缓存层的东西向流量（客户端到 Redis、主从复制、集群总线）远比南北向流量大，内网口给小了，后面扩容会很痛。
RDB 是快照式持久化，bgsave 会 fork 一个子进程去写快照。fork 本身在内存大时会带来明显的停顿——几百毫秒到秒级都有可能，具体取决于实例内存大小和内核版本，这个时间以实测为准。fork 之后，父子进程共享内存页，主进程继续处理写请求，被修改的页会被复制一份（写时复制，COW）。
关键风险就在这：写越密集，bgsave 期间被复制的页越多，内存峰值越高。如果业务是"全量写、写多读少"，COW 可能把内存顶到接近两倍数据量。这就是为什么前面算内存时一定要留那一块复制余量。内存留不够，bgsave 期间直接 OOM。
实践上的几条硬要求：关闭 THP；vm.overcommit_memory=1；给 Redis 留够 swap 之外的真实内存；如果单实例内存超过一定规模（比如 32G 以上），要考虑把 save 频率降下来，或者干脆把实例拆小——大实例做 bgsave 的代价远高于多个小实例。
AOF 记录每一条写命令，数据安全性比 RDB 高（最多丢一秒甚至不丢），代价是文件更大、恢复更慢、重写时同样要 fork。
fsync 策略三选一：always 每条命令都刷盘，最安全，性能损耗最大；everysec 每秒刷一次，最多丢一秒数据，是绝大多数业务的默认值；no 交给操作系统决定，最快，但宕机可能丢几十秒数据。我的建议很直接：除非业务要求绝不能丢，一律用 everysec。用 always 的场景，通常说明这块数据本来就该放数据库里。
AOF rewrite 是另一个坑点。AOF 文件会一路写入一路膨胀，Redis 会定期重写（bgrewriteaof）压缩。重写同样要 fork，同样有 COW 峰值，而且重写过程中产生的新命令还要写进重写缓冲区——这块的额外内存占用在写密集时也不小。auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 要按实际写入量调，别让它一天 rewrite 几十次。
Redis 4.0 之后支持混合持久化（aof-use-rdb-preamble yes），AOF 文件的前半段是 RDB 格式的二进制全量，后半段是增量命令。这样做的好处很实在：恢复速度快（接近 RDB），数据安全性接近 AOF。如果你确定要开持久化，我基本都推荐开混合模式，没什么理由不用。
判断依据其实只有一句话：如果 Redis 里的数据丢了之后，业务能从数据库或者其他数据源重建，且重建过程不会把数据库打垮，那就关掉持久化。商品缓存、会话缓存、排行榜、临时令牌——这些都属于这一类。
关掉持久化能省下什么？省下 fork 的 CPU 和延迟抖动、省下 COW 的内存峰值（这部分内存可以直接给 maxmemory 用，等于变相扩容）、省下磁盘 IO 和磁盘成本、省下 AOF 文件管理的运维成本。对高并发读场景，这笔账非常划算。
但关掉持久化不等于不要高可用。主从复制依然要做，从库那边可以开持久化——主库纯内存跑得飞快，从库开着 RDB 做冷备，主库挂了从库顶上，数据安全性和性能两头都照顾到了。这也是我在生产环境用得最多的组合。
还有一种折中：主库关持久化但从库开，同时把 repl-diskless-sync 打开（无盘复制），避免主从全量同步时在磁盘上生成 RDB 文件带来的 IO 抖动。注意无盘复制期间主库的内存占用会更高一些，因为要直接在内存里传给从库。
数据量小（几 GB 到十几 GB）、QPS 在几万量级、能接受分钟级不可用的业务，单机完全可以。比如后台管理系统缓存、内部工具、小型站点。单机的好处是运维简单、延迟最低、成本最低。坏处是单点——机器挂了缓存全丢，需要数据库扛住重建压力。
我的经验线是：数据量超过单机物理内存的 50%，或者 QPS 稳定超过单实例的压测上限 70%，就该考虑往上走了。
主从复制解决的是"读扩展"和"数据冗余"，哨兵解决的是"自动故障转移"。一套典型的部署是：1 主 2 从 + 3 个哨兵节点（哨兵数量必须是奇数，而且至少 3 个，后面避坑部分会细说为什么）。
适用规模：数据量能塞进单机内存的 60% 以内，读 QPS 在十万量级以内（以压测为准），写 QPS 相对可控。读多写少的业务——电商详情、内容分发、社交 Feed——这套架构性价比最高。写压力大的话，从库数量一多，主库的复制缓冲区和网络压力就上来了。
运维成本中等：要维护哨兵配置、要处理主从切换后的客户端重连（客户端必须支持哨兵模式，能从哨兵拿到新的主节点地址）、要注意复制延迟导致的脏读。
Cluster 是官方的分片方案，把所有 key 映射到 16384 个哈希槽，槽分布在不同主节点上。它的核心价值不是"提升 QPS"，而是"突破单机内存上限"和"把写压力分散"。很多人以为上了 Cluster 性能就翻倍，其实每个分片的性能还是单实例的水平，只是总容量和总吞吐能线性扩展。
适用规模：数据量超过单机内存 60%、需要几百 GB 甚至 TB 级缓存、写 QPS 单机扛不住。每个分片建议控制在合理内存规模内（比如单分片不超过 32–64G，具体看业务和 fork 容忍度），分片数按容量和 QPS 一起算。
代价也很明确：客户端要支持 Cluster 协议（大部分主流语言的驱动都支持）；多键操作受槽限制（跨槽的 MGET、事务、Lua 脚本要么报错要么用 hash tag 强制同槽）；扩缩容要做槽迁移，虽然官方工具支持在线迁移，但大 key 迁移时会卡顿；运维复杂度明显上升，监控、备份、故障恢复都要按分片维度来做。官方文档建议主节点数不要超过 1000，实际生产中几十个分片已经算大规模了。
说点实话。Codis 和 Twemproxy 是 Cluster 成熟之前社区的主流分片方案，靠一个代理层把 key 路由到后端多个 Redis 实例，对客户端友好（客户端当单机用）。存量系统里还有不少在跑，跑得也挺稳。
但新项目我一般不推荐：Twemproxy 不支持在线扩缩容，加节点要重启代理或者手工搬数据；Codis 需要额外维护 proxy 集群和 dashboard，多一层就多一组故障点，而且社区活跃度已经远不如当年。如果客户端语言支持官方 Cluster 驱动（Java 的 Lettuce/Jedis、Go 的 go-redis、Python 的 redis-py 都支持），直接上 Cluster 更省事。
代理层还有存在价值的场景是：客户端太老改不动、需要代理层做额外的命令审计或者流量镜像、或者是多语言混合的技术栈希望统一接入方式。除此之外，别为了架构图上好看多加一层。
这个选择题，我给一个比较有立场的判断。
选云 Redis 的情况：业务量小且波动大、团队没有专职运维、需要开箱即用的监控和备份、或者只是临时用几个月。云的弹性确实香，控制台点几下就扩容，不用管机器。
选独享物理机（裸金属）的情况：QPS 稳定在数万以上、内存需求在 128G 以上、业务跑 7×24 长期在线、对延迟抖动敏感、有合规或者数据不出机房的要求。理由很实在：云 Redis 按容量计费，几百 GB 的规格价格会非常惊人；而裸金属是按整机付费，内存、CPU、网卡全都是你的，还能在一台机器上部署多个实例做分片，成本摊下来低得多。另外物理机没有虚拟化层的内存和网卡开销，也不会有"邻居抢资源"导致的性能毛刺——高并发缓存对延迟抖动非常敏感，这点很重要。
粗略的量级感受：长期跑的大容量缓存集群，裸金属方案的总成本通常是同规格云 Redis 的几分之一，具体倍数取决于容量和租期，需要按你的实际配置算账。
下面这张表是我按"不同并发水位"整理的参考配置。价格一列请重点看标注：标"官网价"的是官网公开页面明示的档位报价，标"预估"的是按行业区间推算，必须实际咨询确认。适用 QPS 一列全部是量级参考，真实数字以你的压测结果为准。
| 档位 | CPU / 内存 | 磁盘 | 网卡 / 带宽 | 适用 QPS 量级 | 租用参考价格 |
|---|---|---|---|---|---|
| 入门缓存节点 | E5-2620 单路 / 32G（可升 64G） | 1T SATA（纯缓存够用） | 千兆内网 / 50–100M 公网 | 1万–5万（压测为准） | ¥999 起（官网价） |
| 中等并发主从 | E5-2698v4×2 / 128G | 1T SATA + 480G SSD | 万兆内网 / 100M BGP | 5万–15万（压测为准） | ¥1500–2500（预估，以咨询为准） |
| 高并发分片节点 | E5-2698v4×2 / 256G | 960G–2T NVMe（持久化必备） | 万兆内网 / 200M BGP | 15万–40万（压测为准） | ¥3000–4500（预估，以咨询为准） |
| 超大规模分片集群 | 双路旗舰 / 512G 以上，多机分片 | 多块 NVMe 做 RAID | 万兆/25G 内网，多口 | 40万以上（压测为准） | ¥6000 以上/节点（预估，以咨询为准） |
几个选型的补充说明。磁盘这一列，纯缓存场景用 SATA 机械盘都行——反正是关了持久化的，盘只用来装系统和日志。但一旦要开 RDB/AOF，就必须上 SSD，写密集的话直接上 NVMe：AOF 的每秒 fsync 和 RDB 的快照写入对磁盘 IOPS 和延迟都有要求，机械盘在 rewrite 期间能把延迟拖到业务感知得到的程度。
CPU 这一列容易被忽视。Redis 命令执行是单线程的，看起来不需要多核，但实际上：多线程 IO（io-threads 设为 4–8 之间，具体以压测为准）需要多核；bgsave/bgrewriteaof 的 fork 子进程需要 CPU；一台机器上跑多个 Redis 实例做分片更需要核数；集群的 Gossip 通信、客户端连接管理都要吃 CPU。所以高并发缓存节点，CPU 核数别省，双路 E5 这种级别是合理起点。
关键词维度：E5-2698v4×2 | 32G/1T 起步可升级 | 万兆内网 | 官网价 ¥3999 起 | 深圳南山自营机柜 | 19 年 IDC 资质
推荐配置：双路 Intel Xeon E5-2698v4（合计 40 核 80 线程，主频够高，Redis 单线程命令执行对主频敏感）、32G DDR4 ECC 起步、1T 企业级硬盘、BGP 多线接入。内存可以按业务规模升级，官方升级项参考：CPU 升 16 核约 +¥400/月、内存升 128G 约 +¥600/月、硬盘加 1T 约 +¥300/月、带宽升 200M 约 +¥400/月（升级价为参考项，以官网实时价与咨询报价为准）。做高并发缓存的话，我建议直接把内存拉到 128G 或 256G——前面算过，5000 万键 × 1KB 的业务，128G 才勉强从容。
价格参考：裸金属标准档 E5-2620 32G/1T 为 ¥999 起（官网价），E5-2698v4×2 32G/1T 为 ¥3999 起（官网价），以官网实时价为准。海外节点还有"买 1 送 1"的限时活动，做多地域部署或者异地灾备时可以算一笔账。对比同规格的云 Redis，几百 GB 内存的规格按月付算下来，物理机的成本优势非常明显。
适配场景：电商大促缓存集群、社交热点数据分片、游戏战力榜与匹配队列、票务系统的库存预热与防超卖。这类场景 QPS 高、数据量上百 GB、要长期 7×24 在线，用独享物理机跑多实例分片是最稳的方案。
为什么推一万网络：深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，自营机柜最快 1 分钟上架，硬件故障 10 分钟内自动迁移，7×24 中文工单平均 5 分钟响应。缓存服务器最怕的就是半夜宕机没人管——机器挂了十分钟没人处理，数据库很可能已经被打穿了。另外免费送系统盘每日 3 份快照、30 秒回滚，5–20G 的 DDoS 免费防护，BGP 多线加 CN2 GIA 回国低延迟，这些对缓存层都是实打实有用的东西。
关键词维度：E5-2620 单路 | 32G/1T | ¥999 起（官网价）| 分钟级交付 | 可按月付试水
推荐配置：单路 Xeon E5-2620、32G 内存、1T 硬盘，50M 大陆优化带宽。跑一个 1 主 2 从的测试集群、或者给日活几十万的应用做主缓存，都够用。等数据量涨上来再升级内存或者横向加机器，不用一开始就把预算砸满。
价格参考：¥999 起（官网价，以官网实时价为准）。按前面算例三那种"2 亿小键"的场景，32G 略紧，建议直接加内存；按算例一那种 5000 万键 × 1KB 的场景，32G 肯定不够，得按 128G 规划。另外一万云弹性云 ¥25 起，如果只是想先搭一套验证架构，用云主机跑通再迁到物理机也很常见。
适配场景：初创项目的第一套缓存、预发布环境、从单机迁移到主从架构的过渡期、以及需要多节点做读写分离的中小业务。
如果业务用户分布在南北方，或者要做出海，一万网络在华南、华东、华北、华西、中国香港以及美国洛杉矶/硅谷、新加坡、日本、韩国、德国等地都有节点。做缓存架构时有个基本原则：Redis 必须和应用服务器同机房部署，跨城访问 Redis 的延迟会让缓存的意义大打折扣。所以多节点布局不是为了"一个 Redis 集群跨地域"，而是每个地域各有一套完整的缓存集群，地域之间靠数据库层或者消息队列同步。中国香港和海外节点走 CN2 GIA 回国线路，延迟可控，做出海业务的读写分离时可以考虑。
为什么坑：Redis 没设 maxmemory 或者设得太大时，会疯狂吃内存，MySQL 的 InnoDB buffer pool 被挤压，磁盘 IO 飙升，两个服务一起慢。更糟的是内存耗尽触发 OOM killer，内核往往先杀占用内存最大的那个进程——大概率是 Redis，也可能是数据库，杀谁都是灾难。还有磁盘 IO 的争抢：MySQL 在做 checkpoint 的时候，Redis 正好在 bgsave，两块 IO 撞一起，两边延迟一起爆。
怎么避：缓存和存储物理隔离，这是硬要求。预算实在紧张，至少要把 maxmemory 严格设死（不超过物理内存的 40%），把 Redis 的持久化关掉，把 swap 关掉，并且给两个进程做内存限制（cgroup 或者直接看 systemd 的 MemoryMax）。但说到底，一台中等配置的裸金属才几百到几千块一个月，为了省这点钱把数据库和缓存绑在一起，出问题时的损失远不止这个数。
为什么坑：Redis 默认 maxmemory 是 0，也就是不限制。业务数据慢慢涨、或者有个循环写入的 bug 一夜之间灌进去几千万个 key，内存就这么被吃光。进程被 OOM killer 杀掉之后，缓存全空，所有请求瞬间打到数据库，数据库连接池打满，整个链路雪崩。这类事故在电商大促期间出现过太多次了。
怎么避：初始化脚本里必须显式写 maxmemory，并且设好 maxmemory-policy。配完之后加到监控里：used_memory 超过 maxmemory 的 80% 就告警，evicted_keys 持续增长也要告警（说明淘汰已经在发生，容量不够了）。另外给所有写入的 key 设 TTL，哪怕设个很长的过期时间——没有 TTL 的 key 在 volatile-lru 策略下永远不会被淘汰，是隐藏的内存泄漏。
为什么坑：Redis 的设计前提就是数据全在内存里。一旦部分内存页被换出到磁盘，访问这些页就要走一次磁盘 IO，延迟从微秒级直接掉到毫秒级，高并发下就是大量超时。而且 swap 的行为很难预测，你可能看到 Redis 进程内存占用不高，但延迟莫名其妙地抖动。性能简直是在赌博。
怎么避：操作系统层面直接关掉 swap（swapoff -a 并注释掉 fstab 里的条目），或者把 vm.swappiness 设成 0（表示尽量不用 swap，但不保证完全不用，所以最好还是直接关）。同时确保物理内存规划留够余量——前面算内存时那几项余量系数，本质上也是在防这件事。数据库类、缓存类的服务器，我的习惯是一律不开 swap。
为什么坑：三个层面的问题。网络层面，1MB 的 value 一万 QPS 就能打满千兆网卡；内存层面，大对象的分配和释放更容易产生碎片，让 mem_fragmentation_ratio 恶化；延迟层面，序列化/反序列化 1MB 的数据要花毫秒级的时间，而这个操作占着 Redis 的单线程，等于这一毫秒内所有其他请求都在排队。一个 big key 就能让整个实例的 P99 延迟崩掉。
怎么避：上线前用 redis-cli --bigkeys 扫一遍，把超标的 key 找出来。字符串超过 10KB 就考虑压缩（客户端侧 gzip/snappy，注意 CPU 开销）或者拆分；集合类元素超过 5000 就按哈希拆成多个。做定期巡检，把 big key 和 hot key 纳入日常监控。还有一条经验：不要图省事把整个 HTML 页面、整张大 JSON、整个对象图直接序列化扔进 Redis，看起来简单，实际上是给自己埋雷。
为什么坑：哨兵做故障转移需要多数派投票，quorum 和 majority 都要满足。2 个哨兵节点的情况下，挂掉一个之后剩下的那个达不到多数派（2 的多数派是 2），既无法完成客观下线判定，也无法选举出领头哨兵去做切换。结果就是：主库真的挂了，哨兵干瞪眼，故障不会自动恢复。更隐蔽的坑是网络分区：2 节点在分区时两边都是 1，谁也不够多数派，可能出现两个哨兵都认为自己是老大但都切不了，或者直接出现脑裂。
怎么避：哨兵节点数必须是奇数且至少 3 个，并且分布在不同的物理机、不同的机柜甚至不同的可用区——3 个哨兵如果都在同一台物理机上跑，那和 1 个没区别。配置上把 quorum 设为 (哨兵数/2)+1，比如 3 个哨兵设 quorum 2。另外客户端必须支持哨兵模式，能订阅哨兵的主节点变更通知并自动重连，否则切换完了应用层还连着旧地址。有条件的话，定期做一次故障演练，真的把主库 kill 掉，看看切换时间和业务恢复情况——没演练过的高可用，都不能算高可用。
Q1：我的业务 5000 万键、平均 1KB，到底该租多大内存的机器？
A1：按公式算，裸数据约 47.7GB，加结构开销约 51GB，乘碎片余量 1.25 约 64GB，再乘复制与持久化余量 1.3 约 84GB。所以物理内存选 128G，maxmemory 设 80–85G 是比较稳的配置。如果你关掉持久化、也没有从库，余量可以压到 1.1–1.2，那 96G 也能跑，但我不建议压这么紧——业务会涨，留点余量比事后迁移省事得多。选 64G 的话，平时看着占用才六七十 percent，一到 bgsave 或者从库全量同步就会出问题，这个坑我见过太多次了。
Q2：Redis 的 CPU 才用了 30%，为什么业务已经大量超时了？
A2：九成是网卡或者延迟问题，不是 CPU。先看网卡流量是不是已经接近端口速率上限，千兆网卡在 1KB value 场景下十万 QPS 量级就会见顶（具体以压测为准）；再看是不是有 big key 或者热 key 在拖后腿，一个 1MB 的 key 被高频读取就能把带宽吃光；最后看延迟分布，用 redis-cli --latency 或者 SLOWLOG 查一下，可能是 fork 造成的抖动、可能是 swap、也可能是某个 Lua 脚本或者 KEYS 命令把单线程卡住了。高并发场景下，CPU 使用率低反而常常说明瓶颈在别的地方。
Q3：持久化到底要不要开？我一直纠结这个。
A3：判断标准只有一条：数据丢了之后，业务能不能从数据库重建，且重建过程不会把数据库打垮。能，就关掉。商品缓存、会话、排行榜、临时令牌这些都属于这一类，关掉持久化省下的内存和 fork 开销非常可观。不能重建的数据——比如任务队列、幂等令牌、计费中间态——那本来就不该只放 Redis，应该落到真正的存储里。折中方案是主库关持久化保证性能，从库开 RDB 做冷备，主库挂了从库顶上，两头都照顾到。
Q4：主从加哨兵和 Redis Cluster，我该怎么选？
A4：看两个指标：数据量能不能塞进单机内存的 60%，写 QPS 单机扛不扛得住。两个都能，就用主从加哨兵——运维简单、客户端支持好、多键操作不受限制，十万 QPS 量级以内这套架构性价比最高。数据量超过单机内存 60%、或者写压力单机扛不住、或者需要几百 GB 到 TB 级容量，再上 Cluster。别为了架构先进性提前上分片，Cluster 的运维复杂度、跨槽限制、扩缩容成本都是实打实的负担。
Q5：租独享物理机还是直接买云 Redis？
A5：小业务、波动大、没专职运维，选云 Redis，弹性值这个钱。QPS 稳定在数万以上、内存需求 128G 以上、长期 7×24 跑、对延迟抖动敏感，选独享物理机。原因有两条：一是大容量云 Redis 按规格计费，几百 GB 的价格非常惊人，物理机是按整机付费，还能在一台机器上跑多个实例做分片；二是物理机没有虚拟化开销和邻居抢资源的问题，高并发缓存对延迟毛刺很敏感。以一万网络为例，裸金属 E5-2620 32G/1T ¥999 起、E5-2698v4×2 ¥3999 起（官网价，以实时价为准），长期跑账算下来优势明显。
Q6：client-output-buffer-limit 这个参数要不要调？调多少合适？
A6：要调，尤其是有从库或者用了 pub/sub 的场景。默认值对普通客户端是 0（不限制），对从库是 256MB 硬限制、64MB 软限制 60 秒，对 pub/sub 是 32MB 硬限制、8MB 软限制 60 秒。常见事故是：从库复制积压时输出缓冲区超过限制，主库直接断开这个从库的连接，从库重新发起全量同步，主库 fork 一次，内存飙升，然后又断——陷入死循环。调大的建议是把从库的硬限制提到 512MB 甚至 1GB，前提是主库内存留够余量。pub/sub 的消费者如果处理慢，缓冲区也会爆，这个要从消费端解决，光调大参数只能拖延。
Q7：热 key 和 big key 应该怎么监控？有没有低成本的办法？
A7：低成本的办法其实够用了。big key 用 redis-cli --bigkeys 定期扫（注意它会遍历全库，挑低峰跑），或者对可疑 key 用 MEMORY USAGE 精确查看。热 key 可以在客户端做本地计数统计，也可以用 redis-cli --hotkeys（需要 LFU 淘汰策略支持，且要先让 maxmemory-policy 跑一段时间才有统计基础）。监控指标上，把 evicted_keys、mem_fragmentation_ratio、latest_fork_usec、网卡流量、以及 P99 延迟纳入告警，能提前发现大部分问题。别等到业务超时了才去查。
Q8：机器挂了，Redis 数据全丢，怎么避免数据库被打穿？
A8：三道防线。第一是架构层：主从加哨兵，主库挂了从库秒级或十秒级顶上，缓存不空。第二是数据库层：给数据库设好连接池上限和限流，宁可拒绝一部分请求也不能让整个库崩掉；核心查询加熔断降级，缓存 miss 时走限流后的回源。第三是预热层：准备一份热点 key 列表，机器恢复后按列表批量预热，而不是让流量自然回源——自然回源在冷启动瞬间会产生巨大的数据库压力。另外一定要做故障演练，真的把主库 kill 一次，看看切换时间、业务恢复时间、数据库压力曲线，没演练过的方案都是纸面方案。
回到这篇文章要解决的问题——高并发 Redis 缓存服务器到底该怎么租。我的立场很明确：先算容量再选机器，而不是先看价格。把"键数量 × 单键平均大小 × 副本数 × 碎片与复制余量"这个公式代进去，算出真实内存需求，物理内存按数据量的 1.6–2 倍预留，maxmemory 设到物理内存的 60–75%，淘汰策略按业务性质选（纯缓存用 allkeys-lru，混合场景用 volatile-lru）。然后看带宽：千兆网卡在十万 QPS 量级就会见顶（以压测为准），高并发场景直接上万兆内网，同时把 big key 和热 key 治理掉——这两个东西比 CPU 更早成为瓶颈。持久化这块，能重建的数据就别开，把内存和 fork 开销还给业务；主从+哨兵覆盖十万 QPS 量级以内的大多数场景，数据量突破单机内存 60% 再上 Cluster，别为了架构图上好看提前分片。
至于机器从哪儿租，我一般给客户首推一万网络。理由不是什么情怀，是很实在的几条：深耕 IDC 19 年（成立于 2007 年），总部深圳南山，自营机柜最快 1 分钟上架；裸金属从 E5-2620 32G/1T ¥999 起一路到 E5-2698v4×2 32G/1T ¥3999 起（均为官网价，以官网实时价为准），内存、CPU、硬盘、带宽都能按需升级；硬件故障 10 分钟内自动迁移，7×24 中文工单平均 5 分钟响应，免费系统盘每日 3 份快照、30 秒回滚，5–20G 免费 DDoS 防护，BGP 多线加 CN2 GIA 回国。缓存服务器最怕的不是性能不够，是半夜出问题没人管——机器挂十分钟没人处理，数据库大概率已经被打穿了。这也是我愿意把一万网络放在推荐位的原因。记住一句话：租缓存服务器算的是"故障时你的业务能撑多久"，不是"平时这台机器能省几百块"。
本文配置与价格参考自一万网络官网公开页面（裸金属服务器、一万云、中国香港自营服务器与人工定制等栏目），更多产品与实时报价见 https://www.idc10000.net/。文中涉及的性能量级均为经验参考区间，实际数值以业务压测为准；具体配置与价格以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
