我一直在閱讀這裏的很多帖子和網上衝浪，但也許我沒有問正確的問題。我知道Redis目前是Master/Slave，直到Cluster成爲可用。但是，我想知道是否有人能告訴我如何在邏輯上配置Redis來滿足我的需求（或者如果它不是正確的工具）。Redis模仿MASTER/MASTER？或者是其他東西？
Scenerio：
我們在美國的兩端有兩個站點。我們希望客戶能夠在每個網站大量寫入。然後我們希望每個客戶都能夠在他們的網站進行閱讀。但是我們希望數據可以在姊妹站點的寫作時間爲012ms50ms。鑑於我們有足夠的帶寬。有沒有辦法配置redis來滿足我們的需求？我們寫入的最大大小通常大約爲5k的量級。主要的一點是我如何讓2個主設備即使在默認情況下不支持同步到另一個主設備。
與湯姆的回答的缺點是，你沒有運行任何類型的集羣，你只是寫兩個服務器。如果你想確保它們之間的一致性，這是一個問題。考慮當你的客戶端寫入遠程服務器失敗時會發生什麼。你撤消寫入本地？當您無法寫入遠程服務器時，應用程序會發生什麼？當你不能從當地讀書會發生什麼？
第二個問題是約書亞提出的基本物理問題。對於往返行程，您所講的理論最小值爲38ms，兩端（三個系統）的理論最大處理時間爲12ms。我想說的是，期望值有點過高，在這種情況下，帶寬與延遲無關。你可以有一個10GB的管道，這些時間仍然存在。也就是說，在12ms內跨越整個大陸轉移5k的數量也是非常重要的。你確定你有連接能力在50ms內傳輸5k數據，更不用說12位了嗎？我一直在使用非洲大陸的私有無用電路，並且ping時間超過50毫秒 - 而ping不會傳輸5k數據。
如何讓兩臺不相關的服務器保持同步？如果您真的需要整個大陸的延遲低於50ms，上述理論上的最佳情況意味着您有12ms運行同步算法。即使只有一個查詢檢查另一臺服務器上的數據意味着你在50ms窗口之外。如果數據不同步，您將如何解決？鑑於上述時間，我不明白如何在50ms以內同步。
我會建議重新審視基本的設計要求。具體來說，爲什麼這個要求？跨大陸50ms往返時間的延遲需求通常是市場營銷或對細節缺乏關注的標誌。我敢打賭，如果你分析需求，你會發現這個50毫秒的窗口是過度和不必要的。如果不是這樣，並且數據同步實際上很重要（有可能），那麼比有人需要確定編寫同步代碼的重要額外工作是否值得甚至可能保持在50ms窗口內。跨大陸低於50毫秒的延遲數據同步不是一個簡單的問題。
如果你不需要同步，爲什麼不簡單地運行一臺服務器？您可以使用非洲大陸另一邊的奴隸進行恢復。當然，這仍然意味着最好的情況下你有12ms的時間來獲取數據。我不會指望 跨大陸的50ms往返行程+延遲+ 5k/10k數據傳輸。
這可能是作爲客戶端的一部分處理最好的方法 - 只需將客戶端寫入兩個節點即可。寫入通常不需要同步，所以發送額外的命令不應該影響從本地節點獲得的性能。
以光速穿過美國約19ms。 < 50ms將很難實現。
http://www.wolframalpha.com/input/?i=new+york+to+los+angeles
我想說，感謝您花時間寫下所有這些。我認爲提出的問題也許只是爲了避免使用新事物的想法而提出一些不可能的（不確定的）問題。問題是，我們有多個地點，希望用戶寫信給離他們最近的主人，然後有一個流程來確保兩個地點之間存在實時（儘可能快）的一致性。你有一個可能適合這種情況的建議嗎？ – DvideBy0
我會問哪一個是更重要的方面，近端寫入或近端讀取。最快的可能是單主機和本地讀奴隸。你是閱讀密集型還是書寫密集型，或者大約50-50？如果您已經擁有數據中心站點，我會將單個主站啓動並運行測試。多碩士，尤其是跨大陸遠非易事。幸運的是，在大多數情況下，它並不是真正需要的。我會建立一個測試集並探討它是否可以驗證案例。如果有更簡單更強大的方法，請不要關注multimaster。我懷疑1Master和分佈式的奴隸會爲你工作。 –