使用消息隊列和協調服務的設計系統

Question

我是設計系統的新手，對消息隊列和協調服務（zookeeper）有一些疑問。

這將是巨大的，如果有人可以澄清這些概念： -

我在我設計的系統MQ的理解： -

我將生產性服務，這將創建消息，並加入到MQ。消費者將使用此消息並執行相應的操作。一旦消費者ACK完成消息處理， MQ會將偏移量移至下一個偏移量。我不希望我的郵件被錯過，所以我必須確保郵件成功使用。此外，我試圖讓這個系統消耗一次消息（嘗試儘可能接近）。

現在我基於這樣的認識以下幾個問題： -

1）如果我想我在同一個DC生產者和消費者要運行多個實例（高可用性），那麼我需要有生產者和消費者都是獨立的Zookeeper服務？我的所有不同的服務（在微服務世界中）是否都需要單獨的zookeeper服務器/實例，或者同一個實例可以解決這個問題？

2）當消費者使用消息時，它會在消費完消息後對其進行確認（完成處理並採取任何所需的操作）。我想了解一個系統每秒鐘會有幾千個請求的速度會如何加快。如果我們讀取更多的消息或不等待ACK直到處理，那麼在消費者失敗的情況下，這些消息將被錯過，因爲它們從未成功處理過。我知道擁有更多的消費者將會使其同時工作，但我不清楚這個概念是如何工作的。有人可以向我解釋什麼是消費和配置組件之間的交互的正確方式，以使其優化以及持久性，高可用性，可靠性以及關閉到一次模型。

編輯：我打算在系統中使用Java，Zookeeper，Kafka，Cassandra。

Answer 1

與任何消息傳遞系統一樣，消息隊列可以以兩種基本模式工作：至少一次交付或至多一次交付。兩者都爭取一次交付，但我們在這裏討論邊緣案例。你將不得不選擇其中之一。如果生產者和消費者（包括生產者 - 生產者和消費者 - 消費者）之間的所有通信都通過消息隊列，那麼只有消息隊列需要動物園管理員羣集。通過單個系統集中所有消息傳遞是這樣做的首選方式。

您是否瞄準一次交貨，因爲兩次做同樣的工作是浪費時間，或者是因爲如果您兩次做同樣的事情，所有東西都燃燒到地面上，這會造成浪費？

如果前者，建立一些簡單。消息隊列本身可以跟蹤這一點，因爲它會停止詢問新的消費者使用任務，一旦他們中的一個迴應了結果，或者如果存儲必須更持久一些，則使用redis或couchbase或cassandra或一些簡單的鍵/值存儲來存儲已成功完成的事情。記下您發出的請求，但沒有收到內存中的答案。在數據庫中存儲「此操作已完成」註釋。

如果是後者，那麼設計這個系統的時間會更加困難。您需要能夠判斷某個進程是否崩潰，或者是否比平時耗時更長。您還需要繼續留下它，可能再次從事這項工作。如果更新類似增加10個不同的計數器，則再次執行更新可能會使計數器增加一倍。