kafka 配置文件詳解（server.properties，producer.properties，consumer.properties）

kafka 配置文件詳解

server.properties

# kafka server配置 kafka最爲重要三個配置依次爲：broker.id、log.dir、zookeeper.connect

# 每一個broker在集羣中的唯一表示，要求是正數。當該服務器的IP地址發生改變時，broker.id沒有變化，則不會影響consumers的消息情況
broker.id=0

# broker的主機地址，若是設置了，那麼會綁定到這個地址上，若是沒有，會綁定到所有的接口上，並將其中之一發送到ZK，一般不設置
host.name=192.168.20.112

# broker server服務端口
port =9092

# broker處理消息的最大線程數，一般情況下數量爲cpu核數
num.network.threads=4

# broker處理磁盤IO的線程數，數值爲cpu核數2倍
num.io.threads=8

# socket的發送緩衝區，socket的調優參數SO_SNDBUFF
socket.send.buffer.bytes=1048576

# socket的接受緩衝區，socket的調優參數SO_RCVBUFF
socket.receive.buffer.bytes=1048576

# socket請求的最大數值，防止serverOOM，message.max.bytes必然要小於socket.request.max.bytes，會被topic創建時的指定參數覆蓋
socket.request.max.bytes=104857600

# 每個topic的分區個數，若是在topic創建時候沒有指定的話會被topic創建時的指定參數覆蓋
num.partitions=2

# 數據文件保留多長時間， 存儲的最大時間超過這個時間會根據log.cleanup.policy設置數據清除策略，log.retention.bytes和log.retention.minutes或log.retention.hours任意一個達到要求，都會執行刪除
# 有2刪除數據文件方式： 按照文件大小刪除：log.retention.bytes  按照2中不同時間粒度刪除：分別爲分鐘，小時
log.retention.hours=168
 
# topic的分區是以一堆segment文件存儲的，這個控制每個segment的大小，會被topic創建時的指定參數覆蓋
log.segment.bytes=536870912

# 文件大小檢查的週期時間，是否處罰 log.cleanup.policy中設置的策略
log.retention.check.interval.ms=60000

# 是否開啓日誌清理
log.cleaner.enable=false

# zookeeper集羣的地址，可以是多個，多個之間用逗號分割 hostname1:port1,hostname2:port2,hostname3:port3
zookeeper.connect=192.168.20.112:2181

# ZooKeeper的連接超時時間
zookeeper.connection.timeout.ms=60000

# ZooKeeper的最大超時時間，就是心跳的間隔，若是沒有反映，那麼認爲已經死了，不易過大
zookeeper.session.timeout.ms=6000

# ZooKeeper集羣中leader和follower之間的同步時間
zookeeper.sync.time.ms =2000

# kafka數據的存放地址，多個地址的話用逗號分割,多個目錄分佈在不同磁盤上可以提高讀寫性能  /data/kafka-logs-1，/data/kafka-logs-2
log.dirs=/data1/ehserver/env/kafka_2.11-2.2.0/logs/kafka-logs-1


# ==========================================不重要非必須配置瞭解 =====================================

# 將默認的 delete 改成壓縮模式 日誌清理策略選擇有：delete和compact主要針對過期數據的處理，或是日誌文件達到限制的額度，會被 topic創建時的指定參數覆蓋
log.cleanup.policy=compact

# 表示消息體的最大大小，單位是字節
message.max.bytes =6525000

# 一些後臺任務處理的線程數，例如過期消息文件的刪除等，一般情況下不需要去做修改
background.threads =4

#等待IO線程處理的請求隊列最大數，若是等待IO的請求超過這個數值，那麼會停止接受外部消息，應該是一種自我保護機制。
queued.max.requests =500

#這個參數會在日誌segment沒有達到log.segment.bytes設置的大小，也會強制新建一個segment會被 topic創建時的指定參數覆蓋
#log.roll.hours =24*7


