現在從事java開發的同學，不論是在面試過程中還是在日常的工作中，肯定會碰到訊息佇列的情況，市面上訊息佇列有很多：kafka、rocketMQ、rabbitMQ、zeroMQ等，從本篇部落格起計劃分享一些kafka方面的知識。
訊息佇列基礎知識
所謂訊息佇列很好理解，把它拆開來看就是訊息和佇列，訊息這裡不是一般意義上的訊息，這裡是廣義的，你可以理解為一個個的訂單資訊、學生資訊、一個個的簡訊等；佇列就很好理解了，學過計算機的人都知道就是一個先進先出的線性資料結構。好了，理解了訊息佇列下面看下訊息佇列的其他內容。
一個訊息佇列應該包含三部分，分別是生成方、訊息佇列、消費方，
推/拉模型
何為推/拉模型，這是對於消費方來說的，上面的圖細心的讀者會發現在“訊息佇列”和“消費方”之間我用的是不帶箭頭的實線。訊息佇列把訊息推給消費方稱為推模型，消費方主動去訊息佇列拉取訊息稱為拉模型。
推/拉模型的優缺點，推模型的話就是無法考慮到消費方的消費能力，有可能消費方消費不過來，造成訊息丟失；拉模型消費方主動拉取訊息，可以控制消費的速度，但是要主要訊息佇列中訊息的積壓問題。
點對點/釋出訂閱模式
這裡說的是生成方和消費方的關係，點對點即一個生成方有一個消費方，所有的訊息均有該消費方自己消費；釋出訂閱講的是一個生成方有多個消費方，每個訂閱了該訊息佇列的消費方都可以消費到生成方的全部訊息。
使用訊息佇列的優點
在系統中引入訊息佇列的好處有很多，總的來說有下面三點
- 非同步，這裡把生產方和消費方看成是兩個系統，兩個系統間存在呼叫關係，加入訊息佇列後，之前的同步呼叫關係變成了非同步呼叫，可以減少系統的等待時間；
- 削峰，在高併發、大流量系統中，可以把要處理的訊息放到佇列中，慢慢去消費，不至於把系統打死；
- 解耦，把對訊息的業務處理放在同一個系統中，會造成系統的龐大，增加維護難度，引入訊息佇列，拆成多個系統可以做到系統間的解耦；
使用訊息佇列的缺點
上面說了那麼多優點，訊息佇列就沒有缺點了嗎
- 增加系統複雜度，由於引入了訊息佇列，必然造成系統間呼叫的複雜；服務呼叫鏈增長；排查問題難度加大；
- 增加維護成本，訊息佇列使系統解耦的同時，帶來了維護的成本，要維護多個專案，而且要熟悉服務間的呼叫關係；
上面對訊息佇列大體有了一個瞭解，下面看kafka.
kafka初始
引用官網上的一句話，kafka是一個分散式流處理平臺。說到分散式，自然想到分散式系統中的CAP理論，以及副本等概念，這裡僅僅提下這些概念。對於kafka的簡介，這裡看官網未免不是更好的選擇，
作為一款訊息佇列，kafka使用釋出訂閱模式，採取拉模型消費訊息。
kafka概念
對kafka有了一定的瞭解後，看下其中的一些概念
broker
kafka是一個分散式的系統意味著是多節點的，在這個系統中的每個節點就稱為一個broker。
leader
上面說到每個節點都是一個broker，在分散式系統中必須要有一個主節點，來處理和管理其他節點，那麼由zookeeper從多個broker中選舉出來的主節點稱為leader
follower
除了leader之外的broker稱為follower
topic
topic叫做資料主題相當於生產方傳送訊息的目的地，消費方消費訊息的資料來源。訊息通過topic進行儲存。
分割槽（partition）
分割槽是最終存放訊息地方，分割槽屬於topic，一個topic可以有多個分割槽。一個訊息進入到topic後，由topic決定訊息存放在哪個分割槽，一般是通過輪詢的方式決定訊息的存放分割槽，在一個分割槽內訊息是有序的。訊息落到分割槽後會有分配一個唯一訊息id，此id稱為offset。
副本（replication）
分散式系統為了保證系統的可用性，往往要把儲存的資料存多個副本，也就是同樣的資料存多份。
消費者群組
一個topic可以有多個消費者，那麼所有的消費者可以接受到topic中的全部訊息，為了提高消費者的處理能力，在消費者中使用多執行緒共同消費訊息不是更好，消費者群組就是這樣一個概念，多個消費者組成一個群組共同去消費topic。消費者群組中的消費執行緒（或者服務）根據分割槽去消費訊息。
offset
offset翻譯過來叫偏移量，在消費端會記錄當前這個時刻消費的訊息id，這個id就是offset。在消費過程中重置該offset，可以消費之前的訊息（重複消費）或者跳過某些訊息從最新的開始消費。
kafka架構
kafka是分散式叢集架構，使用zookeeper作為管理元件，協調叢集中每個節點的關係，也就是選舉leader，管理topic和partition。
簡單介紹了訊息佇列和kafka的基本概念，下面準備開始kafka的安裝及使用，敬請關注。
推薦一個kafka的中文網站：kafka中文網站
