消息系統概述

草捏子最近開始學習Kafka。在學習前，給本身肯定了下學習的範圍，大體以下：

1. 理解Kafka的相關概念；
2. 掌握Kafka的基本API使用；
3. 瞭解Kafka的背後原理。

後續將在這學習範圍內輸出一些相關文章。那麼本文做爲Kafka系列的第一篇文章，將從「理解Kafka的相關概念」提及。首先Kafka是什麼。

Kafka起初是由LinkedIn公司採用Scala語言開發的一個多分區、多副本且基於ZooKeeper協調的分佈式消息系統，現已被捐獻給Apache基金會。目前Kafka已經定位爲一個分佈式流式處理平臺，它以高吞吐、可持久化、可水平擴展、支持流數據處理等多種特性而被普遍使用。

從上述介紹中，咱們能夠知道Kafka具備消息系統和流式處理平臺兩種角色。爲了更好的理解Kafka，本文將對消息系統進行介紹。

消息系統

消息系統，又被稱做消息中間件。如今聽到較多的是消息隊列（MQ）的叫法，算是消息中間件的一種簡稱，其實都是一樣的意思。那麼消息系統是什麼。

看一個咱們都熟悉的場景——電子郵件。咱們發送電子郵件，實際上就是將一個郵件文件從咱們的電腦轉發到對方電腦上，可是咱們在發送的時候，並不須要關心對方的電腦是否開着，只管發送就好，郵件會先被髮送到郵件服務器上，而後當對方電腦開機時，再從郵件服務器上獲取郵件。郵件服務器就是一個消息系統，可暫存應用之間通訊所發送的消息。而這樣能帶來的好處也顯而易見了，做爲發送消息的生產者並不須要關心接收消息的消費者的狀態，生產者只需確保將消息成功發送到消息系統便可，這是一種異步通訊模式。

這種通訊模式起到了解耦的做用，減小了生產者的職責。生產者只需關注生產消息和把消息發送到消息系統，而消費狀況無需關注。
不只如此，除上述咱們描述的點對點（單消費者）狀況，咱們還能夠在生產者無感知的狀況下，使用發佈/訂閱模式。加入的新消費者去訂閱主題，而後由消息系統廣播給全部訂閱的消費者，這爲系統的擴展提供了便利。

並且經過異步能加快系統的響應。例如一個下單操做，須要涉及優惠券、積分和短信等系統的處理，若是使用同步則須要等全部系統都處理完，但這樣下單系統的響應時間將大大增長。經過使用消息系統，下單系統只需將下單操做的消息寫入，而後完成下單操做，響應給用戶。至於優惠券、積分、短信等將由相應系統從消息系統中獲取下單操做消息進行處理。

咱們再試想下這樣的場景，當下單系統接收的請求突增的時候，消息系統也能起到削峯/限流的做用，暫存消息，讓下游系統根據自身處理能力來處理消息，避免下游系統崩潰，系統也將更爲穩定。

關注的問題

經過上述的介紹，對消息系統有了必定的認識。下面咱們再進一步的思考下，消息系統的功能咱們已經知道了，若是讓咱們使用一個消息系統，須要關注哪些問題，如下是我所想到的一些：

1. 可用性。若是消息系統掛了，那消費的下游系統都將失效，因此須要保證可用性。
2. 吞吐量。若是上游系統每秒百萬級的吞吐量，須要讓消息系統的寫入吞吐量與其匹配。同時也需關注下游系統消費狀況的吞吐量。
3. 消息丟失。上游系統->消息系統->下游系統，這兩個過程都有可能發生消息丟失。
4. 消息順序。這個問題其實和消息丟失是同時存在的，因爲消息的丟失，將形成消息順序的錯亂。

在後續的學習中，將帶着這幾個問題，去看看Kafka是如何解決。