# topic每個分區的最大文件大小，一個topic的大小限制 = 分區數*log.retention.bytes。-1沒有大小限log.retention.bytes和log.retention.minutes任意一個達到要求，都會執行刪除，會被topic創建時的指定參數覆蓋
# log.retention.bytes=-1

# 日誌清理運行的線程數
log.cleaner.threads = 2

#日誌清理時候處理的最大大小
# log.cleaner.io.max.bytes.per.second=None

# 日誌清理去重時候的緩存空間，在空間允許的情況下，越大越好
# log.cleaner.dedupe.buffer.size=500*1024*1024

# 日誌清理時候用到的IO塊大小一般不需要修改
# log.cleaner.io.buffer.size=512*1024

# 日誌清理中hash表的擴大因子一般不需要修改
log.cleaner.io.buffer.load.factor =0.9

# 檢查是否處罰日誌清理的間隔
log.cleaner.backoff.ms =15000

# 日誌清理的頻率控制，越大意味着更高效的清理，同時會存在一些空間上的浪費，會被topic創建時的指定參數覆蓋
log.cleaner.min.cleanable.ratio=0.5

# 對於壓縮的日誌保留的最長時間，也是客戶端消費消息的最長時間，同log.retention.minutes的區別在於一個控制未壓縮數據，一個控制壓縮後的數據。會被topic創建時的指定參數覆蓋
# log.cleaner.delete.retention.ms =1day

# 對於segment日誌的索引文件大小限制，會被topic創建時的指定參數覆蓋
# log.index.size.max.bytes =10*1024*1024

# 當執行一個fetch操作後，需要一定的空間來掃描最近的offset大小，設置越大，代表掃描速度越快，但是也更好內存，一般情況下不需要搭理這個參數
log.index.interval.bytes =4096

# 表示每當消息記錄數達到1000時flush一次數據到磁盤，log文件”sync”到磁盤之前累積的消息條數,因爲磁盤IO操作是一個慢操作,但又是一個”數據可靠性"的必要手段,所以此參數的設置,需要在"數據可靠性"與"性能"之間做必要的權衡.如果此值過大,將會導致每次"fsync"的時間較長(IO阻塞),如果此值過小,將會導致"fsync"的次數較多,這也意味着整體的client請求有一定的延遲.物理server故障,將會導致沒有fsync的消息丟失.
# log.flush.interval.messages=None 例如log.flush.interval.messages=1000

#檢查是否需要固化到硬盤的時間間隔
log.flush.scheduler.interval.ms =3000


# 僅僅通過interval來控制消息的磁盤寫入時機,是不足的.此參數用於控制"fsync"的時間間隔,如果消息量始終沒有達到閥值,但是離上一次磁盤同步的時間間隔達到閥值,也將觸發.
# log.flush.interval.ms = None 例如：log.flush.interval.ms=1000 表示每間隔1000毫秒flush一次數據到磁盤

# 文件在索引中清除後保留的時間一般不需要去修改
log.delete.delay.ms =60000

# 控制上次固化硬盤的時間點，以便於數據恢復一般不需要去修改
log.flush.offset.checkpoint.interval.ms =60000


# 是否允許自動創建topic，若是false，就需要通過命令創建topic
auto.create.topics.enable =true
default.replication.factor =1



# ===================================以下是kafka中Leader,replicas配置參數================================

