为何我的Redis Sentinel集群始终可写入？Bitnami Helm Chart部署疑问

为什么每次写入都能成功？ #

Bitnami的Redis Sentinel Helm Chart默认提供的主节点Service（通常命名为{release-name}-redis）并非简单的轮询负载均衡，而是依托Sentinel的动态发现机制，始终将流量路由至当前可写入的主节点。如果你用的是这个默认Service，而非手动创建的覆盖所有Redis节点的Service，那每次连接都能写入是正常的设计，并非配置遗漏。

若你确实手动创建了包含所有Redis节点（主+从）的普通ClusterIP Service，却仍每次都能写入，大概率是以下原因：

• kubectl port-forward的端口转发是绑定到单个Pod的，不会触发Service的负载均衡逻辑，你的会话恰好一直连到了主节点
• 测试次数不足，还未轮询到从节点；可以多执行几十次写入操作，或者直接连接从节点Pod执行set命令，应该会收到READONLY You can't write against a read only replica.的错误提示

该Service能否安全用于生产负载？ #

分两种场景判断：

1. 使用Chart默认的主节点Service：完全可以安全用于生产写入流量。Sentinel会自动监控主节点状态，当主节点故障、新主节点选举完成后，Service的Endpoint会自动更新，流量会无缝切换到新主节点，无需人工介入。
2. 手动创建的覆盖所有Redis节点的普通Service：绝对不能用于生产写入流量。普通Service采用轮询负载均衡，会随机将写入请求打到从节点，导致写入失败；且主节点切换后，Service不会自动更新Endpoint指向新主节点，会持续将部分流量发往已降级为从节点的旧主，引发大量写入错误。

如果是读取流量，手动创建的全节点Service可以使用，但需在客户端层面做读写分离：写入请求必须走主节点Service，读取请求可走全节点Service来分摊压力。

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