Redis 哨兵在选举期间的写请求处理

当 Redis master 节点宕机时，哨兵系统将启动选举流程来选择新的 master 节点。在此期间，可能会出现写请求到达剩余的从属节点的情况。

对于如何处理这些写请求，解决方案取决于具体业务类型：

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

• 可以直接通知用户：对于某些业务，可以暂停对新写请求的响应，并通知用户在选举完成后重试。
• 自动重试：对于其他业务，API 可以在一段时间内自动重复请求，在此期间用户可能会体验到延迟。
• 存储在消息队列中：如果业务允许延迟，则可以将写请求存储在消息队列中，并在选举完成后再重新尝试。

具体选择哪种解决方案取决于业务的性质和优先级。

例如：

• 对于一个实时聊天应用，可能有必要立即处理新的消息。因此，可以直接丢弃选举期间到达的写请求，并在选举完成后通知用户。
• 对于一个电子商务网站，可能可以延迟订单处理。因此，可以将写请求存储在消息队列中，并在选举完成后再尝试。
• 对于一个金融交易系统，可能需要立即处理所有写请求。因此，可以使用自动重试机制来确保写请求的最终一致性。