2019.10.04 學習記錄1 極客時間 - 《kafka核心技術與實戰》
一、為什麼學習kafka
就拿資料量激增來說，kafka能夠有效隔離上下游業務，將上游突增的流量快取起來，以平滑的方式傳導到下游子系統中，避免了流量的不規則衝擊。
apache kafka是一款開源的訊息引擎系統。
「訊息傳遞」
官方：訊息引擎系統是一組規範。企業利用這組規範在不同系統之間傳遞語義準確的訊息，實現松耦合的非同步式資料傳遞。
平語：系統a傳送訊息給訊息引擎系統，系統b從訊息引擎系統中讀取a傳送的訊息。
訊息傳遞格式：使用的是純二進位制的位元組序列。
設定傳輸協議，即我用什麼方法把訊息傳輸出去，有兩種方式：1、點對點，即a對b； 2、發布/訂閱：主題topic，多對多
kafka同時支援這兩種方式，為什麼呢？ jms一組api
「削峰填谷」
為什麼要使用kafka？
所謂的「削峰填谷」就是指緩衝上下游瞬時突發流量，使其更平滑。另一大好處在於傳送方和接收方的松耦合，這也在一定程度上簡化了應用的開發，減少了系統間不必要的互動。
類似於秒殺這樣的業務時，上游訂單流量會瞬時增加，可能出現的結果就是直接壓跨下游子系統服務。
可以對上游系統限速，但問題不出現它這裡，更常見的方式是引入kafka這樣的訊息引擎系統對抗上下游tps的錯配以及瞬時峰值流量。
還是這個例子，當引入了kafka之後。上游訂單服務不再直接與下遊子服務進行互動。當新訂單生成後它僅僅是向kafka broker傳送一條訂單訊息即可。類似地，下游的各個子服務訂閱kafka中的對應主題，並實時從該主題的各自分割槽（partition）中獲取到訂單訊息進行處理，從而實現了上游訂單服務與下游訂單處理服務的解耦。這樣當出現秒殺業務時，kafka能夠將瞬時增加的訂單流量全部以訊息形式儲存在對應的主題中，既不影響上游服務的tps，同時也給下遊子服務留出了充足的時間去消費它們。這就是kafka這類訊息引擎系統的最大意義所在。
問題解答：
這個場景使用kafka streams比較適合，它就是為read-process-write場景服務的
rabbitmq屬於比較傳統的訊息佇列系統，支援標準的訊息佇列協議（amqp, stomp，mqtt等），如果你的應用程式需要支援這些協議，那麼還是使用rabbitmq。另外rabbitmq支援比較複雜的consumer routing，這點也是kafka不提供的。
往大了說屬於資料流模式（dataflow mode）的問題。
我們常見的資料流有三種：1. 通過資料庫；2. 通過服務呼叫（rest/rpc）; 3. 通過非同步訊息傳遞（訊息引擎，如kafka）
rpc和mq是有相似之處的，畢竟我們遠端呼叫乙個服務也可以看做是乙個事件，但不同之處在於：
1. mq有自己的buffer，能夠對抗過載（overloaded）和不可用場景
2. mq支援重試
3. 允許發布/訂閱模式
當然它們還有其他區別。應該這樣說rpc是介於通過資料庫和通過mq之間的資料流模式。
如果是以實現高吞吐量為主要目標，kafka是不錯的首選；如果是以實現業務系統為主要目標，特別是金融類業務，可以考慮應用kafka的流處理元件kafka streams。不過坦率說目前將kafka應用於純業務系統的並不多
二、術語
客戶端：生產者和消費者
服務端：kafka的伺服器端由被稱為broker的服務程序構成，即乙個kafka集群由多個broker組成，broker負責接收和處理客戶端傳送過來的請求，以及對訊息進行持久化。雖然多個broker程序能夠執行在同一臺機器上，但更常見的做法是將不同的broker分散執行在不同的機器上，會實現高可用。
「備份機制」
kafka定義了兩類副本：領導者副本（leader replica）和追隨者副本。
前者對外提供服務，這裡的對外指的是與客戶端程式進行互動；而後者只是被動地追隨領導者副本而已，不能與外界進行互動。
副本的工作機制：
生產者總是向領導者副本寫訊息；而消費者總是從領導者副本讀訊息。至於追隨者副本，它只做一件事：向領導者副本傳送請求，請求領導者把最新生產的訊息發給它，這樣它能保持與領導者的同步。
雖然有了副本機制可以保證資料的持久化或訊息不丟失，但沒有解決伸縮性的問題。
領導者副本積累了太多的資料以至於單台broker機器都無法容納了，此時應該怎麼辦呢？乙個很自然的想法就是，能否把資料分割成多份儲存在不同的broker上？即分割槽。
kafka中的分割槽機制指的是將每個主題劃分成多個分割槽（partition），每個分割槽是一組有序的訊息日誌。生產者生產的每條訊息只會被傳送到乙個分割槽中
即時總結：
副本機制可以保證資料持久化或訊息不丟失
但不能保證伸縮性
分割槽可以保證伸縮性
「訊息層次」
kafka broker是如何持久化資料的？
使用訊息日誌log來儲存資料，只能追加寫，避免了io操作，這是kafka實現高吞吐量的乙個重要手段；
但也要定期刪除訊息以**磁碟，可以通過日誌段機制。
在kafka底層，乙個日誌又近一步細分成多個日誌段，訊息被追加寫到當前最新的日誌段中，當寫滿了乙個日誌段後，kafka會自動切分出乙個新的日誌段，並將老的日誌段封存起來。kafka在後台還有定時任務會定期地檢查老的日誌段是否能夠被刪除，從而實現**磁碟空間的目的。
點對點：指的是同一條訊息只能被下游的乙個消費者消費，其他消費者則不能染指。
指的是多個消費者例項共同組成乙個組來消費一組主題。這組主題中的每個分割槽都只會被組內的乙個消費者例項消費，其他消費者例項不能消費它。為什麼要引入消費者組呢？主要是為了提公升消費者端的吞吐量。多個消費者例項同時消費，加速整個消費端的吞吐量（tps）。
消費者組內某個消費者例項掛掉後，其他消費者例項自動重新分配訂閱主題分割槽的過程。rebalance是kafka消費者端實現高可用的重要手段。
比較好的總結：
為什麼 kafka 不像 mysql 那樣允許追隨者副本對外提供讀服務？
kafka學習記錄
kafka集群搭建 1 搭建 2 配置檔案介紹 軟體環境 linux 需要有zookeeper集群，版本選擇0.8.1 kafka 原始碼包 配置檔案 server.properties 不推薦使用預設的zookeeper broker.id 0 例項id 集群中的唯一標示 prot 9092 ho...
Kafka學習記錄
kafka適合什麼樣的場景?它可以用於兩大類別的應用 構造實時流資料管道，它可以在系統或應用之間可靠地獲取資料。相當於message queue 構建實時流式應用程式，對這些流資料進行轉換或者影響。就是流處理，通過kafka stream topic和topic之間內部進行變化 以下是一些基本的概念...
kafka學習筆記1
下面以乙個kafka集群中4個broker舉例，建立1個topic包含4個partition，2 replication 資料producer流動如圖所示 當集群中新增2節點，partition增加到6個時分布情況如下 producer在發布訊息到某個partition時，先通過zookeeper找...