## partition leader與replicas之間通訊時,socket的超時時間
#controller.socket.timeout.ms =30000
#
## partition leader與replicas數據同步時,消息的隊列尺寸
#controller.message.queue.size=10
#
##replicas響應partition leader的最長等待時間，若是超過這個時間，就將replicas列入ISR(in-sync replicas)，並認爲它是死的，不會再加入管理中
#replica.lag.time.max.ms =10000
#
## 如果follower落後與leader太多,將會認爲此follower[或者說partition relicas]已經失效。通常,在follower與leader通訊時,因爲網絡延遲或者鏈接斷開,總會導致replicas中消息同步滯後如果消息之後太多,leader將認爲此follower網絡延遲較大或者消息吞吐能力有限,將會把此replicas遷移到其他follower中.在broker數量較少,或者網絡不足的環境中,建議提高此值.
#replica.lag.max.messages =4000
#
## replicas
#replica.socket.timeout.ms=30*1000
#
## leader複製時候的socket緩存大小
#replica.socket.receive.buffer.bytes=64*1024
#
## replicas每次獲取數據的最大大小
#replica.fetch.max.bytes =1024*1024
#
##replicas同leader之間通信的最大等待時間，失敗了會重試
#replica.fetch.wait.max.ms =500
#
##fetch的最小數據尺寸,如果leader中尚未同步的數據不足此值,將會阻塞,直到滿足條件
#replica.fetch.min.bytes =1
#
##leader進行復制的線程數，增大這個數值會增加follower的IO
#num.replica.fetchers=1
#
## 每個replica檢查是否將最高水位進行固化的頻率
#replica.high.watermark.checkpoint.interval.ms =5000
#
## 是否允許控制器關閉broker ,若是設置爲true,會關閉所有在這個broker上的leader，並轉移到其他broker
#controlled.shutdown.enable =false
#
##控制器關閉的嘗試次數
#controlled.shutdown.max.retries =3
#
## 每次關閉嘗試的時間間隔
#controlled.shutdown.retry.backoff.ms =5000
#
## leader的不平衡比例，若是超過這個數值，會對分區進行重新的平衡
#leader.imbalance.per.broker.percentage =10
#
## 檢查leader是否不平衡的時間間隔
#leader.imbalance.check.interval.seconds =300
#
##客戶端保留offset信息的最大空間大小
#offset.metadata.max.bytes



#   FORMAT:
#     listeners = listener_name://host_name:port
#   EXAMPLE:
#     listeners = PLAINTEXT://your.host.name:9092
# 這是默認配置，使用PLAINTEXT，端口是9092， tcp用來監控的kafka端口
listeners=PLAINTEXT://192.168.20.112:9092



# The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.
# This value is recommended to be increased for installations with data dirs located in RAID array.
num.recovery.threads.per.data.dir=1

############################# Internal Topic Settings  #############################
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state"
# For anything other than development testing, a value greater than 1 is recommended for to ensure availability such as 3.
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1

# The following configuration specifies the time, in milliseconds, that the GroupCoordinator will delay the initial consumer rebalance.
# The rebalance will be further delayed by the value of group.initial.rebalance.delay.ms as new members join the group, up to a maximum of max.poll.interval.ms.
# The default value for this is 3 seconds.
# We override this to 0 here as it makes for a better out-of-the-box experience for development and testing.
# However, in production environments the default value of 3 seconds is more suitable as this will help to avoid unnecessary, and potentially expensive, rebalances during application startup.
group.initial.rebalance.delay.ms=0

producer.properties

#指定kafka節點列表，用於獲取metadata，不必全部指定
#需要kafka的服務器地址，來獲取每一個topic的分片數等元數據信息。
metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092

#生產者生產的消息被髮送到哪個block，需要一個分組策略。
#指定分區處理類。默認kafka.producer.DefaultPartitioner，表通過key哈希到對應分區
#partitioner.class=kafka.producer.DefaultPartitioner

#生產者生產的消息可以通過一定的壓縮策略（或者說壓縮算法）來壓縮。消息被壓縮後發送到broker集羣，
#而broker集羣是不會進行解壓縮的，broker集羣只會把消息發送到消費者集羣，然後由消費者來解壓縮。
#是否壓縮，默認0表示不壓縮，1表示用gzip壓縮，2表示用snappy壓縮。
#壓縮後消息中會有頭來指明消息壓縮類型，故在消費者端消息解壓是透明的無需指定。
#文本數據會以1比10或者更高的壓縮比進行壓縮。
compression.codec=none

