Kafka講解
介紹
kafka是一個分佈式的，分區的，可備份的日誌提交服務。它提供了消息系統的功能，但是設計確實獨一無二。這些意味着什麼呢？
首先我們介紹一些術語：
1. Kafka獲取的消息在類型上叫做topics
2. 我們把生產消息到kafka的進程叫做producer（生產者）
3. 我們稱訂閱topic並且處理kafka獲得的消息的進程叫做consumer（消費者）
4. kafka作爲一個集羣來運行，這個集羣有一個或多個服務器組成，這些服務器每一個都被稱爲broker
所以從一個高的角度來講，生產者生產數據通過網絡到kafka集羣上，爲consumer準備數據，過程如下圖所示：
在客戶端與服務端之間的通信是使用一個簡單、高可靠、與語言無關的TCP協議。我們對於kafka提供了Java的客戶端。但是對於其他的語言也有相應的客戶端。
Topics和Logs
我們首先研究kafka提供的高級抽象-topics
topics是一個種類或者說消息發佈的一個名字。對於每個topic來說，kafka集羣維持一個分佈式的日誌如下：
每一個分區都是一個有序的、可變的消息序列，該序列被持續的加入提交的日誌。在分區的中的消息每個都被分配一個有序的id號碼，這個號碼被稱爲offset，在一個分區中
與其他消息的id都是不同的。
Kafka集羣會保留所有提交的消息-不管他們是否被消費-在你配置的這段時間內。比如，你把日誌保留時間設置爲兩天，那麼在這兩天當該消息被髮布之後，他是可以被消費
的，時間過去了兩天之後，他將會被丟棄用來釋放空間。Kafka的性能與數據的大小是不相關的，所以保留很大量的數據是沒有任何問題的。
事實上在每個消費者基本信息中保存的都是消費者在log中的位置，稱作：offset。這個offset被消費者所控制：一般情況下，消費者呈直線的增加他的offset，但是事實上，
offset是由消費者控制的，它能夠消費數據以任何他想要的順序。比如說，消費者可以重新獲得一個更古老的位移來重新處理。
這種結合起來的特性意味着kafka消費者十分的cheap（我不知道這種情況下如何翻譯），他們能夠在集羣或者其他的消費者上來去自如，並不會對後者產生多少影響。比如
說，你可以使用我們的命令行工具去tail任何topic的內容，而不會改變其他正在消費該topic的消費者。
日誌服務中的分區有很多作用。第一：它允許日誌超越一個單獨服務器上的大小範圍。每一個分區必須與包含它的服務器相匹配，但是一個topic可以含有很多分區，所以他
可以包含任意數量的數據。第二：他們運作起來像是一個平行單元，更多內容在下面章節。
分佈式
日誌的分區被分佈在kafka集羣上的服務器之中，每個服務器都處理數據，並且請求共享的分區。每個分區都根據配置進行備份從而進行容錯處理。每個分區有一個服務器，該服務器扮演着leader（主）的身份，其餘的機器則扮演者follower（從）的身份。主服務器處理所有關於分區的讀和寫的請求，從服務器被動的復
制主的操作。如果主服務器掛了，從服務器中的一個將會自動成爲新的主服務器。每個服務器對於他自己的分區來說扮演着主的角色，而對於其他的分區則扮演着從的身份，所
以在集羣中load操作能夠得到平衡。
生產者
生產者生產數據到他們指定的topic中，生產者負責決策哪個消息被保存在哪個topic中的哪個分區中。這個可以用循環的方式去做僅僅是爲了平衡load，同樣他也可以通過語
意分區來完成（也就是說基於消息中的key來完成）。
消費者
消息發送傳統上有兩種方式：隊列方式和發佈訂閱方式。在隊列方式中，一個池中的消費者們也許從服務器讀取數據到他們之中的一個。在發佈訂閱模式中，消息被廣播到
所有的消費者中。Kafka提供了一個單獨的消費者抽象來包含了以上的兩者-消費者組（consumer group）。
消費者使用一個消費者組名來標記自己，任何發佈到topic中的消息都被髮送給指定的消費者組中的一個消費者實例。消費者實例可以在不同的進程中或者在不同的機器上。
如果所有的消費者實例擁有同一個消費者組，這種工作方式類似於傳統的消息隊列式。如果所有的消費者實例擁有不同的消費者組，這種工作方式類似於發佈訂閱的類型，他會把消息廣播到所有的消費者中。
更常見的是，我們發現topics有很少數量的消費者羣，每個都有“邏輯訂閱者”。每個組都包含很多消費者實例爲了穩定性和容錯機制。這不僅僅是發佈訂閱模式，因爲kafka
發佈訂閱模式的訂閱者是一個消費者集羣而不是一個單獨的進程。
Kafka相較於傳統消息系統有着一個很強的順序保障。一個傳統的消息隊列在服務器上按照順序保存消息。如果多個消費者從隊列中消費數據，那麼服務器會按照數據的存儲順序分發。然而，雖然服務器按照順序分發消息，消
息異步的分發給消費者，所以對於不同的消費者來說，接收到消息的順序可能是錯亂的。這也就意味着在平行消費中消息丟失了它原有的順序。
消息系統經常變通的通過獨有的消費者線程來從隊列中取數據。當然這也就意味着不能平行的進行計算。Kafka做的更好，他有着平行的概念-分區-在topics中。Kafka有能力爲消費者線程池中的消費者提供順序保證和load平衡。這是通過聲明topic中的消費者組中的消費者的分區
來完成的，從而使得每個分區被組中的一個消費者消費。通過這些我們確保了該消費者是該分區的唯一一個讀取者，這樣就可以按照順序消費數據了。由於有很多的分區，這樣
的方式同樣採用平衡load到多個消費者實例中。注意，在消費者組中，消費者的數量不可以多於分區的數量。
在一個分區內，kafka對於消息僅僅提供一個整體的順序，而不是在topic中的多個分區間。每個分區順序通過key組合分區數據的能力對於大多數的應用來講已經足夠了。然
而，如果你需要關於消息的整體順序的話，你可以設置該topic只含有唯一一個分區。雖然這意味着在一個消費者組中只有一個消費者進程。
保障
在一個高層次來講，kafka提供瞭如下的保障：1. 發送往特定topic下分區的消息將會按照他們發送的順序被添加。這就是說，如果消息M1被消費者作爲消息M2發送，那麼M1會被首先發送，接着M1相較於M2會有一個較小
的offset，在log裏面顯現的也會更早。
2. 一個消費者實例查看消息時按照消息保存在log的順序來查看。3. 如果一個topic含有副本元素N，那麼我們能夠容忍N-1的服務器掛掉卻不會丟失任何的數據。
Messaging（發送消息）
Kafka同樣可以作爲傳統消息broker的替代品，消息brokers因爲種種原因被使用。對比大多數消息系統，kafka擁有更好的吞吐量，內置分區，備份，和容錯機制，這種種使
得kafka是那些擁有者大規模消息處理的應用的完美解決方案。
在我們的經驗中，消息系統相比較而言一般都是小吞吐量的，但是也許需要點對點的低延遲並且依賴kafka提供的較強間隔保證。在這個方面kafka可以與傳統消息系統相比較，例如：ActiveMQ或者RabbitMQ。
Web Activity Tracking(網頁事件追蹤)
原始的kafka用例能夠重建用戶事件追蹤管道爲一系列實時發佈訂閱信息。這意味着網站事件（網頁瀏覽、搜索或者其他活動都能夠獲取）被髮送到中心topic中，並且是每個
事件類型對應着一個topic。這些信息對於訂閱者來說有着許多應用包括實時處理，實時監控，讀入Hadoop或者倉庫系統的離線數據用來離線處理或者報告。
事件追蹤通常有非常高的容量，因爲從每個用戶的界面都會產生許多事件消息。度量
kafka經常用作檢測數據。這包含從不同的分佈式應用中聚合統計結果去產生集中後的數據。日誌收集
很多人使用Kafka作爲日誌收集系統。日誌收集系統本質上來講是各個服務器上收集物理日誌文件，把他們放入一箇中心位置用來處理。Kafka抽象了文件的細節並給了一個
更明確的抽象就是消息流。這允許了多數據源和分佈式處理時的低延遲和更簡易的支持。相比較於以日誌文中心的系統像是Scribe和Flume，kafka提供了同樣好的性能，更健壯
的保證、更低的端對端的延遲。
流處理很多實用kafka的用戶處理數據用包含很多階段的管道方式。方便後邊的消費或者接下來的處理，來自於kafka中topics的數據被消費接着被組合、加工、或者直接被轉化爲了
新的topics。比如，一個用來推薦新聞文章的處理管道可能會從RSS上爬取信息並且把他發佈爲一個文章topic。那麼接下來的工作可能就是處理這些爬取的內容然後發佈清洗後的
數據爲一個新的topic。最後的階段可能就是嘗試把他推薦給用戶。這種處理管道基於每個topic創建了一個實時數據流。在0.10.0.0上開始，一個輕量級但是強力的流處理包Kafka
Streams在apache kafka中可以被使用，用來處理如上所述的數據。除了kafka streams以外，其他的開源流處理工具包括apache Storm和apache Samza
Event Soucing（事件溯源）
事件溯源是一種應用設計，在這種設計中，狀態改變都會被記錄爲基於時間排序的序列記錄。Kafka支持海量數據存儲的特點使得他對於這種類型的應用是非常理想的選擇。Commit Log(提交日誌)
對於一個分佈式系統來說，Kafka能作爲一款外部的日誌提交系統來提供服務。日誌幫助在節點間複製數據，其表現的像是一個re-syncing 機制主要用來對那些失敗的節點重
新保存數據。Kafka中日誌壓縮的屬性支持這種用法，在這種用法中，Kafka 類似於Apache BookKeeper項目。
以上是關於kafka的概念性內容，下一次我將進行關於操作部分的內容講解。感謝開源。
