kafka_zookeeper_配置文件配置

server.properties配置以下：

broker.id= 0

num.network.threads= 2

num.io.threads= 8

socket.send.buffer.bytes= 1048576

socket.receive.buffer.bytes= 1048576

socket.request.max.bytes= 104857600

log.dirs=/tmp/kafka-logs

num.partitions= 2

log.retention.hours= 168

 

log.segment.bytes= 536870912

log.retention.check.interval.ms= 60000

log.cleaner.enable= false

 

zookeeper.connect=localhost: 2181

zookeeper.connection.timeout.ms= 1000000

 

指定每個server.properties對應項的含義：

參數

說明(解釋)

broker.id = 0

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

log.dirs=/data/kafka-logs

kafka數據的存放地址，多個地址的話用逗號分割 /data/kafka-logs- 1 ，/data/kafka-logs- 2

port = 9092

broker server服務端口

message.max.bytes = 6525000

表示消息體的最大大小，單位是字節

num.network.threads = 4

broker處理消息的最大線程數，通常狀況下不須要去修改

num.io.threads = 8

broker處理磁盤IO的線程數，數值應該大於你的硬盤數

background.threads = 4

一些後臺任務處理的線程數，例如過時消息文件的刪除等，通常狀況下不須要去作修改

queued.max.requests = 500

等待IO線程處理的請求隊列最大數，如果等待IO的請求超過這個數值，那麼會中止接受外部消息，應該是一種自我保護機制。

host.name

broker的主機地址，如果設置了，那麼會綁定到這個地址上，如果沒有，會綁定到全部的接口上，並將其中之一發送到ZK，通常不設置

socket.send.buffer.bytes= 100 * 1024

socket的發送緩衝區，socket的調優參數SO_SNDBUFF

socket.receive.buffer.bytes = 100 * 1024

socket的接受緩衝區，socket的調優參數SO_RCVBUFF

socket.request.max.bytes = 100 * 1024 * 1024

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

log.segment.bytes = 1024 * 1024 * 1024

topic的分區是以一堆segment文件存儲的，這個控制每一個segment的大小，會被topic建立時的指定參數覆蓋

log.roll.hours = 24 * 7

這個參數會在日誌segment沒有達到log.segment.bytes設置的大小，也會強制新建一個segment會被 topic建立時的指定參數覆蓋

log.cleanup.policy = delete

日誌清理策略選擇有：delete和compact主要針對過時數據的處理，或是日誌文件達到限制的額度，會被 topic建立時的指定參數覆蓋

log.retention.minutes=3days

數據存儲的最大時間超過這個時間會根據log.cleanup.policy設置的策略處理數據，也就是消費端可以多久去消費數據

log.retention.bytes和log.retention.minutes任意一個達到要求，都會執行刪除，會被topic建立時的指定參數覆蓋

log.retention.bytes=- 1

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

log.retention.check.interval.ms=5minutes

文件大小檢查的週期時間，是否處罰 log.cleanup.policy中設置的策略

log.cleaner.enable= false

是否開啓日誌壓縮

log.cleaner.threads =  2

日誌壓縮運行的線程數

log.cleaner.io.max.bytes.per.second=None

日誌壓縮時候處理的最大大小

log.cleaner.dedupe.buffer.size= 500 * 1024 * 1024

日誌壓縮去重時候的緩存空間，在空間容許的狀況下，越大越好

log.cleaner.io.buffer.size= 512 * 1024

日誌清理時候用到的IO塊大小通常不須要修改

log.cleaner.io.buffer.load.factor = 0.9

日誌清理中hash表的擴大因子通常不須要修改

log.cleaner.backoff.ms = 15000

檢查是否處罰日誌清理的間隔

log.cleaner.min.cleanable.ratio= 0.5

日誌清理的頻率控制，越大意味着更高效的清理，同時會存在一些空間上的浪費，會被topic建立時的指定參數覆蓋

log.cleaner.delete.retention.ms =1day

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

log.index.size.max.bytes = 10 * 1024 * 1024

對於segment日誌的索引文件大小限制，會被topic建立時的指定參數覆蓋

log.index.interval.bytes = 4096

當執行一個fetch操做後，須要必定的空間來掃描最近的offset大小，設置越大，表明掃描速度越快，可是也更好內存，通常狀況下不須要搭理這個參數

log.flush.interval.messages=None

