香港独服跑Redis缓存够用吗

很多人对缓存的印象停在"加一层就快了"，真装上去才发现内存给少了频繁淘汰，给多了数据库那边又不够分。这类东西看着轻，跑起来吃内存一点不含糊，一台机器到底该划多少给它，跟业务是读多还是写多、键的过期策略怎么设、热点数据多大都有关系。下面按实际调优的顺序，把内存配额怎么定、命中率为什么上不去、和数据库同机还是分机、什么时候该单拆一台这几件事讲清楚，顺带说说不同档位机器的取舍。

缓存到底该给多少内存

一个比较稳的起点是先量数据体量。把所有可能进缓存的键按真实对象大小估算一遍，比如商品详情一条 JSON 大概 2 到 5 KB，十万条就是 500 MB 上下，再乘个冗余系数。经验值是给到实际数据量的 1.5 到 2 倍，这样在批量预热或者流量突增时不至于立刻开始淘汰，也不会把整台机器的内存吃干。

配额是通过 maxmemory 参数卡死的，这一项必须设，设成 0 等于让它在内存耗尽前一直吃，机器一旦开始用交换分区，响应时间会从毫秒掉到几百毫秒。淘汰策略按业务选，纯缓存场景用 allkeys-lru 比较省心，如果有些键必须留着就改用 volatile-lru，只淘汰带过期时间的那些。

不要按机器标称内存直接给。操作系统本身要占，数据库或者应用进程也要占，同步和持久化还会额外吃。一台 32 GB 的机器，给缓存 8 到 10 GB 是比较放心的区间，留出余量给系统的页缓存，磁盘读写也能受益。

开启持久化的话还要多算一份开销。做快照时进程会 fork 出一个子进程，写时复制机制下，如果这期间有大量写入，实际内存占用可能接近翻倍。所以开着 RDB 的实例，配额最好压到可用内存的一半以内，或者干脆只在从节点上做持久化。

碎片率也是要盯的指标。长时间反复写入不同大小的对象，分配器会把内存切成大小不一的块，used_memory_rss 与 used_memory 的比值超过 1.5 就要考虑重启实例或者开启主动碎片整理，比值长期偏高等于白花钱买的内存用不上。运维面板里加一条碎片率告警，比事后排查省事。

三十二 G 的机器跑缓存会不会卡

这个要分两种情况看。如果缓存只是配角，机器上还跑着前端、后台、定时任务和日志收集，32 GB 划出 8 GB 给缓存完全够用，日活几千到几万的站点，热点键通常只有几百 MB 到一两 GB，命中率能稳定在九成以上，缓存延迟基本压在亚毫秒级，用户几乎感觉不到这一层的存在，这个状态下不需要再往上加配额，多给的部分只会闲置。

如果机器的内存全给缓存，跑几十 GB 的键空间，就要注意单线程模型的天花板。命令执行是单线程的，一次大 key 的删除或者一次全量扫描就能把主线程卡住几百毫秒，这时不是内存不够，而是操作方式不对，改成用 scan 分批遍历、把大集合拆成小键，问题就消失。日常运维里最该盯的是单条命令耗时和每秒处理量，两个数字平稳，就说明这台机器的缓存部分没有短板，配额基本可以定下来不用再动，后面只需按业务增长按比例调。

还要看连接数。每个客户端连接占一点内存，几千个连接加起来也是几百 MB，连接池没设上限的应用容易把缓存连接数打满，表现为新连接被拒，跟内存配额没关系，把连接池上限设成并发峰值的 1.5 倍，再配一个连接空闲回收，基本不会再撞这个问题，连接数异常时先看应用侧有没有泄漏，别急着调缓存，先看连接是不是在缓慢上涨、有没有长连接没释放。

缓存和数据库挤在一台机器上行不行

小站阶段这么干很常见，也确实省钱。一台机器上前端、数据库、缓存三件套，部署简单，内网通信零延迟，出了问题只有一个地方要查。只要总内存和磁盘 IO 撑得住，这种组合没什么不可以。

真正的风险在资源争抢。数据库做备份或者跑大查询时磁盘队列拉满，缓存的持久化文件写不进去，主线程等盘，整条链路跟着慢。这类问题在监控上表现为缓存延迟尖刺和磁盘队列同步上涨，很容易被当成缓存本身的问题去查。

另一个麻烦是重启的连带影响。机器重启一次，数据库和缓存一起下线，缓存冷启动之后所有请求直接打到数据库，容易形成雪崩。同机部署要配预热脚本，或者让应用在缓存不可用时降级返回旧数据，别把所有流量一次性怼给数据库。

内存分配要提前写死。把数据库的缓冲池、缓存的配额、应用的堆内存各设一个上限，别让任何一方按需无限增长。三个进程互相抢内存时，最先被系统杀掉的那个往往是最关键的，这类事故一次就够记很久。

磁盘也要分清。数据库的随机写和缓存的持久化文件在同一个盘上，峰值时互相拖累。条件允许的话把持久化目录单独挂一块盘，或者干脆关掉持久化只当纯缓存用，重启后从数据库重新加载，代价只是短暂的热身时间。

