現在我們構建了一個實時分析系統，它應該是高度分布式的。我們計劃使用分布式鎖和計數器來保證數據的一致性，我們需要某種分布式映射來知道哪個客戶端連接到哪個服務器。我之前沒有分布式系統方面的經驗，但我認為我們有兩個選擇：Java+HazelcastGolang+ETCD但是在主題上下文中彼此的優缺點是什么？
2 回答
汪汪一只貓
TA貢獻1898條經驗 獲得超8個贊
Hazelcast 和 etcd 是兩個非常不同的系統。原因是CAP定理。
CAP 定理指出，任何分布式系統都不能具有一致性、可用性和分區容錯性。分布式系統通常更接近 CA 或 CP。Hazelcast 是一個 AP 系統，而 etcd（作為 Raft 實現）是 CP。因此，您的選擇是在一致性和可用性/性能之間。
一般來說，Hazelcast 會比 Raft 和 etcd 性能更高，能夠處理更多的故障，但代價是潛在的數據丟失或一致性問題。Hazelcast 的工作方式是對數據進行分區并將數據片段存儲在不同的節點上。因此，在 5 個節點的集群中，鍵“foo”可能存儲在節點 1 和 2 上，而 bar 可能存儲在節點 3 和 4 上。您可以通過 Hazelcast 和 map 控制 Hazelcast 將數據復制到的節點數量配置。但是，在網絡或其他故障期間，您可能會在 Hazelcast 中看到舊數據甚至丟失數據。
或者，Raft 和 etcd 是一個單領導高度一致的系統，將數據存儲在所有節點上。這意味著它不適合存儲大量狀態。但即使在網絡故障期間，etcd 也可以保證您的數據保持一致。換句話說，您永遠不會看到舊的/過時的數據。但這需要付出代價。CP 系統要求集群的大部分都處于活動狀態才能正常運行。
一致性問題可能與基本鍵值存儲相關，也可能不相關，但它可能與鎖極為相關。如果你希望你的鎖是整個集群一致-這意味著只有一個節點甚至可以在網絡或其他故障持有鎖-千萬不能使用Hazelcast。因為 Hazelcast 犧牲了一致性來支持可用性（再次參見 CAP 定理），所以網絡故障完全有可能導致兩個節點相信可以免費獲取鎖。
或者，Raft 保證在網絡故障期間只有一個節點將保持 etcd 集群的領導者，因此所有決策都通過該節點做出。這意味著 etcd 可以保證它始終具有一致的集群狀態視圖，并且可以確保像鎖這樣的東西只能由單個進程獲取。
真的，你需要考慮你在數據庫中尋找什么并去尋找它。CP 和 AP 數據存儲的用例大不相同。如果您希望存儲少量狀態、一致鎖、領導選舉和其他協調工具的一致性，請使用像 ZooKeeper 或 Consul 這樣的 CP 系統。如果您希望以潛在的一致性代價獲得高可用性和性能，請使用 Hazelcast 或 Cassandra 或 Riak。
- 2 回答
- 0 關注
- 371 瀏覽
添加回答
舉報
0/150
提交
取消