不能直接升级所有节点内核，因内核版本差异会导致epoll行为、transparent_hugepage策略、net.core.somaxconn等参数不一致，引发连接拒绝、延迟毛刺或集群握手失败。
Redis 集群本身不依赖系统内核版本做功能适配，升级内核不会直接触发 Redis 服务变更，但滚动更新节点时若涉及重启、重装或容器重建，就可能暴露内核兼容性问题——比如 epoll 行为差异、transparent_hugepage 默认策略变化、或 net.core.somaxconn 等参数在新内核中默认值调整，都会间接导致连接拒绝、延迟毛刺甚至集群握手失败。
为什么不能直接升级所有节点的内核？
Redis 集群节点间通过 CLUSTER MEET、CLUSTER NODES 交换拓扑信息，这些通信底层走 TCP + 自定义二进制协议。不同内核版本对 socket 队列、TIME_WAIT 处理、TCP fast open 支持程度不一。例如：
- Linux 5.10+ 默认启用
tcp_fastopen，而旧版 Redis 客户端（如 Jedis 3.x）未显式设置TCP_FASTOPENsocket 选项，可能导致握手超时 - 某些云厂商定制内核（如 Alibaba Cloud Kernel 5.10-aliyun）禁用
net.ipv4.tcp_tw_reuse，若集群节点混跑新旧内核，部分节点会因 TIME_WAIT 积压无法建立足够连接数 -
transparent_hugepage在内核 6.1 后默认改为madvise模式，但 Redis 进程若未显式调用madvise(MADV_NOHUGEPAGE)，仍可能被强制合并页表，引发内存抖动
滚动升级内核前必须验证的三项配置
不是“升级完 reboot 就行”，而是每台节点 reboot 后要确认以下三处是否与集群其他节点一致：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
/proc/sys/net/core/somaxconn：必须 ≥ 65535。Redis 6.2+ 启动时若检测到该值 -
/sys/kernel/mm/transparent_hugepage/enabled：必须为never。哪怕内核默认是madvise，也要显式设成never，否则redis-server启动日志会出现WARNING you have Transparent Huge Pages (THP) support enabled... -
/proc/sys/vm/overcommit_memory：必须为1。Redisfork()子进程做 RDB 时依赖此设置，内核 5.15+ 某些发行版默认为0，会导致Can't save in background: fork: Cannot allocate memory
如何安全执行单节点内核滚动升级
关键不是“怎么升内核”，而是“升完怎么让 Redis 继续被集群识别”。操作顺序不能错：
- 先在目标节点执行
redis-cli -a <password> -h 127.0.0.1 -p 7001 CLUSTER NODES | grep myself</password>，确认当前角色是slave；如果不是，用CLUSTER FAILOVER主动降级（避免升级主节点时触发槽位迁移） - 停掉 Redis：
systemctl stop redis@7001，再uname -r记录旧内核版本，然后升级内核、reboot - 重启后立刻检查上述三项 sysctl 参数，用
sysctl -w临时修正，并写入/etc/sysctl.d/99-redis.conf持久化 - 启动 Redis：
systemctl start redis@7001，立刻连上去执行INFO SERVER看redis_version和os字段，确认没回退到旧二进制 - 最后运行
redis-cli --cluster check 127.0.0.1:7001，重点看输出里有没有[OK] All nodes agree about slots configuration.—— 如果出现FAIL: Not all 16384 slots are covered，说明该节点虽在线，但未被其他节点识别为有效成员，大概率是内核级网络参数不一致
最容易被忽略的是：升级完内核后，systemd 可能因 unit 文件里写了 ConditionKernelCommandLine= 或 ConditionPathExists= 而跳过启动 Redis 服务；或者容器环境里，镜像 base 镜像内核版本未同步更新，导致 docker run 启动失败却报错模糊。务必在每台节点 reboot 后手动验证 Redis 进程状态和集群视角可见性，而不是只看 systemctl 是否 active。