#指定序列化處理類，消息在網絡上傳輸就需要序列化，它有String、數組等許多種實現。
serializer.class=kafka.serializer.DefaultEncoder

#如果要壓縮消息，這裏指定哪些topic要壓縮消息，默認empty，表示不壓縮。
#如果上面啓用了壓縮，那麼這裏就需要設置
#compressed.topics= 
#這是消息的確認機制，默認值是0。在面試中常被問到。
#producer有個ack參數，有三個值，分別代表：
#（1）不在乎是否寫入成功；
#（2）寫入leader成功；
#（3）寫入leader和所有副本都成功；
#要求非常可靠的話可以犧牲性能設置成最後一種。
#爲了保證消息不丟失，至少要設置爲1，也就
#是說至少保證leader將消息保存成功。
#設置發送數據是否需要服務端的反饋,有三個值0,1,-1，分別代表3種狀態：
#0: producer不會等待broker發送ack。生產者只要把消息發送給broker之後，就認爲發送成功了，這是第1種情況；
#1: 當leader接收到消息之後發送ack。生產者把消息發送到broker之後，並且消息被寫入到本地文件，才認爲發送成功，這是第二種情況；#-1: 當所有的follower都同步消息成功後發送ack。不僅是主的分區將消息保存成功了，
#而且其所有的分區的副本數也都同步好了，纔會被認爲發動成功，這是第3種情況。
request.required.acks=0

#broker必須在該時間範圍之內給出反饋，否則失敗。
#在向producer發送ack之前,broker允許等待的最大時間 ，如果超時,
#broker將會向producer發送一個error ACK.意味着上一次消息因爲某種原因
#未能成功(比如follower未能同步成功)
request.timeout.ms=10000

#生產者將消息發送到broker，有兩種方式，一種是同步，表示生產者發送一條，broker就接收一條；
#還有一種是異步，表示生產者積累到一批的消息，裝到一個池子裏面緩存起來，再發送給broker，
#這個池子不會無限緩存消息，在下面，它分別有一個時間限制（時間閾值）和一個數量限制（數量閾值）的參數供我們來設置。
#一般我們會選擇異步。
#同步還是異步發送消息，默認“sync”表同步，"async"表異步。異步可以提高發送吞吐量,
#也意味着消息將會在本地buffer中,並適時批量發送，但是也可能導致丟失未發送過去的消息
producer.type=sync

#在async模式下,當message被緩存的時間超過此值後,將會批量發送給broker,
#默認爲5000ms
#此值和batch.num.messages協同工作.
queue.buffering.max.ms = 5000

#異步情況下，緩存中允許存放消息數量的大小。
#在async模式下,producer端允許buffer的最大消息量
#無論如何,producer都無法儘快的將消息發送給broker,從而導致消息在producer端大量沉積
#此時,如果消息的條數達到閥值,將會導致producer端阻塞或者消息被拋棄，默認爲10000條消息。
queue.buffering.max.messages=20000

#如果是異步，指定每次批量發送數據量，默認爲200
batch.num.messages=500

#在生產端的緩衝池中，消息發送出去之後，在沒有收到確認之前，該緩衝池中的消息是不能被刪除的，
#但是生產者一直在生產消息，這個時候緩衝池可能會被撐爆，所以這就需要有一個處理的策略。
#有兩種處理方式，一種是讓生產者先別生產那麼快，阻塞一下，等會再生產；另一種是將緩衝池中的消息清空。
#當消息在producer端沉積的條數達到"queue.buffering.max.meesages"後阻塞一定時間後,
#隊列仍然沒有enqueue(producer仍然沒有發送出任何消息)
#此時producer可以繼續阻塞或者將消息拋棄,此timeout值用於控制"阻塞"的時間
#-1: 不限制阻塞超時時間，讓produce一直阻塞,這個時候消息就不會被拋棄
#0: 立即清空隊列,消息被拋棄
queue.enqueue.timeout.ms=-1