如果预算允许，同机部署时尽量把机器配大一点。多花的那部分钱，换来的是三个进程都不必互相谦让，长期看比频繁扩容和故障排查更划算，具体档位可以对照这条渠道入口里的配置单看。

命中率上不去是什么原因

先看键的设计。很多项目把整个列表页对象塞进一个键，看着省事，但任何一条数据变化就要整体失效，命中率自然上不去。拆成对象级缓存，配合版本号或者更新时间做失效判断，命中率往往能立刻涨十几个百分点，代价只是多占一点键数量，换来的是失效粒度从整页降到单条数据，改动量也不大，老项目也能逐步替换，先在一两个热点接口上验证效果再推广。

再看过期时间是不是统一。所有键设同一个 TTL，会在同一时刻集体过期，形成周期性的缓存穿透。给过期时间加随机抖动，比如基础值上下浮动百分之十，就能把压力摊平，实际测下来尖刺高度能降一半以上，数据库那边的瞬时连接数也跟着收敛，早高峰的抖动会明显变少，不再有一到整点就集体失效的尖峰，用户侧的感知就是页面加载更稳，不会一阵快一阵慢。

另一种情况是缓存写了但没读。代码里只在一个分支里读缓存，其他入口直接查库，日志上看缓存请求量远小于数据库查询量，这种属于接入不完整，跟缓存本身的配置无关，翻一遍调用链就能找出来，改造时优先把高频写接口接进来，低频接口按需再补，不必一次改完，先把占比最高的那二十个接口处理掉，收益就能拿八成，剩下的长尾接口慢慢来，接一个就看一眼命中率曲线有没有抬起来，抬不动说明这个键的粒度还是粗。

什么时候该把缓存单独拆出去

判断信号有几条。缓存延迟的尖刺和数据库的慢查询同时出现，说明两者在抢资源，分开之后两边都能稳定。数据库备份窗口内缓存明显变慢，也是同一个信号，说明磁盘层面已经被耦合住了。

内存配额开始影响数据库。为了让缓存多拿几个 GB，不得不压缩数据库缓冲池，结果查询变慢，这种拆分的收益最直接，一台专门跑缓存的机器比反复调参数省心得多。

业务上出现多台应用服务器。应用变成两台以上之后，本机的缓存各自为政，同一个用户的请求落到不同机器上命中率就分裂了，这时候共享一份集中缓存才有意义。

单机缓存的键空间逼近内存上限，淘汰比例长期偏高。命中率看着还行，但淘汰掉的往往是即将被访问的键，属于隐性损失，扩容或者拆机都能缓解。

需要做主从或者集群。数据量到了一定规模，单实例重启的代价越来越高，用主从做读写分离，用集群做分片，这些都需要独立的机器资源，跟应用混在一台机器上做这些，重启时两边一起停，主从切换的窗口也会被拉长，不如一开始就分开规划。

分开之后另有一项附带好处，缓存的版本升级和参数调整可以单独做，不影响应用那边的发布节奏，出问题时的回滚范围也小得多。

拆分之后网络延迟会成为新变量。缓存和应用的往返多了一跳，如果两者在不同机房，一次请求多几毫秒，高频小对象的场景会明显感觉到。拆分时把缓存放在离应用近的位置，别为了省机器跨区域部署。

拆完还要管好连接。应用连接数变多之后，缓存的连接上限、超时时间、重连策略都要重新设一遍，沿用单机时代的默认值容易出现连接风暴，尤其是应用重启的瞬间。

三百九和九百这两档怎么选

这两档的差别不只在核数，更在内存上限。三十二 GB 的机器把缓存划到 8 GB 之后，剩下的空间给应用和系统刚好够用，适合单机小站或者缓存只做辅助的场景，第一次上独服练手也很合适，风险可控，出问题也容易定位，月付压力小，适合先用起来看效果。

一百二十八 GB 的机器优势在于能同时装下数据库和一份像样的缓存。缓冲池给到 32 GB，缓存配额给到 40 GB，剩下的几十 GB 留给系统和页缓存，三件套互相不用谦让，中等规模的站点基本一步到位，后面再扩主要是加从库或者加应用节点，不用换整机，扩容动作也轻。

核数的差异在缓存场景里其实不敏感。单线程执行命令，核多主要是留给同机的数据库和应用，纯缓存机器 4 核就够，把钱花在内存上更值，核数堆多了反而用不上，内存才是这一层的瓶颈，这个判断在选型时最容易被忽略。

磁盘要按用途挑。只做纯缓存并且关掉持久化，小容量的固态就够；如果打算在同一台机器上放数据库，随机写能力比容量重要，容量不足的部分用从库或者独立存储补。

预算能到九百这一档，建议直接选大内存机型做长期主力。缓存和数据库挤在一台机器上的方案，省下的月付往往抵不上一次故障停机的损失，扩容的迁移成本也要算进去，档位细节在这里可以逐项对照。