現在從事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中文網站
