本文的目的是讓讀者快速了解Kafka與消息隊列之間的關系，告訴讀者為什么會考慮使用它的原因。以下為譯文。

Kafka最初是由Linkedin社區開發的一項技術。簡而言之，它有點像消息隊列系統，但它與消息隊列系統不同的就是它能夠支持pub/sub，可以在許多服務器上進行擴展，并重新播放消息。

平時你可能不太關注這些問題，但是當你想要采用響應式編程風格而不是命令式編程風格時，上述這些就是你需要進行關注的了。

命令式編程和響應式編程之間的區別

命令式編程是我們一開始就采用的編程類型。當發生了一些事情，換句話說，事件發生了，然后你的代碼被告知發生了該事件。例如，用戶單擊一個按鈕，你在代碼中處理這個事件的地方，就決定了你希望系統接下來觸發哪些動作。您可以將記錄保存到數據庫中，調用另一個服務，發送電子郵件，或者將這些動作組合在一起。這里最重要一點是，事件是與這些具體發生的動作是直接耦合的。

響應式編程使用戶能夠響應發生的事件，通常以流的形式出現。多個關注點可以訂閱相同的事件，并讓事件在它的域中產生影響，而不管其他域發生了什么。換句話說，它支持松散耦合的代碼，可以很容易地擴展到更多的功能。有可能在不同的棧中編碼的各種大的下流系統會受到事件的影響，甚至是在云的某個地方執行的一大堆沒有服務器的函數。

從消息隊列到Kafka

為了理解Kafka會給你的架構帶來什么，讓我們先談論一下消息隊列。我們之所以從消息隊列開始，是因為我們將討論它的局限性，然后看看Kafka是如何解決這些問題的。

消息隊列允許一組訂閱者從隊列的末尾提取一條或多條消息。在消息被移除之前，隊列通常允許執行某些級別的事務，以確保在消息被刪除之前執行所需的操作。

并不是所有的隊列系統都具有相同的功能，但是一旦消息被處理了，就會從隊列中刪除掉。如果你仔細想想，它其實與命令式編程非常類似，首先得發生一些事情，然后起始系統決定在下游系統中應該執行哪些操作。

盡管可以在隊列中擴展多個消費者，但它們都包含相同的功能，而這只是為了處理負載和并行處理消息，換句話說，它不允許你基于相同的事件啟動多個獨立的操作。隊列消息的所有處理器將在相同的域中執行相同類型的邏輯。這意味著隊列中的消息實際上是命令，它適合于命令式編程，而不是一個適合于響應式編程的事件。

對于隊列，通常在相同的域中為隊列中的每個消息執行相同的邏輯

另一方面，使用Kafka，你可以將消息/事件發布到主題上，它們會被持久化。當消費者收到這些消息時，他們也不會被移除掉。這允許你重放消息，但更重要的是，它允許大量的消費者基于相同的消息/事件處理各自不同邏輯。

你仍然可以在相同的域中進行并行處理，但是更重要的是，你還可以添加不同類型的消費者，這些消費者基于相同的事件執行不同的邏輯。換句話說，對于Kafka，用戶可以采用一個被動的pub/sub體系結構。

不同的邏輯可以由不同的系統基于相同的事件來執行

在使用Kafka的情況下，這是可能的，因為信息是保留的，消費者群體的概念也是如此。Kafka的消費者團體在向Kafka詢問關于某個話題的信息時，將自己定位于Kafka。Kafka將會記錄哪些消息(偏移量)被傳送到哪個消費者組，這樣它就不會再為它服務了。實際上，它比這要復雜一些，因為您有許多可用的配置選項來控制這一點，但是我們不需要全面地探索這些選項，只是為了在高層次上理解Kafka。

總結

Kafka還有其它很多的功能，比如它是如何管理擴展(分區)的、為可靠消息傳遞提供了哪些配置選項等等，但我希望這篇文章足夠好，讓你明白為什么你會考慮采用Kafka而不是好的“ol消息隊列”。