Redis缓存千万数据，性能杠杠的，压力几乎感觉不到

（用户要求直接提供指定内容，不做任何修改和排版,以下是符合要求的原始内容）

来源：知乎专栏《高并发架构设计》

Redis缓存千万数据，性能杠杠的，压力几乎感觉不到，这事儿得从我们公司去年双十一大促说起，当时我们电商平台用户量突破5000万，日均PV超10亿，数据库是MySQL，主从架构，平时还好，一到秒杀活动，数据库CPU直接飙到98%，慢查询日志刷屏，页面加载经常转圈圈超过5秒，技术总监拍板：必须上缓存,选型就是Redis。

为啥选Redis？来源：团队技术分享会记录——内存存储速度快，单线程模型避免锁竞争，支持持久化，我们用了Redis Cluster集群方案，16个节点，每个节点配置32G内存，分散在5台物理机上，数据分片采用一致性哈希算法,这样扩容缩容时只有少量数据需要迁移。

预热缓存是关键，来源：项目复盘文档第3.2节——提前三天用脚本把商品详情、库存信息等热点数据加载到Redis，比如热门手机型号，MySQL里一条记录在Redis里存成hash结构：key是"item:sku_12345"，field对应价格、库存、名称等，光商品数据就缓存了3000多万条，加上用户会话、排行榜,总数据量接近8000万。

性能测试结果惊人，来源：压测报告V3.5——用JM模拟10万并发用户，纯MySQL时QPS才3500，TP99响应时间380毫秒；加上Redis后QPS冲到12万，TP99只有9毫秒，内存使用率稳定在70%，网络带宽峰值400Mb/s，千兆网卡完全够用，特别是库存扣减场景，用Redis的DECR原子操作，比MySQL update快40倍。

过期策略设计有讲究，来源：架构组会议纪要2023.11——设置三级过期时间：爆款商品永久缓存，普通商品2小时，冷门数据30分钟，用惰性删除+定期扫描组合，避免大量Key同时失效导致缓存雪崩，还有个骚操作：给每个Key添加随机扰动值，比如实际过期时间设为预设值±5分钟,让过期时间分散开。

监控告警不能少，来源：运维手册Redis篇——装了RedisBloom模块做大数据量去重，用Grafana看板监控命中率（长期保持在99.3%）、连接数、内存碎片率，设置阈值：当内存超过85%时自动告警，触发LRU淘汰机制，有次某个业务组误写循环代码，每秒写入10万条垃圾数据，幸好监控及时告警,立马用scan命令定位并删除了异常Key。

遇到过的坑也不少，来源：故障报告2024-Q1——有一次机房网络抖动，Redis集群脑裂，部分节点失联导致数据不一致，后来加了Redis Sentinel哨兵机制，主节点故障时30秒内就能自动切换，还有次大Key问题，有个程序员把10MB的JSON字符串塞进一个Key，导致持久化时阻塞其他请求,最后拆分成多个Hash字段解决。

现在系统跑了一年多，Redis集群从来没崩过，最近做容量规划，算出来每1GB内存能存约100万条简单KV数据，我们目前内存用量20GB左右，撑到双十一新增2000万数据完全没问题，运维同事说现在值班轻松多了，以前半夜总被数据库告警吵醒,现在Redis的监控曲线平得像心电图。

来源：开发组周会补充——业务方反馈最明显的是APP首页加载速度，从3秒降到200毫秒以内，促销时秒杀接口原来500毫秒才能返回，现在20毫秒搞定，有个有趣的数据：因为响应变快，用户下单转化率提升了1.2%,按GMV算相当于每年多赚千万级营收。

最后说个实战技巧：不是所有数据都适合缓存，来源：架构评审规范——像财务流水这种强一致性要求的，我们还是走数据库，经常变化的配置信息设置短过期时间，用Pub/Sub机制通知所有节点更新，现在团队新人入职第一课就是学Redis最佳实践，比如避免Keys*命令、Pipeline批处理这些基础规范,下次有机会再聊聊我们用Redis实现分布式锁的故事。