Redis集群那些头疼的问题和解决办法，聊聊常见坑和经验分享

说到Redis集群,用起来是爽，分布式、高可用、高并发，但真到了运维和深度使用的时候，一堆头疼事儿就冒出来了，这些东西官方文档不会手把手教你，很多都是踩过坑才换来的经验，下面我就聊聊几个最常见也最让人头疼的问题和解决办法。

第一个大坑：内存爆了，但删除Key还是报OOM。

这事儿特别反直觉,你可能遇到过，明明Redis已经报了OOM（内存不足）错误，但当你试图删除一些大Key来释放空间时，删除命令本身也失败了，还是报OOM，这感觉就像掉进了一个死循环，非常绝望。

为啥会这样？ 原因在于Redis删除Key的方式，对于大型的复合数据类型，比如一个包含几百万个元素的Hash或者List，删除它需要消耗大量的CPU时间来进行内存回收，这个删除操作本身，需要在同一时间点分配一个临时的、跟这个Key差不多大的内存空间来辅助完成释放动作，当整个实例内存已经见顶时，连这个“临时空间”都分配不出来了，所以删除命令就直接失败了。（来源：Redis官方文档关于内存优化的部分）

怎么办？ 有几种思路：

1. 防患于未然：这是最重要的，通过监控系统，时刻关注内存使用率，设定一个安全阈值（比如80%），一旦接近就赶紧扩容或者清理数据，别等到100%。
2. “温柔”地删除：不要直接用 DEL 命令删大Key，可以用更柔和的方式，比如对于Hash，用 HSCAN 加 HDEL 分批删除字段；对于Set，用 SSCAN 加 SREM 分批删除成员；对于List，直接一点点 LPOP/RPOP，虽然慢，但不会导致阻塞和OOM，阿里云的开发者社区就有文章详细讲过这种渐进式删除的方法。
3. 终极手段：如果已经卡死了，连渐进式删除都做不了，只能重启节点，用 redis-cli 加上 --bigkeys 参数先找出大Key（如果还能执行命令的话），然后通过重启从节点，再切换主从的方式来规避，这会带来短暂的服务不可用。

第二个头疼点：客户端连接数爆满，新连接被拒绝。

Redis集群每个节点能支撑的连接数是有上限的,这取决于 maxclients 配置和系统文件描述符限制，当应用有BUG导致连接泄漏，或者某个客户端因为网络问题产生大量短连接时，很容易把连接数打满，这时候新的业务请求就完全进不来了，影响非常大。

解决办法：

1. 监控报警是生命线：必须对每个节点的连接数进行监控，设置明确的报警线，这是第一时间发现问题的关键。
2. 使用连接池：客户端一定要使用连接池，避免每次操作都创建新连接，并且要合理配置连接池的最大空闲数和最大连接数。
3. 定期检查与重启：定期检查 CLIENT LIST 命令的输出，看看有没有异常长时间空闲的连接或者来源可疑的连接，在紧急情况下，可以用 CLIENT KILL 命令踢掉一些空闲连接来救急，但根本之道是找到并修复客户端连接泄漏的代码。
4. 调整系统限制：确保系统的 ulimit 配置足够大，让Redis能够设置更高的 maxclients。

第三个常见坑：网络抖动导致的主从切换和脑裂。

在分布式系统中,网络是脆弱的，偶尔的网络抖动（比如丢几个包，延迟高几百毫秒）是常态，但在Redis集群里，这可能会引发大问题，集群节点之间心跳检测超时，哨兵（Sentinel）或者集群模式可能会认为主节点挂了，于是选举出一个新的主节点，但可能旧的主节点其实没挂，只是网络暂时不通，等它恢复后，就出现了两个主节点，这就是“脑裂”，这时，如果客户端还没来得及切换到新主节点，还往旧主节点写数据，这部分数据就会丢失（因为旧主节点恢复后会被降为从节点，并清空自己的数据以同步新主节点）。

如何应对：

1. 合理配置超时参数：这是最关键的经验。cluster-node-timeout（集群模式）或哨兵的 down-after-milliseconds 参数不能设得太小，比如在云环境这种网络不如本地机房稳定的地方，设成30秒甚至更长可能比默认的15秒更稳妥，这给了网络抖动一定的容忍度，避免过于敏感地触发切换。
2. 最小化主节点压力：避免主节点处理过于耗时的命令（如 KEYS *）或大Value的读写，这些都会增加节点的响应时间，容易被误判为下线。
3. 客户端配置降级策略：客户端应该具备在写入失败时，自动重试或切换到备用节点的能力，而不是一直卡在旧主节点上。

第四个让人困惑的点：为什么数据没了？—— 持久化陷阱。

很多人以为用了集群,数据就万无一失了，其实不然，集群主要解决的是高可用和扩展性问题，数据安全很大程度上还得依赖持久化（RDB和AOF），如果配置不当，照样丢数据。

• 场景1：你只用了RDB，并且设置了每5分钟保存一次，如果节点在最后一次保存后第4分钟宕机，那么这4分钟内的数据就全丢了。
• 场景2：主从切换时，如果新主节点在成为主节点那一刻，它的数据不是最新的（比如它本身同步有延迟），那么它上面缺失的那部分数据也就永久丢失了。

经验分享：

1. 根据业务需求选择持久化策略：如果数据绝对不能丢，就开启AOF，并配置为 appendfsync always（每个写命令都刷盘，性能损耗大），或者至少是 appendfsync everysec，结合RDB做冷备。
2. 理解主从同步的局限性：主从复制是异步的，存在延迟窗口，对于金融等极高要求的场景，可以使用Redis的WAIT命令，强制要求写操作同步到一定数量的从节点后才返回，但这会牺牲性能。
3. 定期备份：无论如何，定期对RDB文件进行备份，并放到异地，是最基础的安全底线。

用Redis集群,不能只看到它的好处，更要敬畏这些分布式中固有的复杂性，多监控、合理配置参数、理解底层原理、做好应急预案，才能让它真正稳定地为业务服务，这些坑，希望你能提前知道，绕道而行。