GKE中通过Helm部署Redis后的服务连接及读写架构疑问

先给你明确下这三个Service的核心角色，搞懂这个你就明白为啥会碰到那个问题了：

• redis-master：这个Service专门指向唯一的可写主节点，所有需要写入Redis的操作都得往这儿发，读操作也能在这儿执行。
• redis-slave：这个Service会把请求负载均衡到所有只读的从节点上，专门用来承接读请求。
• redis-headless：这是个无头服务，不会做负载均衡，而是直接返回所有Redis节点（主+从）的Pod IP。你用它连接时，客户端会随机选一个IP——假设你是1主2从的架构，选到从节点的概率就是2/3，这就是为啥你有66%的概率碰到READONLY报错，从节点根本不允许写操作嘛。

接下来逐个解答你的疑问：

1. 是否只能连接redis-master？ #

当然不是，得分操作类型来看：

• 要是你做写操作（比如SET、HSET、DEL这类），那必须连redis-master，因为只有主节点有写入权限，从节点都是只读的。
• 要是你做读操作（比如GET、LRANGE、INFO这类），完全可以连redis-slave，让从节点来扛读流量，减轻主节点的压力；或者你也可以自己通过redis-headless定位到主节点再连接，但这种方式一般没必要，直接用redis-slave更省心。

2. 从节点是否会被使用？ #

必须会啊！从节点的核心价值就是分担主节点的读请求，尤其是读多写少的业务场景，把读请求分流到从节点能大幅提升整个Redis集群的吞吐量，避免主节点因为读请求过多而性能下降。

不过默认情况下，Helm Chart不会帮你自动做读写分离的路由——这事儿得你在应用层面处理：比如在代码里区分读写操作，写请求发往redis-master，读请求发往redis-slave；或者用支持主从感知的Redis客户端，让客户端自动把读请求路由到从节点，写请求路由到主节点。

3. 主节点故障时是否会自动切换？ #

这取决于你部署Helm Chart时有没有启用哨兵模式（Sentinel）。默认情况下，很多主流的Redis Helm Chart（比如Bitnami的Redis Chart）的主从模式是不带自动故障转移的——也就是说，如果主节点挂了，从节点不会自动升级为主节点，redis-master Service也不会自动指向新的主节点，这时候你的写请求就会全部失败。

如果想要主节点故障后自动切换，你需要在部署Chart的时候开启哨兵组件。启用哨兵后，哨兵集群会持续监控主节点的状态，一旦主节点挂了，就会自动选举一个从节点升级为主节点，同时更新相关的Service指向，确保你的应用能无缝连接到新的主节点。

4. 是否应该路由到从节点处理读请求？ #

非常推荐这么做！这是Redis主从架构最核心的优化点之一：

• 能有效减轻主节点的负载，让主节点专注于处理写操作，避免因为大量读请求拖慢写性能。
• 多个从节点可以同时处理读请求，大幅提升整体的读吞吐量。

具体的实现方式可以参考这几种：

• 在应用代码里做读写分离：写请求统一发往redis-master，读请求统一发往redis-slave。
• 使用支持主从分离的Redis客户端：比如Java的Lettuce、Jedis，Python的redis-py等，配置好主从地址后，客户端会自动把读请求路由到从节点。
• 要是启用了哨兵，客户端可以通过哨兵集群自动获取主从节点的信息，动态调整路由，还能自动应对主节点故障的情况。

最后再给你总结下：

• 写操作必须走redis-master；
• 读操作优先走redis-slave实现分流；
• 如需自动故障转移，一定要启用哨兵模式；
• redis-headless适合需要直接访问所有节点的场景（比如自定义监控、特殊路由逻辑），不适合直接用来处理业务的读写请求。

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