我是 Redis 新手。我在Sentinel 和Replication 上阅读了他们的文档，其中讨论了副本如何尽可能地与主服务器保持同步，但是如果主服务器在成功写入后失败，则副本仍然有可能可能不会收到该写入。如果 Sentinel 然后将此副本标记为新的主节点，则该副本可能会提供陈旧的数据。
如果我不能承受失去一致性并且更喜欢它而不是可用性，我该如何关闭复制，以便当 Sentinel 将新副本标记为主副本时，所有第一个请求都将是缓存未命中，并且我的缓存可以慢慢预热而不是返回可能过时的数据？
另外，这是个好主意吗？还有其他好的选择吗？
【问题讨论】：
标签： redis redis-sentinel
我不能失去一致性，我更喜欢它而不是可用性
目前尚不清楚 redis 自动故障转移是否适合您的应用程序。看起来每个客户端都需要仔细跟踪服务器的可用性。
假设您有几个客户端，一个主服务器 M1 和三个副本 R2、R3、R4。客户端 C5 向 M1 写入新的银行账户余额，立即永久失败，R2 被提升为主 M2。 Master 在回复客户端之前没有从副本获得确认。在将回复发送到 C5 之前，服务器之间不会发生类似 paxos 的共识协议。
C5 可以记住嵌入在每个写入请求中的计数器/时间戳，忘记写入负载，并检测过时的读取。但是客户端 C6 不能，除非您在协议之外快速可靠地提供此类数据。 Nathan Fritz 观察到您的应用程序可能会发出写入，然后发出 PUBLISH 事件，并使用 LISTEN 监控该事件的多个副本，从而延迟向最终用户报告成功。如果需要虚拟同步的可靠承诺，请考虑将derecho 合并到您的应用程序中。 redis 的生产版本针对的是问题空间的不同部分，而不是您的主要兴趣。
【讨论】：