比較Apache Kafka與各大雲端計算的分散式日誌技術 - scottlogic

banq發表於2022-03-22
ApacheKafka分散式

Apache Kafka、Amazon Kinesis、Microsoft Event Hubs 和 Google Pub/Sub 等分散式日誌技術在過去幾年中已經成熟，並且在為某些用例移動資料時新增了一些很棒的新型解決方案。
據IT Jobs Watch稱，自去年以來，使用[url=https://www.itjobswatch.co.uk/jobs/uk/kafka.do]Apache Kafka[/url]的專案的職位空缺增加了 112%；與去年同期相比， 使用Active MQ釋出的職位減少了 43%。Rabbit MQ是傳統訊息代理的更現代版本，並有效地實現了 AMQP，但在招聘廣告方面僅增加了 22%。我懷疑實際上許多傳統訊息代理服務不佳的用例已經非常迅速地轉移到分散式日誌技術，並且許多傳統使用的技術（如 Active MQ）的新開發已經轉移到了 Rabbit MQ。
 

Kafka與傳統訊息代理區別 
雖然分散式日誌技術表面上看起來與傳統的代理訊息傳遞技術非常相似，但它們在架構上存在顯著差異，因此具有非常不同的效能和行為特徵。
傳統的訊息代理系統（例如符合 JMS 或 AMQP 的系統）往往具有直接連線到代理的程式和直接連線到程式的代理。因此，對於從一個程式到另一個程式的訊息，它可以透過代理進行路由。這些解決方案傾向於針對靈活性和可配置的交付保證進行最佳化。

最近出現了 Apache Kafka 等技術，或者俗稱的分散式提交日誌技術，可以起到與傳統代理訊息系統類似的作用。它們針對不同的用例進行了最佳化，但是它們並沒有專注於靈活性和交付保證，而是傾向於專注於可擴充套件性和吞吐量。
在分散式提交日誌架構中，傳送和接收程式更加分離，並且在某些方面傳送程式並不關心接收程式。訊息會立即儲存到分散式提交日誌中。交付保證通常在分散式提交日誌中的訊息傾向於僅保留一段時間的上下文中檢視。一旦時間到期，分散式提交日誌中的舊訊息就會消失，無論保證如何，因此通常適合資料可能到期或將在特定時間處理的用例。
 

分散式提交日誌技術的選擇
在本文中，我們將比較四種最流行的分散式日誌技術。以下是每個的高階摘要：

  • Apache Kafka

Kafka是一個分散式流媒體服務，最初由LinkedIn開發。API允許生產者將資料流釋出到主題。一個主題是一個分割槽的記錄日誌，每個分割槽都是有序和不可改變的。消費者可以訂閱主題。Kafka可以執行在一個由經紀人組成的叢集上，其分割槽在叢集節點之間分割。因此，Kafka旨在實現高度的可擴充套件性。然而，Kafka可能需要使用者付出額外的努力來根據需求進行配置和擴充套件。
  • 亞馬遜Kinesis

Kinesis是一個基於雲的實時處理服務。Kinesis生產者可以在資料被建立後立即推送到流中。Kenesis將資料流分成不同的分片（類似於分割槽），由你的分割槽金鑰決定。每個分片對每秒的交易數和資料量都有一個硬性限制。如果你超過這個限制，你需要增加分片的數量。大部分的維護和配置對使用者是隱藏的。AWS允許使用者輕鬆擴充套件，只需為他們使用的內容付費。
  • 微軟Azure事件中心

事件集線器將自己描述為一個事件採集器，能夠每秒接收和處理數百萬個事件。生產者透過AMQP或HTTPS將事件傳送到事件中心。事件集線器也有分割槽的概念，使特定的消費者能夠接收流的一個子集。消費者透過AMQP連線。消費者組被用來允許消費的應用程式對事件流有一個單獨的看法。Event Hubs是一個完全可管理的服務，但使用者必須預先購買以吞吐量為單位的容量。
  • 谷歌Pub/Sub

Pub/Sub提供可擴充套件的基於雲的訊息傳遞。釋出者應用程式將訊息傳送到一個主題，消費者訂閱到一個主題。訊息在被確認之前一直儲存在一個訊息儲存中。釋出者和拉動訂閱者是可以提出Google API HTTPS請求的應用程式。透過在各資料中心之間分配負載來實現自動擴充套件。使用者按資料量收費。

在這篇文章中，不可能對每項技術進行詳細的研究。然而，作為一個例子，我們將在下面的章節中更多地探討Apache Kafka。
   

分散式提交日誌技術有什麼用？
雖然我不會比較和對比傳統訊息代理的所有用例，當與分散式日誌技術相比較時（我們將留到另一篇部落格），但如果我們暫時比較一下Active MQ和Apache Kafka設計背後的驅動力，我們就能感受到它們的好處。
Apache Kafka是在LinkedIn建立的，以提供一種方法來擴充套件他們的更新並最大化吞吐量。可擴充套件性是對延遲和訊息傳遞保證的首要關注。在可擴充套件性的要求下，需要簡化配置、管理和監控。

分散式日誌技術有幾個真正擅長的用例，它們通常有以下特點。

  • 資料有一個自然的到期時間--比如股票或股份的價格。
  • 資料量很大--因此吞吐量和可擴充套件性是關鍵的考慮因素。
  • 資料是一個自然流--回溯到流中的某些點或向前穿越到某個給定的點可能有價值。


因此，在金融服務領域，Kafka被用於。
  • 價格反饋
  • 事件溯源採購
  • 將資料從OLTP系統送入資料湖

 

分散式日誌技術的屬性
在選擇分散式日誌技術時，應該考慮一些屬性，這些屬性包括：

  • 資訊傳遞保證
  • 排序保證
  • 吞吐量
  • 延遲
  • 可配置的永續性週期
  • 持久儲存
  • 分割槽
  • 消費者群體

 
資訊傳遞保證
訊息傳遞系統通常在傳遞訊息時提供特定的保證。有些保證是可配置的。保證的型別有。
  • 最多一次--有些訊息可能會丟失，沒有訊息會被交付一次以上。
  • 精確一次--每條訊息保證只被傳遞一次，不多也不少。
  • 至少一次--每條訊息都保證被送達，但在某些情況下可能被多次送達。


排序保證
對於分散式日誌技術，可以有以下排序保證
  • 無--絕對不保證任何訊息以與它們進來的順序相關的任何順序出來。
  • 在一個分割槽內--在任何給定的分割槽內，順序是絕對保證的，但是在不同的分割槽之間，資訊可能會出現順序錯誤。
  • 跨越分割槽--跨分割槽的排序是有保證的。這是很昂貴的，而且會減慢速度，使擴充套件變得更加複雜。


吞吐量
在設定的時間內可處理的資訊量。

延遲
一條訊息放在佇列中後被處理的平均速度。值得注意的是，有時你可以透過批處理事情來犧牲延遲以獲得吞吐量（反之，透過在資料建立後立即傳送來改善延遲，會犧牲吞吐量）。

可配置的持久化時間
訊息將被儲存的時間段。一旦過了這個時間，訊息就會被刪除，即使沒有消費者消費過該訊息。
 

如何選擇使用哪一種？
在選擇分散式提交日誌技術時，你可以問自己幾個大問題（在下面的一個簡單的決策流程圖中捕獲）。你是在尋找一個託管解決方案還是一個管理服務解決方案？雖然Kafka可能是所有技術中最靈活的，但它也是操作和管理最複雜的。你在工具上節省的成本，可能會在支援和開發人員的執行和管理上用掉。

所有分散式提交日誌技術的共同點是，訊息傳遞的保證往往至少是一次處理。這意味著消費者需要防止多次收到訊息。
與Apache Spark這樣的流處理引擎相結合，可以給消費者提供精確的一次處理，並消除使用者應用程式處理重複訊息的需要。

更多點選標題

相關文章