訊息中介軟體的使用已經越來越廣泛，基本上具有一定規模的系統都會用到它，在大資料領域也是個必需品，但為什麼使用它呢？一個技術的廣泛使用必然有它的道理。
背景與問題
以前一些傳統的系統，基本上都是“使用者——系統——資料庫”一條線，拿下單做例子，使用者下單，系統接受並處理請求，把資料存到資料庫。
這樣的好處就是簡單，但隨著需求越來越多，使用者量越來越大，系統需要承載的壓力就越大；如果需要擴充套件系統，修改程式碼，牽一髮動全身，麻煩滴很。
訊息佇列可以解決這些問題，它是一個存放訊息的佇列，生產者往佇列推數，消費者從佇列取數。
優點
解耦
一個系統一般都有很多個模組，但業務發展起來，系統的體量就跟著變大，就需要多做幾個模組，然而每擴充一個模組就要多各種呼叫。
以一個交易系統為例，當完成一次交易，系統需要通知推薦系統、廣告系統等。當多出一個模組，系統就要增加一個呼叫，從而需要修改程式碼。
要是你覺得改改程式碼不麻煩，可是改完，後面有一個模組出問題了咋辦，一點一點排查，改錯地方了還影響到了其他模組。
如果增加訊息中介軟體，各個模組只需要完成各自的工作，然後將訊息發到訊息佇列，由其他模組去取或者訊息佇列推送，就可以解決耦合的問題了。
非同步
傳統系統的話，一條路走到底，比如購買商品，完了扣除優惠券，再給你積點分。這每個流程可能就花一點時間，但合起來就很久了。
加上訊息佇列，我直接完成我的工作，再給佇列，佇列再通知其他模組，這不僅省事兒，還減少了不必要的時間浪費。
削峰
還是以傳統系統為例，當併發量大的時候直接懟到資料庫，資料庫承受的壓力得多大呀這是。欸，那就加個訊息佇列，把請求扔到訊息佇列，慢慢處理
缺點
技術嘛，總是有好有壞，剛才說了它的優點，現在簡單嘮嘮它的缺點。
首先，降低了系統的可用性，好好的一個系統，加一箇中介軟體，如果它掛了，後面不得涼涼。
為了防止它掛掉或者掛掉了修復它，是不是得維護？是不是增加了運維成本？
不僅如此，還要考慮資料一致性問題，以及重複消費的問題，還要保證訊息的可靠傳輸。要考慮的東西有多少，系統的複雜性就有多高。
消費模式
訊息中介軟體一般有兩種消費模式，一種是點對點模式，一種是釋出訂閱模式。
點對點是一種一對一的模式，一般訊息只由一個消費者消費，導致訊息沒法複用；
釋出訂閱模式是一種常見的模式。消費者訂閱，當有訊息來的時候通知消費者。這種模式也分為兩種情況，一種是由訊息佇列推送，類似公眾號訂閱一樣，只要消費者訂閱了，訊息一來就推給訂閱了的消費者。
但是這種方法也有缺點，因為消費者的處理速度不一樣，有快有慢，容易出現問題。比如訊息佇列推送的速度為100M/s，消費者A處理速度為10M/s，消費者B處理速度為500M/s，這時候A就崩了，對於B來說，又造成資源浪費。
所以由消費者主動拉取的方式誕生了，由消費者主動拉資料，解決了上面的問題，但技術有優點的同時，一般都存在缺點。由於消費者要主動拉取，需要維護一個長輪洵去詢問佇列，但當遇到長時間沒有訊息的情況，就造成了資源浪費。
本文的主角 Kafka 是基於拉取的釋出訂閱模式。
講了這麼多，是時候請上主角，有請 Kafka 登場！
Kafka 的基礎架構
Producer：生產者，釋出訊息的物件，將訊息推到 Kafka 叢集
Consumer：消費者，消費訊息的物件
Consumer Group：消費者組，Kafka 中可以將多個 Consumer 分為一個組，從整體上可以將它看作是一個Consumer
Broker：一臺 Kafka 伺服器就是一個 Broker，多個 Broker 組成一個 Cluster
Topic：訊息的主題，可以理解為一個訊息佇列
Partition：分割槽，一個 Topic 可以分為多個 Partition，這樣的好處是負載均衡；同時，一個 Partition 可以有多個副本，提高可靠性。對於 Consumer Group 來說，一個消費者組中的消費者只能訂閱同一個 Topic 的不同分割槽，可以提高效率，又避免重複消費。
Leader & Follower：對於同一個 Partition 而言，消費者只讀取 Leader 的訊息，而不會讀取 Follower 的訊息，Follower 是 Leader 的副本，在 Leader 掛掉的時候 Follower 可成為 Leader
Zookeeper： Kafka 是基於 zk 的，用於叢集管理
為什麼 Kafka 要這樣設計
如果訊息中介軟體只有一臺機，哪天突然當機了，整個系統就崩了。因此需要整一個叢集，搞多臺伺服器，所以我們搞幾個 Broker。
然後生產者準備傳送訊息了，如果正巧所有的訊息都隨機地發到其中某一臺機器上，流量全上去了，生產者消費者都來找他，看著其他機器都在摸魚，它突然不幹了。
於是要合理分配工作，整出了 Partition，每個 Topic 對應每個生產者和消費者，同一個 Topic 又分成多個分割槽，分別在不同的 Broker，分擔了單臺節點的壓力。
不過現在又有一個問題，如果一臺 Broker 當機，該節點上的分割槽資料也沒了。為了防止單節點故障造成資料丟失，每個分割槽存幾個副本儲存在其它 Broker。
但消費者只能訪問其中一個分割槽，不然會造成重複消費的現象，所以要區分好 Leader 和 Follower，並使消費者只能訪問 Leader，而 Follower 需要在 Leader 發生故障的時候成為新的 Leader。