1、Offset如何標記數據
每個分區的offset都是從1開始標記的
每個分區將數據切分成segment（段），每個段由log和index兩份文件組成
假設一個Topic的數據，有三個分區，存了4500條數據：
ruozedata-0 1開始標記…
ruozedata-1 1開始標記…
ruozedata-2 1開始標記…
命名規則：
第一組0開頭，存了1000條：
00000000000000000000.index
00000000000000000000.log
第二組，由上一組的最後一條消息的offset來命名，存了2500條：
00000000000000001000.index
00000000000000001000.log
第三組，由第二組的最後一條消息的offset來命名，存了1000條：
00000000000000003500.index
00000000000000003500.log
絕對offset：是關於分區的全局id，比如ruozedata-0分區(3個log文件 全局的id)
相對offset:：存儲在index文件裏，對應其log文件的消息的id，格式是：相對offset-id，對應log的pos位置
index存儲：是稀疏存儲的， log文件裏的每條信息不會都有一個index的，而是挑選的部分index。
舉例，假設mysql一張表維護的offset信息：
對於上面提到的概念，結合這個表，就一目瞭然。
mysql表
globalid sid message
1 1
2 2
3 3
4 4
...
1000 1000
------------------
1001 1
1002 2
1003 3
...
1010 10
...
3500 2500
-----------------
3501 1
3502 2
3503 3
...
4500 1000
2、Offset如何尋址
還是根據上面的例子
假設：尋找offset爲1016的消息是什麼？
這裏的1016是全局的offset，用二分查找法。
第一步，先找到<=1016的最大的segment文件
00000000000000000000.index # [0-1000)
00000000000000000000.log
#那麼此時知道是落在這個區間,在第二個segment裏面，他裏面包含的是[1000-3500)的數據條數信息
00000000000000001000.index
00000000000000001000.log
00000000000000003500.index #[3500,4500]
00000000000000003500.log
第二步，1016-1000=16 爲index的相對offset，去index找 <=16的最大的相對offset
假設index裏面存儲的是這樣的信息，因爲是稀疏存儲，不會存所有的index記錄。
那麼找到的就是： 10,98這一行的信息
第三步，去對應的log文件找到98位置，按順序往下讀到第16條消息即可，我們要的是第16條的信息，而index只維護了第10條所在位置的信息，所以最優位置只能從第10所在的位置開始讀。
#讀log文件，98位置，按順序讀到第16條
00000000000000001000.log
3、消費模式
at most once ：最多消費一次 0/1 可能丟數據，但是不重複
at least once：至少消費一次 >=1 不丟數據 但是會重複（實際工作中常用）
exactly once:：精準消費一次 1 不丟 也不重複
4、參數調優
配置文件，主要是這三個
[hadoop@vm01 config]$ ll
-rw-r--r--. 1 hadoop hadoop 1221 Nov 9 2018 consumer.properties
-rw-r--r--. 1 hadoop hadoop 1925 Nov 9 2018 producer.properties
-rw-r--r--. 1 hadoop hadoop 6963 Aug 9 09:54 server.properties
#producer
#這意味着領導者將等待完整的同步副本來確認記錄。leader是用來讀寫，另外倆副本用來同步
#這保證了只要至少有一個同步副本仍然存在，記錄就不會丟失。這是最有力的保證
acks=all
#生產者可用於緩衝等待發送到服務器的記錄的總內存字節數。
#如果記錄發送的速度比發送到服務器的速度快，那麼生產者將阻塞max.block。之後，它將拋出異常。
buffer.memory
#生成器生成的所有數據的壓縮類型。默認值是none(即沒有壓縮)
compression.type = snappy
#重試次數
retries=100
#客戶機在阻塞之前在單個連接上發送的未確認請求的最大數量。
#注意，如果該設置被設置爲大於1且發送失敗，則由於重試(即，如果啓用重試功能)。
max.in.flight.requests.per.connection=1
#當多個記錄被髮送到同一個分區時，生產者將嘗試將這些記錄一起批處理成更少的請求。
#這有助於提高客戶機和服務器的性能。此配置以字節爲單位控制默認批處理大小。
batch.size
#此設置將限制生產者在單個請求中發送的記錄批次的數量，以避免發送巨大的請求。
#這也有效地限制了最大記錄批大小。注意，服務器對記錄批大小有自己的上限，這可能與此不同。
max.request.size
#客戶機等待請求響應的最大時間量
request.timeout.ms
timeout.ms
#Broker/server
advertised.host.name ?????
#Kafka允許的最大記錄批大小
message.max.bytes
#服務器用於處理請求的線程數，可能包括磁盤I/O
num.io.threads
#服務器用於從網絡接收請求並向網絡發送響應的線程數
num.network.threads
#客戶端等待與zookeeper建立連接的最長時間
zookeeper.connection.timeout.ms
#zookeeper會話超時
zookeeper.session.timeout
#consumer: new
#服務器應該爲獲取請求返回的最大數據量。
fetch.message.max.bytes
#如果爲真，使用者的偏移量將在後臺定期提交。
auto.commit.enable : false
#當Kafka中沒有初始偏移量，或者當前偏移量在服務器上不存在時(例如，因爲數據已被刪除)，該怎麼辦?
#earliest: 自動重置偏移到最早的偏移
#latest:自動將偏移量重置爲最新偏移量
#none: 如果沒有爲使用者的組找到以前的偏移量，則向使用者拋出異常
#anything else:向使用者拋出異常。
auto.offset.reset
"auto.offset.reset" -> "latest",
"enable.auto.commit" -> (false: java.lang.Boolean)
#如果enable.auto.commit設置爲true，則使用者偏移量自動提交到Kafka的頻率(以毫秒爲單位)。
auto.commit.interval.ms