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