大家好！
開始翻譯一本小書：
««，
作者：Jakub Korab，出版商：O'Reilly Media, Inc.，出版日期：2017 年 9781492049296 月，ISBN：XNUMX。
從本書的介紹：
“... 本書將通過比較和對比兩種流行的代理技術：Apache ActiveMQ 和 Apache Kafka，教您如何思考代理消息系統。 它將概述使用案例和開發激勵措施，這些用例和開發激勵措施導致他們的開發人員對系統之間的代理消息傳遞的同一領域採取截然不同的方法。 我們將從頭開始審視這些技術，並在此過程中強調不同設計選擇的影響。 您將深入了解這兩種產品，了解它們應該如何使用和不應該如何使用，並了解在未來考慮其他消息傳遞技術時需要注意什麼。 ...“
目前翻譯的部分：
我將在翻譯完成的章節後發布它們。
第1章
介紹
系統間消息傳遞是 IT 領域中了解最少的領域之一。 作為開發人員或架構師，您可能對各種框架和數據庫非常熟悉。 但是，您很可能只瞥見了基於代理的消息傳遞技術的工作原理。 如果那是你的感受，別擔心，你有很好的陪伴。
人們通常與消息傳遞基礎設施的接觸非常有限。 他們通常會連接到很久以前創建的系統，或者從 Internet 下載分發包，將其安裝到 PROM 中並開始為其編寫代碼。 一旦基礎設施在 PROM 中啟動並運行，結果可能會喜憂參半：消息在崩潰時丟失，發送不按預期工作，或者代理掛起您的生產者或不向您的消費者發送消息。
聽起來很熟悉？
一種常見的情況，您的消息傳遞代碼暫時可以正常工作。 直到它停止工作。 這段時間會降低警惕並給人一種錯誤的安全感，從而導致更多代碼基於對技術基本行為的錯誤想法。 當事情開始出錯時，你會面臨一個令人不安的事實：你真的不了解產品的潛在行為，或者作者選擇的權衡，例如性能與健壯性，或交易與交易. 水平可擴展性。
在不深入了解代理如何工作的情況下，人們會對他們的消息系統做出看似合理的聲明，例如：
- 系統永遠不會丟失消息
- 消息將按順序處理
- 添加消費者將使系統更快
- 消息只會發送一次
不幸的是，其中一些陳述基於僅在特定情況下適用的假設，而其他陳述則根本不正確。
本書將通過比較和對比兩種流行的代理技術：Apache ActiveMQ 和 Apache Kafka，教您如何推理代理消息系統。 它將概述使用案例和開發激勵措施，這些用例和開發激勵措施導致他們的開發人員對系統之間的代理消息傳遞的同一領域採取截然不同的方法。 我們將從頭開始審視這些技術，並在此過程中強調不同設計選擇的影響。 您將深入了解這兩種產品，了解它們應該如何使用和不應該如何使用，並了解在未來考慮其他消息傳遞技術時需要注意什麼。
在我們開始之前，讓我們回顧一下基礎知識。
什麼是消息系統以及為什麼需要它
為了讓兩個應用程序相互通信，它們必須首先定義一個接口。 此接口的定義包括傳輸或協議（如 HTTP、MQTT 或 SMTP）的選擇，以及系統將交換的消息格式的協商。 這可以是一個嚴格的過程，例如定義一個 XML 模式，其中包含消息的負載成本要求，也可以是不那麼正式的過程，例如兩個開發人員之間的協議，即 HTTP 請求的某些部分將包含客戶端標識符。。
只要消息的格式和發送的順序在系統之間保持一致，它們就可以相互通信而不用擔心對方系統的實現。 這些系統的內部結構，例如所使用的編程語言或框架，可能會隨著時間而改變。 只要合約本身得到維護，交互就可以在另一端繼續保持不變。 這兩個系統通過這個接口有效地解耦（分離）。
消息傳遞系統通常涉及兩個系統之間的中介，這兩個系統交互以進一步分離（分離）發件人與收件人或收件人。 在這種情況下，消息傳遞系統允許發件人在不知道收件人位於何處、他是否處於活動狀態或他們的實例有多少的情況下發送消息。
讓我們看一下消息傳遞系統解決的各種問題的幾個類比，並介紹一些基本術語。
點對點
亞歷山德拉去郵局給亞當寄包裹。 她走到窗口，將包裹遞給員工。 員工拿起包裹並給亞歷山德拉一張收據。 寄出包裹時，亞當不需要在家。 Alexandra 確信包裹會在未來的某個時間交付給 Adam，並且可以繼續開展她的業務。 後來，在某個時候，亞當收到了一個包裹。
這是消息傳遞模型的示例 點對點. 郵局在這裡充當包裹分發機制，確保每個包裹都派送一次。 郵局的使用將發送包裹的行為與交付包裹的行為分開。
在經典消息系統中，點對點模型是通過 隊列. 隊列充當一個或多個消費者可以訂閱的 FIFO（先進先出）緩衝區。 每條消息僅發送 訂閱的消費者之一. 隊列通常會嘗試在消費者之間公平地分發消息。 只有一個消費者會收到此消息。
術語“持久”適用於隊列。 可靠性 是一個服務屬性，它保證消息傳遞系統將在沒有活動訂閱者的情況下保留消息，直到消費者訂閱消息傳遞隊列。
可靠性經常與 堅持 而且，儘管這兩個術語可以互換，但它們執行不同的功能。 持久性決定了在接收消息和將消息發送給消費者之間消息系統是否將消息寫入某種存儲。 發送到隊列的消息可能持久也可能不持久。
當用例需要對消息執行單個操作時，將使用點對點消息傳遞。 示例包括將資金存入帳戶或完成交貨訂單。 稍後我們將討論為什麼消息傳遞系統本身無法提供一次性交付，以及為什麼隊列充其量只能提供交付保證。 至少一次.
發布者-訂閱者
加布里埃拉撥了會議號碼。 當她連接到會議時，她會聽到發言人和其他通話參與者所說的一切。 當她昏過去時，她會想念剛才說的話。 重新連接時，她繼續聽到所說的話。
這是消息傳遞模型的示例 發布-訂閱. 電話會議充當廣播機制。 正在通話的人不關心當前有多少人在通話 - 系統確保當前連接的任何人都能聽到所說的內容。
在經典消息系統中，發布-訂閱消息模型是通過 最高額. 主題提供與會議機制相同的廣播方法。 當消息發佈到主題時，它被分發 對於所有訂閱用戶.
話題通常 不可靠的（非耐用的）. 就像聽眾在電話會議上聽不到談話內容一樣，當聽眾離線時，主題訂閱者會錯過離線時發送的任何消息。 出於這個原因，我們可以說毛條提供了交貨保證。 不超過一次 為每一位消費者。
當消息本質上是信息性的並且單個消息的丟失不是特別重要時，通常使用發布-訂閱消息傳遞。 例如，一個主題可以每秒傳輸一次來自一組傳感器的溫度讀數。 對當前溫度感興趣並訂閱主題的系統不會擔心錯過消息 - 另一條消息很快就會到達。
混合動力車型
商店網站將訂單消息放入“消息隊列”。 這些消息的主要消費者是執行系統。 此外，審計系統必須有這些訂單消息的副本以供以後跟踪。 兩個系統都不會錯過消息，即使系統本身在一段時間內不可用也是如此。 該網站不應該知道其他系統。
用例通常需要混合使用發布-訂閱和點對點消息傳遞模型，例如當多個系統需要消息副本並且需要可靠性和持久性以防止消息丟失時。
在這些情況下，需要一個目的地（隊列和主題的總稱），它基本上像主題一樣分發消息，以便將每個消息發送到對這些消息感興趣的單獨系統，但每個系統也可以在其中定義多個消費者接收傳入消息，更像是一個隊列。 這種情況下的閱讀類型是 - 每個利益相關者一次. 這些混合目的地通常需要持久性，以便在消費者斷開連接時，在消費者重新連接時接受當時發送的消息。
混合模型並不新鮮，可以應用於大多數消息系統，包括 ActiveMQ（通過結合主題和隊列的虛擬或複合目標）和 Kafka（隱含地，作為其目標設計的基本屬性）。
既然我們已經掌握了一些基本術語，並且了解了消息系統的用途，那麼讓我們進入細節。
翻譯完成：
下一個翻譯部分：
待續...
來源： www.habr.com