运维老手血泪总结：5大服务器部署缓存深坑

　　运维老手血泪总结：5大服务器部署缓存深坑

　　去年四月份，我在华东三区IDC给某银行核心账务系统上线Redis 7.2集群——6节点哨兵+Proxy架构，结果凌晨三点熔断，流水积压超42万笔，DB CPU飙到98%，查日志发现是maxmemory-policy配成noeviction却没改配置同步策略，热key没触发驱逐，全堆在1个分片上。这坑我踩过三次，每次都是“默认值最安全”这种幻觉害人。

　　第二坑是swap分区——很多人以为“Linux内核自动管理”，其实Redis 7.0+启用透明大页（THP）后，只要内存水位＞75%，内核就会把部分page swap out再swap in，我实测过：同一台32G内存的ECS，关闭swap后set操作p99延迟从87ms降到3.2ms；但运维同学偷偷重启了sysctl，忘了关vm.swappiness=1，第二天早高峰就抖动。你猜怎么着？监控只报“连接超时”，没人看/proc/swaps里那0.5G的匿名页。

　　第三坑藏在etcd里。去年四月份我们用etcd v3.5.10做服务发现注册缓存节点，但没设lease TTL续期心跳，结果etcd leader换届期间有2个client连续5分钟没续租——它们的缓存实例就从服务列表里消失了，流量全打到剩下4个节点上，CPU干到91%。更绝的是，etcd日志里只写“lease expired”，没提哪个key、哪个client，排查花了6小时17分钟。新技术？对，但文档里那句“lease默认不自动续期”被加粗得像芝麻粒。

　　第四坑是TLS握手缓存。我们给Codis-proxy加了mTLS双向认证，本意是防中间人，结果发现客户端每建一个新连接都要跑完整TLS 1.3 handshake，OpenSSL 3.0.7的session resumption在代理层根本没生效——因为Codis没透传ticket key，导致每秒新建连接数从800飙到12000，proxy线程池满，拒绝服务。查了三天，在Codis 4.3.2的GitHub issue#3918才看到一句“tls session cache disabled by design”。这设计，真是贴心。

文章配图，仅供参考

　　我测过，所有主流缓存SDK的refreshAfterWrite在write-through模式下都会跟分布式缓存写失败打架。不是bug，是设计哲学冲突——有人要一致性，有人要吞吐量，没人想背锅。

　　运维老手血泪总结：5大服务器部署缓存深坑

　　我认为它优点在"新技术"

　　去年四月份

　　这五个坑，我每个都留了tcpdump包、systemd journal截屏、和当时值班表照片——但我不敢开源，怕法务找上门。现在我改用手写checklist，第7条明确写着：“确认etcd lease续期代码已埋点，不许信默认”。你要是想抄，我建议先拿测试环境跑72小时，盯着/proc/meminfo里的SwapCached字段看——真坑都在数字背后藏着。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!