我在这里阅读了很多帖子并在网上冲浪，但也许我没有问对正确的问题。我知道 Redis 目前是主/从，直到集群可用。但是，我想知道是否有人可以告诉我如何从逻辑上配置 Redis 以满足我的需求（或者它是否不是正确的工具）。
场景：
我们在美国的两端有 2 个站点。我们希望客户能够在每个站点进行大量写作。然后，我们希望每个客户端也能够在他们的站点上执行读取。但是，我们希望在小于 50 毫秒的时间内从姊妹站点写入数据。鉴于我们有足够的带宽。有没有办法配置redis来满足我们的需求？我们的写入最大大小通常在 5k 左右，通常要小得多。要点是，即使默认情况下不支持，我如何才能拥有 2 个彼此同步的主控。
【问题讨论】：
标签： redis
汤姆回答的问题是您没有运行任何类型的集群，您只是在写入两台服务器。如果要确保它们之间的一致性，这是一个问题。考虑当您的客户端无法写入远程服务器时会发生什么。您是否撤消对本地的写入？当您无法写入远程服务器时，应用程序会发生什么？当您无法从本地读取时会发生什么？
第二个问题是约书亚提出的基本物理问题。对于往返，您所说的理论最小值为 38 毫秒，而两端（三个系统）的理论最大处理时间为 12 毫秒。我会说期望有点过高，在这种情况下，带宽与延迟无关。你可以有一个 10GB 的管道，这些时间仍然存在。也就是说，在 12 毫秒内跨大陆传输 5k 也要求很多。你确定你有在 50 毫秒内传输 5k 数据的连接能力，更不用说 12 了吗？我一直在整个大陆的私人不使用电路上看到 ping 时间超过 50 毫秒 - 而且 ping 没有传输 5k 的数据。
您将如何使两个不相关的服务器保持同步？如果您确实需要跨大陆的低于 50 毫秒的延迟，那么上述理论上的最佳情况意味着您有 12 毫秒的时间来运行同步算法。即使是检查另一台服务器上数据的查询也意味着您超出了 50 毫秒窗口。如果数据不同步，您将如何解决？鉴于上述时间，我看不出如何在 50 毫秒内同步。
我建议重新审视基本设计要求。具体来说，为什么有这个要求？跨大陆往返 50 毫秒的延迟要求通常是营销的标志或缺乏对细节的关注。我敢打赌，如果您分析需求，您会发现这个 50 毫秒的窗口是过多且不必要的。如果不是，并且数据同步实际上很重要（很可能），那么有人将需要确定编写同步代码的大量额外工作是否值得，甚至是否可以保持在 50 毫秒的窗口内。跨大陆延迟低于 50 毫秒的数据同步不是一个简单的问题。
如果您不需要同步，为什么不简单地运行一台服务器呢？你可以在大陆的另一边使用奴隶来进行恢复。当然，这仍然意味着最好的情况是您有 12 毫秒的时间来获取数据。我不会指望 50ms 往返操作+延迟+5k/10k 跨大陆数据传输。
【讨论】：
以光速穿越美国大约需要 19 毫秒。
http://www.wolframalpha.com/input/?i=new+york+to+los+angeles
【讨论】：
这可能最好作为客户端的一部分处理 - 只需让客户端写入两个节点即可。写入通常不需要同步，因此发送额外的命令不会影响您从本地节点获得的性能。
【讨论】：