kafka 將訊息以 topic 為單位進行歸納
將向 kafka topic 發布訊息的程式成為 producers.
將預訂 topics 並消費訊息的程式成為 consumer.
kafka 以集群的方式執行，可以由乙個或多個服務組成，每個服務叫做乙個 broker.
producers 通過網路將訊息傳送到 kafka 集群，集群向消費者提供訊息
資料傳輸的事務定義通常有以下三種級別:
（1）最多一次: 訊息不會被重**送，最多被傳輸一次，但也有可能一次不傳輸
（2）最少一次: 訊息不會被漏傳送，最少被傳輸一次，但也有可能被重複傳輸.
（3）精確的一次（exactly once）: 不會漏傳輸也不會重複傳輸,每個訊息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的
（1）節點必須可以維護和 zookeeper 的連線，zookeeper 通過心跳機制檢查每個節點的連線
（2）如果節點是個 follower,他必須能及時的同步 leader 的寫操作，延時不能太久
producer 直接將資料傳送到 broker 的 leader(主節點)，不需要在多個節點進行分發，為了幫助 producer 做到這點，所有的 kafka 節點都可以及時的告知:哪些節點是活動的，目標 topic 目標分割槽的 leader 在哪。這樣 producer 就可以直接將訊息傳送到目的地了
kafa consumer 消費訊息時，向 broker 發出"fetch"請求去消費特定分割槽的訊息，consumer 指定訊息在日誌中的偏移量（offset），就可以消費從這個位置開始的訊息，customer 擁有 了 offset 的控制權，可以向後回滾去重新消費之前的訊息，這是很有意義的。
kafka 最初考慮的問題是，customer 應該從 brokes 拉取訊息還是 brokers 將訊息推送到 consumer，也就是 pull 還 push。在這方面，kafka 遵循了一種大部分訊息系統共同的傳統 的設計：producer 將訊息推送到 broker，consumer 從 broker 拉取訊息
一些訊息系統比如 scribe 和 apache flume 採用了 push 模式，將訊息推送到下游的 consumer。這樣做有好處也有壞處：由 broker 決定訊息推送的速率，對於不同消費速率的 consumer 就不太好處理了。訊息系統都致力於讓 consumer 以最大的速率最快速的消費消 息，但不幸的是，push 模式下，當 broker 推送的速率遠大於 consumer 消費的速率時， consumer 恐怕就要崩潰了。最終 kafka 還是選取了傳統的 pull 模式
pull 模式的另外乙個好處是 consumer 可以自主決定是否批量的從 broker 拉取資料。push 模式必須在不知道下游 consumer 消費能力和消費策略的情況下決定是立即推送每條訊息還 是快取之後批量推送。如果為了避免 consumer 崩潰而採用較低的推送速率，將可能導致一 次只推送較少的訊息而造成浪費。pull 模式下，consumer 就可以根據自己的消費能力去決
定這些策略
pull 有個缺點是，如果 broker 沒有可供消費的訊息，將導致 consumer 不斷在迴圈中輪詢， 直到新訊息到 t 達。為了避免這點，kafka 有個引數可以讓 consumer 阻塞知道新訊息到達 (當然也可以阻塞知道訊息的數量達到某個特定的量這樣就可以批量發
訊息由乙個固定長度的頭部和可變長度的位元組陣列組成。頭部包含了乙個版本號和 crc32 校驗碼。
訊息長度: 4 bytes (value: 1+4+n)
版本號: 1 byte
crc 校驗碼: 4 bytes
具體的訊息: n bytes
(1).kafka 把 topic 中乙個 parition 大檔案分成多個小檔案段，通過多個小檔案段，就容易定期清除或刪除已經消費完檔案，減少磁碟占用。
(2).通過索引資訊可以快速定位 message 和確定 response 的最大大小。
(3).通過 index 元資料全部對映到 memory，可以避免 segment file 的 io 磁碟操作。
(4).通過索引檔案稀疏儲存，可以大幅降低 index 檔案元資料占用空間大小。
(1).kafka 持久化日誌，這些日誌可以被重複讀取和無限期保留
(2).kafka 是乙個分布式系統：它以集群的方式執行，可以靈活伸縮，在內部通過複製資料 提公升容錯能力和高可用性
(3).kafka 支援實時的流式處理
副本因子不能大於 broker 的個數；
第乙個分割槽（編號為 0）的第乙個副本放置位置是隨機從 brokerlist 選擇的；
其他分割槽的第乙個副本放置位置相對於第 0 個分割槽依次往後移。也就是如果我們有 5 個 broker，5 個分割槽，假設第乙個分割槽放在第四個 broker 上，那麼第二個分割槽將會放在第五 個 broker 上；第三個分割槽將會放在第乙個 broker 上；第四個分割槽將會放在第二個 broker 上，依次類推；
剩餘的副本相對於第乙個副本放置位置其實是由 nextreplicashift 決定的，而這個數也是 隨機產生的
在啟動 kafka 集群之前，我們需要配置好 log.dirs 引數，其值是 kafka 資料的存放目錄， 這個引數可以配置多個目錄，目錄之間使用逗號分隔，通常這些目錄是分布在不同的磁碟 上用於提高讀寫效能。
當然我們也可以配置 log.dir 引數，含義一樣。只需要設定其中乙個即可。
如果 log.dirs 引數只配置了乙個目錄，那麼分配到各個 broker 上的分割槽肯定只能在這個 目錄下建立資料夾用於存放資料。
但是如果 log.dirs 引數配置了多個目錄，那麼 kafka 會在哪個資料夾中建立分割槽目錄呢？
答案是：kafka 會在含有分割槽目錄最少的資料夾中建立新的分割槽目錄，分割槽目錄名為 topic 名+分割槽 id。注意，是分割槽資料夾總數最少的目錄，而不是磁碟使用量最少的目錄！也就 是說，如果你給 log.dirs 引數新增了乙個新的磁碟，新的分割槽目錄肯定是先在這個新的磁 盤上建立直到這個新的磁碟目錄擁有的分割槽目錄不是最少為止。
topic 中的多個 partition 以資料夾的形式儲存到 broker，每個分割槽序號從 0 遞增， 且訊息有序
partition 檔案下有多個 segment（***.index，***.log）
segment 檔案裡的 大小和配置檔案大小一致可以根據要求修改 預設為 1g
如果大小大於 1g 時，會滾動乙個新的 segment 並且以上乙個 segment 最後一條訊息的偏移量命名
request.required.acks 有三個值 0 1 -1
0：生產者不會等待 broker 的 ack，這個延遲最低但是儲存的保證最弱當 server 掛掉的時候就會丟資料
1：服務端會等待 ack 值 leader 副本確認接收到訊息後傳送 ack 但是如果 leader 掛掉後他不確保是否複製完成新 leader 也會導致資料丟失
-1：同樣在 1 的基礎上 服務端會等所有的 follower 的副本受到資料後才會受到 leader 發出的 ack，這樣資料不會丟失
消費者每次消費資料的時候，消費者都會記錄消費的物理偏移量（offset）的位置
等到下次消費時，他會接著上次位置繼續消費
乙個消費者組中的乙個分片對應乙個消費者成員，他能保證每個消費者成員都能訪問，如果組中成員太多會有空閒的成員
乙個消費者組裡它的內部是有序的
消費者組與消費者組之間是無序的
生產者決定資料產生到集群的哪個 partition 中
每一條訊息都是以（key，value）格式
key 是由生產者傳送資料傳入
所以生產者（key）決定了資料產生到集群的哪個 partition
Kafka面試專題
1.kafka 的設計時什麼樣的呢？kafka 將訊息以 topic 為單位進行歸納 將向 kafka topic 發布訊息的程式成為 producers.將預訂 topics 並消費訊息的程式成為 consumer.kafka 以集群的方式執行，可以由乙個或多個服務組成，每個服務叫做乙個 brok...
MyBatis面試專題以及答案
1 什麼是 mybatis？答 mybatis 是乙個可以自定義 sql 儲存過程和高階對映的持久層框架。2 講下 mybatis 的快取 答 mybatis 的快取分為一級快取和二級快取,一級快取放在 session 裡面,預設就有,二級緩 存放在它的命名空間裡,預設是不開啟的,使用二級快取屬性類...
kafka面試題 附答案
1.什麼是kafka kafka是分布式發布 訂閱訊息系統，它最初是由linkedin公司開發的，之後成為apache專案的一部分，kafka是乙個分布式，可劃分的，冗餘備份的永續性的日誌服務，它主要用於處理流式資料。2.為什麼要使用 kafka?為什麼要使用訊息佇列?緩衝和削峰 上游資料時有突發流...