bind应填实际用于集群通信或客户端访问的所有本机IPv4/IPv6地址，如192.168.1.10 192.168.2.10 ::1 2001:db8::100，不可只写127.0.0.1或漏掉业务网卡IP，且cluster-announce-ip必须与之匹配并确保其他节点可TCP直连。
bind 应该填哪些 IP，而不是“要不要填 0.0.0.0”
bind 不是让你选“开放还是不开放”，而是明确告诉 Redis：“用哪几张网卡对外提供服务”。多网卡环境下，bind 必须列出所有**实际用于集群通信或客户端访问的本机 IPv4/IPv6 地址**，不能只写 127.0.0.1 或漏掉某张内网卡 IP。
常见错误现象：客户端连得上 192.168.1.10 却连不上 192.168.2.10；或者集群节点间 CLUSTER NODES 显示部分节点地址为 127.0.0.1:6379，导致重定向失败。
- 查本机所有可用 IPv4：运行
ip -4 addr show | grep 'inet ' | awk '{print $2}' | cut -d/ -f1 - 排除 loopback（如
127.0.0.1）和 Docker/K8s 虚拟网段（如172.17.0.1），只保留真实业务网卡 IP - 若需同时支持 IPv6，加
::1和对应公网/内网 IPv6 地址（如2001:db8::100） - 示例配置：
bind 192.168.1.10 192.168.2.10 ::1 2001:db8::100
cluster-announce-ip 必须与实际可达地址一致，且≠ bind 值
cluster-announce-ip 是集群节点向其他节点“自我介绍”的地址，它决定 CLUSTER NODES 输出里显示什么 IP。这个值必须是其他节点能直接 TCP 连通的地址，和 bind 没有强制相等关系——但一旦不一致，就会出现握手成功却后续不可达的问题。
使用场景：双网卡机器中，一张卡走管理流量（192.168.1.10），另一张卡专供集群总线通信（192.168.2.10）。此时 bind 应包含两者，而 cluster-announce-ip 必须设为 192.168.2.10，否则其他节点尝试连 192.168.1.10 的总线端口会超时。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 验证方式：在节点 A 上执行
telnet 192.168.2.10 16379（即cluster-announce-port + 10000），必须通 - 若用 Docker，
cluster-announce-ip应填容器网络中其他节点能路由到的 IP，不是host.docker.internal或localhost -
cluster-announce-bus-port必须显式设置，不能依赖默认偏移量，尤其当防火墙策略限制端口范围时
protected-mode yes 和 requirepass 的组合才是安全底线
设了多个 bind IP 后，protected-mode yes 仍有效——它只在以下任一条件满足时拦截连接：bind 未配置、仅含 127.0.0.1 且无密码、或含 0.0.0.0 但没设 requirepass。所以多网卡环境里，只要写了具体 IP（不含 0.0.0.0），protected-mode 就不会自动拒绝，但也不代表安全。
- 必须配
requirepass，否则任意能连上的客户端都可执行CONFIG SET或FLUSHALL - 不要为了“省事”关掉
protected-mode，这等于放弃 Redis 内置的最小防护层 - 云环境建议配合安全组/iptables，只放行指定源 IP 段对
6379和16379的访问
启动后必须验证三件事，缺一不可
改完 redis.conf 并重启后，光看 redis-cli ping 成功远远不够。集群通信是否真正就绪，取决于底层网络连通性与宣告一致性。
- 执行
redis-cli CLUSTER NODES，检查所有节点 IP 是否为你设定的cluster-announce-ip，且状态为connected - 在每个节点上用
telnet <其他节点 cluster-announce-ip> <cluster-announce-bus-port>测试双向连通性 - 用
redis-cli -h <本节点 announce-ip> -p <port> INFO replication确认主从关系正常，没有master_link_status:down
最容易被忽略的是 bus 端口的双向连通性——很多团队只测了客户端端口（6379），却没验证 16379 是否也通，结果集群看似启动成功，但故障转移永远触发不了。
