基于Redis Cluster与微服务的Kubernetes负载均衡方案可行性问询

假设是否成立？ #

这个假设在满足两个前提条件时成立：

• Redis Cluster哈希槽为静态分配：每个K8s Node上的Redis实例被固定分配专属的哈希槽范围，未开启自动重分片功能。
• 微服务访问逻辑完全匹配哈希槽分配：请求进入某Node后，推送到的<SERVICE_PREFIX>:{CLUSTER_HASH_SLOT}列表对应的哈希槽，恰好属于该Node上Redis实例负责的范围，不存在跨实例访问的情况。

只要这两个条件落地，数据就只会留在请求进入的Node上，不会产生跨Node的Redis通信。

方案是否可行？ #

这个方案整体可行，但需要注意细节：

可行的核心逻辑 #

既然数据都留在本地Node，新增Node时只需给新的Redis实例分配新的哈希槽范围，同时调整微服务的哈希槽映射规则，让轮询到新Node的请求对应新实例的哈希槽。这样每个Node的网络流量会被均匀分摊，新增Node就能直接缓解网络包速率超限的问题，完全匹配你的需求。

需要规避的风险 #

• 禁止Redis自动重分片：一旦开启自动重分片，哈希槽可能被迁移到其他Node，直接打破数据不跨Node的假设，瞬间引发跨Node通信。
• 哈希槽映射逻辑要精准：微服务必须严格按照预设的哈希槽-Node对应关系生成列表名，不能出现计算错误导致的跨实例访问，否则会触发Redis Cluster的跨槽转发，产生额外网络流量。
• 故障转移预案要到位：如果某个Node故障，对应的哈希槽需要手动迁移到其他Node，这期间会产生跨Node数据传输，需要提前评估流量影响，或者准备备用实例承接故障节点的哈希槽，避免网络阈值被突破。

内容的提问来源于stack exchange，提问作者me_the_bo