#當producer接收到error ACK,或者沒有接收到ACK時,允許消息重發的次數
#因爲broker並沒有完整的機制來避免消息重複,所以當網絡異常時(比如ACK丟失)
#有可能導致broker接收到重複的消息,默認值爲3.
message.send.max.retries=3

#producer刷新topic metada的時間間隔,producer需要知道partition leader
#的位置,以及當前topic的情況
#因此producer需要一個機制來獲取最新的metadata,當producer遇到特定錯誤時,
#將會立即刷新
#(比如topic失效,partition丟失,leader失效等),此外也可以通過此參數來配置
#額外的刷新機制，默認值600000
topic.metadata.refresh.interval.ms=60000

consumer.properties

#消費者集羣通過連接Zookeeper來找到broker。
#zookeeper連接服務器地址
zookeeper.connect=zk01:2181,zk02:2181,zk03:2181

#zookeeper的session過期時間，默認5000ms，用於檢測消費者是否掛掉
zookeeper.session.timeout.ms=5000

#當消費者掛掉，其他消費者要等該指定時間才能檢查到並且觸發重新負載均衡
zookeeper.connection.timeout.ms=10000

#這是一個時間閾值。
#指定多久消費者更新offset到zookeeper中。
#注意offset更新時基於time而不是每次獲得的消息。
#一旦在更新zookeeper發生異常並重啓，將可能拿到已拿到過的消息
zookeeper.sync.time.ms=2000

#Consumer歸屬的組ID，broker是根據group.id來判斷是隊列模式還是發佈訂閱模式，非常重要
group.id=xxxxx

#這是一個數量閾值，經測試是500條。
#當consumer消費一定量的消息之後,將會自動向zookeeper提交offset信息#注意offset信息並不是每消費一次消息就向zk提交
#一次,而是現在本地保存(內存),並定期提交,默認爲true
auto.commit.enable=true

# 自動更新時間。默認60 * 1000
auto.commit.interval.ms=1000

# 當前consumer的標識,可以設定,也可以有系統生成,
#主要用來跟蹤消息消費情況,便於觀察
conusmer.id=xxx

# 消費者客戶端編號，用於區分不同客戶端，默認客戶端程序自動產生
client.id=xxxx

# 最大取多少塊緩存到消費者(默認10)
queued.max.message.chunks=50

# 當有新的consumer加入到group時,將會reblance,此後將會
#有partitions的消費端遷移到新  的consumer上,如果一個
#consumer獲得了某個partition的消費權限,那麼它將會向zk
#註冊 "Partition Owner registry"節點信息,但是有可能
#此時舊的consumer尚沒有釋放此節點, 此值用於控制,
#註冊節點的重試次數.
rebalance.max.retries=5

#每拉取一批消息的最大字節數
#獲取消息的最大尺寸,broker不會像consumer輸出大於
#此值的消息chunk 每次feth將得到多條消息,此值爲總大小,
#提升此值,將會消耗更多的consumer端內存
fetch.min.bytes=6553600

#當消息的尺寸不足時,server阻塞的時間,如果超時,
#消息將立即發送給consumer
#數據一批一批到達，如果每一批是10條消息，如果某一批還
#不到10條，但是超時了，也會立即發送給consumer。
fetch.wait.max.ms=5000
socket.receive.buffer.bytes=655360

# 如果zookeeper沒有offset值或offset值超出範圍。
#那麼就給個初始的offset。有smallest、largest、
#anything可選，分別表示給當前最小的offset、
#當前最大的offset、拋異常。默認largest
auto.offset.reset=smallest

# 指定序列化處理類
derializer.class=kafka.serializer.DefaultDecoder

 

每天努力一點，每天都在進步。