kafka——(一)：初識kafka
學習資源安利
需求
其實瞭解kafka也有一段時間了，最近可能需要從一個介面獲得資料放進HDFS，感覺直接接受介面的資料放進Hive也不是不可以，但是考慮到穩定性可靠性，決定還是用下kafka，看看具體有什麼不同。
參考：為什麼使用訊息系統【解耦、冗餘、擴充套件、峰值處理能力、可恢復性、非同步處理、順序性、緩衝
主要是可靠性和普適性：前者中，訊息佇列起到安全快取的作用，保證資料不丟失；後者，多個不同的服務，不必要二次開發訊息傳遞元件（也是領英開發kafka的原因所在）
現實生活中，很多系統監控和理解的物件都是連續不斷的流，比如說使用者健康資料、GPS訊號、物聯網的各種感測器資料等，因此以資料流的方式採集和分析資料也是順理成章的事。
訊息佇列的兩種模式
| \ | 點對點-Queue | 釋出/訂閱：Topic |
|---|---|---|
| 概念 | 訊息生產者生產訊息傳送到queue中，然後訊息消費者從queue中取出並且消費訊息 | 訊息生產者（釋出）將訊息釋出到topic中，同時有多個訊息消費者（訂閱）消費該訊息 |
| 最主要區別 | 訊息被消費以後，queue中不再有儲存，所以訊息消費者不可能消費到已經被消費的訊息。 | 和點對點方式不同，釋出到topic的訊息會可以被多個訂閱者消費。(可持久化——解耦訊息的傳送者和消費者；kafka中，可以通過引數配置保留期限) |
幾種常見的訊息系統
kafka各個版本的新特性
可參考此文
0.9版本有較大的改變，不再有高階低階API之分。
安裝啟動kafka
1.cdh中安裝kafka：下載parcel——分發啟用——設定broker以及Mirromaker節點——注意whitelist（白名單）以及JVM 對記憶體的設定，出錯參考
Producer/Consumer使用初探
–create 建立一個toipc：
./kafka-topics --create --zookeeper ip10:2181,ip11:2181,ip12:2181 --replication-factor 1 --partitions 3 --topic testTopic
【通過主題，可以避免消費者讀取其他不相關的資料】–list 檢視所有topic：
./kafka-topics --list --zookeeper ip10:2181,ip11:2181,ip12:2181–descirbe 檢視topic詳細資訊：
./kafka-topics --describe --zookeeper ip10:2181,ip11:2181,ip12:2181
建立釋出者console-producer:
Kafka自帶一個命令列客戶端，它從檔案或標準輸入中獲取輸入，並將其作為message（訊息）傳送到Kafka叢集。預設情況下，每行將作為單獨的message傳送。
執行 producer，然後在控制檯輸入一些訊息以傳送到伺服器。
~~./kafka-console-consumer --broker-list ip10:9092 --topic testTopic
~沒反應。。。提示：broker-list is not a recognized option，cdh的kafka有不一樣？~
~找了一圈，然後在cloudera官網中找到了答案~
最開始我”理所當然“的認為，命令位於/opt/cloudera/parcels/KAFKA-3.1.0-1.3.1.0.p0.35/bin/下面，因為，該有的，它都有了。。。：
~/usr/bin/下的使用命令，效果一樣，還是沒反應~
命令敲錯了，[producer 敲成了consumer ]：
./kafka-console-producer --broker-list ip10:9092,ip11:9092,ip12:9092 --topic testTopic
5.啟動消費者：
kafka-console-consumer --zookeeper ip10:2181,ip11:2181,ip12:2181 --topic testTopic
注意，偏移檢查已經廢棄:新的Consumer API不支援kafka-consumer-offset-checker
push還是pull
- producer 採用 push 模式將訊息釋出到 broker，每條訊息都被 append 到 patition 中；
- kafka的例項broker與consumer之間的資料”溝通“，是consumer向broker pull資料，而不是broker主動向消費者/訂閱者主動push資料，這樣做的好處有：
1.降低broker的壓力，borker可以減少對consumer的管理，少記錄一些資訊；consumer 可自主控制消費訊息的速率，可簡化 broker 的設計；
2.push 模式很難適應消費速率不同的消費者，因為訊息傳送速率是由 broker 決定的。它的目標是儘可能以最快速度傳遞訊息，但是這樣很容易造成 consumer 來不及處理訊息，典型的表現就是拒絕服務以及網路擁塞。而 pull 模式則可以根據 consumer 的消費能力以適當的速率消費訊息。[1]
3.您可以讓一位消費者實時處理訊息，另一位消費者以批處理模式處理訊息。
另一個原因可能是kafka不僅僅是為像hadoop這樣的單一消費者設計的。不同的消費者可以有不同的需求和能力。[2]
基於流的計算摒棄了全域性狀態的概念，因為全域性掌控資料狀態的代價太高昂，各個部件不需要假裝知道系統其他部件到底正在做什麼。因此，不需要協調就可以完成更多的工作。
2018/6/10增
- kafka按照訊息傳遞過來的順序依次將訊息寫入檔案；消費者可以按照自己設定的順序（偏移量）來讀取檔案。
- 在一個主題具有多個分割槽時，只能保證單個分割槽中讀取出來的資料的順序性（就像多個機器同時跑top k 任務）；當消費者以多執行緒的方式讀取訊息時，如果要保證單個分割槽的有序性，還應該讓執行緒數不超過分割槽數。
- kafka所有訊息都是非同步傳送的，可調節緩衝區buffer.size或者指定延時時間linger.size來權衡吞吐量和延時。