log文件」sync」到磁盤以前累積的消息條數,由於磁盤IO操做是一個慢操做,但又是一個」數據可靠性 "的必要手段,因此此參數的設置,須要在" 數據可靠性 "與" 性能 "之間作必要的權衡.若是此值過大,將會致使每次" fsync "的時間較長(IO阻塞),若是此值太小,將會致使" fsync"的次數較多,這也意味着總體的client請求有必定的延遲.物理server故障,將會致使沒有fsync的消息丟失.

log.flush.scheduler.interval.ms = 3000

檢查是否須要固化到硬盤的時間間隔

log.flush.interval.ms = None

僅僅經過interval來控制消息的磁盤寫入時機,是不足的.此參數用於控制 "fsync" 的時間間隔,若是消息量始終沒有達到閥值,可是離上一次磁盤同步的時間間隔達到閥值,也將觸發.

log.delete.delay.ms = 60000

文件在索引中清除後保留的時間通常不須要去修改

log.flush.offset.checkpoint.interval.ms = 60000

控制上次固化硬盤的時間點，以便於數據恢復通常不須要去修改

auto.create.topics.enable = true

是否容許自動建立topic，如果 false ，就須要經過命令建立topic

default .replication.factor = 1

是否容許自動建立topic，如果 false ，就須要經過命令建立topic

num.partitions = 1

每一個topic的分區個數，如果在topic建立時候沒有指定的話會被topic建立時的指定參數覆蓋

 

 

如下是kafka中Leader,replicas配置參數

 

controller.socket.timeout.ms = 30000

partition leader與replicas之間通信時,socket的超時時間

controller.message.queue.size= 10

partition leader與replicas數據同步時,消息的隊列尺寸

replica.lag.time.max.ms = 10000

replicas響應partition leader的最長等待時間，如果超過這個時間，就將replicas列入ISR(in-sync replicas)，並認爲它是死的，不會再加入管理中

replica.lag.max.messages = 4000

若是follower落後與leader太多,將會認爲此follower[或者說partition relicas]已經失效

##一般,在follower與leader通信時,由於網絡延遲或者連接斷開,總會致使replicas中消息同步滯後

##若是消息以後太多,leader將認爲此follower網絡延遲較大或者消息吞吐能力有限,將會把此replicas遷移

##到其餘follower中.

##在broker數量較少,或者網絡不足的環境中,建議提升此值.

replica.socket.timeout.ms= 30 * 1000

follower與leader之間的socket超時時間

replica.socket.receive.buffer.bytes= 64 * 1024

leader複製時候的socket緩存大小

replica.fetch.max.bytes = 1024 * 1024

replicas每次獲取數據的最大大小

replica.fetch.wait.max.ms = 500

replicas同leader之間通訊的最大等待時間，失敗了會重試

replica.fetch.min.bytes = 1

fetch的最小數據尺寸,若是leader中還沒有同步的數據不足此值,將會阻塞,直到知足條件

num.replica.fetchers= 1

leader進行復制的線程數，增大這個數值會增長follower的IO

replica.high.watermark.checkpoint.interval.ms = 5000

每一個replica檢查是否將最高水位進行固化的頻率

controlled.shutdown.enable = false

是否容許控制器關閉broker ,如果設置爲 true ,會關閉全部在這個broker上的leader，並轉移到其餘broker

controlled.shutdown.max.retries = 3

控制器關閉的嘗試次數

controlled.shutdown.retry.backoff.ms = 5000

每次關閉嘗試的時間間隔

leader.imbalance.per.broker.percentage = 10

leader的不平衡比例，如果超過這個數值，會對分區進行從新的平衡

leader.imbalance.check.interval.seconds = 300

檢查leader是否不平衡的時間間隔

offset.metadata.max.bytes

客戶端保留offset信息的最大空間大小

kafka中zookeeper參數配置

 

zookeeper.connect = localhost: 2181

zookeeper集羣的地址，能夠是多個，多個之間用逗號分割 hostname1:port1,hostname2:port2,hostname3:port3

zookeeper.session.timeout.ms= 6000

ZooKeeper的最大超時時間，就是心跳的間隔，如果沒有反映，那麼認爲已經死了，不易過大

zookeeper.connection.timeout.ms = 6000

ZooKeeper的鏈接超時時間

zookeeper.sync.time.ms = 2000

ZooKeeper集羣中leader和follower之間的同步實際那