我想知道紀事圖中的原子性語義。如果我有一個跨2個節點（服務器）共享的歷史記錄映射，並且我嘗試在兩個節點上同時將相同的密鑰插入此映射，那麼事務性語義是什麼？編年史圖原子性語義
第一次成功，第二次失敗？
我很好奇，如果Chronicle Map保證Apache Zookeeper具有相同的事務語義？
在我的用例中，我想依賴的事實是，如果node1將密鑰K1放入地圖中，則該節點2將能夠檢查K1的存在，如果不存在，它會明確地知道它是第一個添加K1的。
實際上，詢問ChronicleMap是否是分佈式事務，跨越2個節點。
非常感謝 克利福德
紀事地圖使用最終一致性，最後一個獲勝。當你觀察微秒時間尺度時，節點處於裂腦節點中，因爲無法以這種速度保持它們同步。 這是設計的，因爲Map旨在支持每臺服務器每秒數百萬次更新。 通常，在正常操作下不難確保兩臺服務器不會同時更新相同的密鑰。例如。您可以使用引擎將所有更新傳遞給一臺服務器，也可以對密鑰進行分區以進行更新。 雖然分佈式事務聽起來像是一個好主意，但您應該注意到; - 它們慢很多個數量級， - 從分裂大腦等失敗時很難恢復。 - 測試您的應用程序在不同的故障條件下正常工作是一個真正的痛苦。
我認爲我們最好設計一個不需要這個假設的系統，並且你會知道它在未經過廣泛測試的情況下如何表現失敗。
假設您將zookeeper安裝到三個數據中心，並確保一個數據中心的故障不會通過確保沒有數據中心具有一半或更多節點（兩個數據中心不夠）而停止運行，但是假設您有臨時拆分大腦由緩慢的互連引起，這會影響任何更新，但是以瞬間難以重現或測試的方式。 使用歷史記錄地圖，數據中心可以在任何時間斷開連接，並且所有的保證都得到遵守，您無需進行額外的測試。事實上，除了一個節點之外，您可能會失去所有節點，並仍然完全運行
感謝Peter的詳細回覆。我的訂單可以發送到3個出網關中的任何一個，以最終交付給ECN（這是爲了確保高可用性）。我試圖保證第一個接收訂單的網關是將其發送給交易所的網關，而另一個網關則不應該這樣做。我將爲Chronicle添加唯一的訂單ID，並且在發送訂單前，所有3個網關檢查是否存在此訂單ID。根據你上面的建議，你對如何實現這一目標有任何建議嗎？ Chronicle Map是否合適？ – cliff