用Redis撑起百万级数据存储，聊聊那些架构上的坑和经验分享

用Redis撑起百万级数据存储，聊聊那些架构上的坑和经验分享

直接上干货，我们当初业务量上来，数据量逼近百万级时，Redis从一把锋利的瑞士军刀，突然变成了需要小心伺候的“祖宗”,踩过的坑一个接一个。

第一个大坑：内存，你以为的和你实际用的不一样。 刚开始觉得数据量不大，就使劲往里塞，用了很多花里胡哨的数据结构，每个键值都挺小，但架不住数量多，最要命的是，我们没仔细算内存，Redis的数据全在内存里，内存是硬成本，等报警来了，发现内存使用率95%以上，快撑爆了，操作开始变慢，这时候才明白，（来源：早期项目教训）必须提前规划容量，给内存留出至少20%-30%的余量，不能等到报警再处理。 有些数据根本没必要放Redis，比如一些冷数据，或者可以异步计算的结果，放进去就是浪费，我们后来立了规矩，进Redis的数据必须经过审核，有明确的TTL（过期时间）。

第二个坑：持久化的“沉默杀手”。 为了保证数据不丢，我们开了RDB（快照）和AOF（日志）两种持久化，结果在某个业务高峰，Redis突然卡住了几秒钟，响应时间飙升，查了半天，发现是RDB在后台fork子进程做快照，当数据量很大时（比如十几个G），fork操作本身会阻塞主线程，如果服务器内存不够大或者CPU扛不住，这个阻塞时间会很长，（来源：线上故障复盘）这就是著名的“fork阻塞”问题。 教训是，对于大数据量的Redis实例，要特别关注持久化策略，不能无脑全开，我们后来把持久化放在从库上做，主库关掉或者用更轻量的方式，牺牲一点极端情况下的数据安全性，换来主库的稳定，机器内存要留足，避免fork时和操作系统“借”内存导致的问题。

第三个坑：网络和超时，链路上的暗箭。 业务多了，成百上千个服务都连同一个Redis集群，网络稍微有点波动，或者某个服务发了条慢查询，整个连接池可能就被拖慢了，我们遇到过因为一个不合理的KEYS *操作（虽然明令禁止，但总有疏忽），导致Redis CPU瞬间打满，所有依赖它的服务连锁超时、雪崩。（来源：某次全链路故障报告）必须对客户端命令进行监控和限制。 我们后来引入了代理层，对高危命令进行拦截，也对每个客户端的连接数和超时时间做了严格限制，一定要设置合理的连接超时和读写超时时间,不能让一个慢查询拖死所有连接。

第四个坑：集群，不是银弹。 单实例撑不住了，自然想到用集群，但集群带来了新的复杂度，首先是数据分片，如果键设计得不合理，导致大量数据集中在某个分片，这个分片就成了热点，容量和性能都先到瓶颈，我们吃过亏，（来源：集群扩容踩坑记录）比如用固定的前缀做键，结果那个分片的数据量是其他的两倍。 必须用合适的哈希标签来保证相关数据在一个分片，同时让数据分布均匀，其次是集群运维，节点故障、主从切换、扩容缩容，每一步都是风险，手动操作很容易出错，后来我们花了大力气做自动化运维脚本,把流程固化下来。

第五个坑：客户端，猪队友的坑。 Redis服务端再稳定，也怕“猪队友”客户端，我们见过客户端连接泄露（开了不关），把Redis的最大连接数占满；也见过客户端配置不对，用了同步阻塞的方式去调异步命令，把接口拖慢。（来源：多团队协作支持案例）必须统一和规范客户端的使用。 我们制定了公司级的Redis客户端使用规范，推荐经过验证的连接池配置，并提供公共的客户端包，把重试、降级、监控的逻辑都封装在里面,减少业务方误用。

最后一点经验：监控和告警是生命线。 不能只监控Redis服务是否存活，核心指标必须盯死：内存使用率、连接数、OPS（每秒操作数）、延迟时间、CPU使用率、网络带宽，还有慢查询日志，我们设了多级告警，比如内存超过80%就发预警，超过90%就打电话。（来源：运维团队实践）很多问题在酿成大祸前，监控指标上早有端倪。

用Redis扛百万级数据，它绝对是好帮手，但你必须尊重它的特性：它是内存数据库，容量和速度是核心；它是单线程模型，怕慢操作和阻塞；它是分布式系统的一部分，网络和客户端行为至关重要，架构上没有一劳永逸的方案，只有持续的关注、规范的约束和细致的运维，先想清楚数据怎么存、怎么过期，再考虑怎么用，出了问题怎么降级,这套思路比任何具体的技术选型都重要。