此篇文章是我從官網拿來的資料自己打了4個多小時翻譯的，給大家參考Server端的配置
NAME | DESCRIPTION | TYPE | DEFAULT | VALID VALUES | IMPORTANCE | ||||||
zookeeper.connect | Zookeeper host string | string |
|
| high | ||||||
advertised.host.name | 打廣告的地址，若是設置的話，會提供給producers, consumers,其他broker連接，具體如何使用還未深究 | string |
|
| high | ||||||
advertised.listeners | 打廣告的地址，若是設置的話，會提供給producers, consumers,其他broker連接，具體如何使用還未深究 | string |
|
| high | ||||||
advertised.port | 只在“廣告”、“聽衆”或“聽衆”沒有設置時使用。改爲使用“廣告。聽衆”。該端口發佈給動物園管理員供客戶使用。在IaaS環境中，這可能需要與代理綁定的端口不同。如果沒有設置，它將發佈代理綁定到的端口。 | int |
|
| high | ||||||
auto.create.topics.enable | 啓用服務器上的主題自動創建
| boolean | true |
| high | ||||||
auto.leader.rebalance.enable | 是否自動平衡broker之間的分配策略 | boolean | true |
| high | ||||||
background.threads | 一些後臺任務處理的線程數，例如過期消息文件的刪除等，一般情況下不需要去做修改 | int | 10 | [1,...] | high | ||||||
broker.id | 每一個broker在集羣中的唯一標示，要求是正數。在改變IP地址，不改變broker.id的話不會影響consumers | int | -1 |
| high | ||||||
compression.type | 指定給定主題的最終壓縮類型。此配置接受標準壓縮編解碼器('gzip', 'snappy', 'lz4')。它還接受“uncompressed”，這相當於沒有壓縮；和“producer”，這意味着保留原始壓縮編解碼器設置的producer。 | string | producer |
| high | ||||||
delete.topic.enable | 啓用刪除主題。如果這個配置被關閉，通過管理工具刪除主題將不起作用。 | boolean | true |
| high | ||||||
host.name | broker的主機地址，若是設置了，那麼會綁定到這個地址上，若是沒有，會綁定到所有的接口上，並將其中之一發送到ZK，一般成自己的ip | string | "" |
| high | ||||||
leader.imbalance.check.interval.seconds | 檢查leader是否不平衡的時間間隔 | long | 300 |
| high | ||||||
leader.imbalance.per.broker.percentage | leader的不平衡比例，若是超過這個數值，會對分區進行重新的平衡 | int | 10 |
| high | ||||||
listeners | 偵聽器列表-逗號分隔的URI列表，我們將偵聽和偵聽器名稱。如果偵聽器名稱不是安全協議，也必須設置ListEn.SaleTy.Primo.Mp。指定主機名爲0.0.0.0以綁定到所有接口。將主機名空到綁定到默認接口。合法聽衆列表的例子：明文：//MyHub：9092，SSL://:9091客戶端：//0.0.0.0:9092，複製：//LoalHoo: 9093
| string |
|
| high | ||||||
log.dir | Kafka數據存放的目錄。 | string | /tmp/kafka-logs |
| high | ||||||
log.dirs | Kafka數據存放的目錄。可以指定多個目錄，中間用逗號分隔，當新partition被創建的時會被存放到當前存放partition最少的目錄。 | string |
|
| high | ||||||
log.flush.interval.messages | log文件”sync”到磁盤之前累積的消息條數 因爲磁盤IO操作是一個慢操作,但又是一個”數據可靠性”的必要手段 所以此參數的設置,需要在”數據可靠性”與”性能”之間做必要的權衡. 如果此值過大,將會導致每次”fsync”的時間較長(IO阻塞) 如果此值過小,將會導致”fsync”的次數較多,這也意味着整體的client請求有一定的延遲. 物理server故障,將會導致沒有fsync的消息丟失. | long | 9223372036854775807 | [1,...] | high | ||||||
log.flush.interval.ms | 僅僅通過interval來控制消息的磁盤寫入時機,是不足的. 此參數用於控制”fsync”的時間間隔,如果消息量始終沒有達到閥值,但是離上一次磁盤同步的時間間隔 達到閥值,也將觸發. | long |
|
| high | ||||||
log.flush.offset.checkpoint.interval.ms | 控制上次固化硬盤的時間點，以便於數據恢復 一般不需要去修改 | int | 60000 | [0,...] | high | ||||||
log.flush.scheduler.interval.ms | 檢查是否需要固化到硬盤的時間間隔 | long | 9223372036854775807 |
| high | ||||||
log.flush.start.offset.checkpoint.interval.ms | 更新日誌起始偏移的持久記錄的頻率 | int | 60000 | [0,...] | high | ||||||
log.retention.bytes | topic每個分區的最大文件大小，一個topic的大小限制 = 分區數*log.retention.bytes =-1 沒有大小限制 log.retention.bytes和log.retention.minutes任意一個達到要求，都會執行刪除，會被topic創建時的指定參數覆蓋 | long | -1 |
| high | ||||||
log.retention.hours | 在刪除日誌文件之前的小時數 | int | 168 |
| high | ||||||
log.retention.minutes | 數據存儲的最大時間超過這個時間會根據log.cleanup.policy設置的策略處理數據，也就是消費端能夠多久去消費數據 log.retention.bytes和log.retention.minutes任意一個達到要求，都會執行刪除，會被topic創建時的指定參數覆蓋 | int |
|
| high | ||||||
log.retention.ms | 在刪除日誌文件（毫秒）之前保留毫秒數，如果未設置，則使用Log.ReaTime.Mess中的值。 | long |
|
| high | ||||||
log.roll.hours | 這個參數會在日誌segment沒有達到log.segment.bytes設置的大小，也會強制新建一個segment會被 topic創建時的指定參數覆蓋 | int | 168 | [1,...] | high | ||||||
log.roll.jitter.hours | 從logRollTimeMillis（以小時爲單位）減去的最大浮動，繼承於log.roll.jitter.ms屬性 | int | 0 | [0,...] | high | ||||||
log.roll.jitter.ms | 從logRollTimeMillis中減去的最大浮動（以毫秒爲單位）。 如果未設置，則使用log.roll.jitter.hours中的值 | long |
|
| high | ||||||
log.roll.ms | 新日誌段推出之前的最長時間（以毫秒爲單位）。 如果未設置，則使用log.roll.hours中的值 | long |
|
| high | ||||||
log.segment.bytes | 單個日誌文件的最大大小 | int | 1073741824 | [14,...] | high | ||||||
log.segment.delete.delay.ms | 從文件系統中刪除文件之前等待的時間 | long | 60000 | [0,...] | high | ||||||
message.max.bytes | 服務器可以接收的消息的最大大小 | int | 1000012 | [0,...] | high | ||||||
min.insync.replicas | 當生產者將acks設置爲“all”（或“-1”）時，min.insync.replicas指定必須確認寫入的副本的最小數量，以使寫入被認爲成功。 如果這個最小值不能滿足，那麼生產者將引發一個異常（NotEnoughReplicas或NotEnoughReplicasAfterAppend）。當一起使用時，min.insync.replicas和ack允許你強制更強的耐久性保證。 典型的情況是創建一個複製因子爲3的主題，將min.insync.replicas設置爲2，併產生一個“all”的acks。 這將確保生成器在大多數副本沒有接收到寫入時引發異常。 | int | 1 | [1,...] | high | ||||||
num.io.threads | 服務器用於執行網絡請求的io線程數 | int | 8 | [1,...] | high | ||||||
num.network.threads | 服務器用於處理網絡請求的網絡線程數 | int | 3 | [1,...] | high | ||||||
num.recovery.threads.per.data.dir | 每個數據目錄的線程數，用於在啓動時進行日誌恢復並在關閉時刷新 | int | 1 | [1,...] | high | ||||||
num.replica.fetchers | 用於從源broker複製消息的提取線程數。 增加此值可以提高跟隨器broker中的I / O並行度。 | int | 1 |
| high | ||||||
offset.metadata.max.bytes | 與offset提交關聯的元數據條目的最大大小 | int | 4096 |
| high | ||||||
offsets.commit.required.acks | 可以接受提交之前所需的acks。 通常，不應覆蓋默認值（-1） | short | -1 |
| high | ||||||
offsets.commit.timeout.ms | 偏移提交將被延遲，直到偏移主題的所有副本都收到提交或達到此超時。 這類似於生產者請求超時。 | int | 5000 | [1,...] | high | ||||||
offsets.load.buffer.size | 用於在將偏移量裝入緩存時從偏移段讀取的批量大小。 | int | 5242880 | [1,...] | high | ||||||
offsets.retention.check.interval.ms | 檢查舊偏移的頻率 | long | 600000 | [1,...] | high | ||||||
offsets.retention.minutes | 偏移topic的日誌保留時間（分鐘） | int | 1440 | [1,...] | high | ||||||
offsets.topic.compression.codec | 用於偏移topic的壓縮編解碼器 - 壓縮可以用於實現“原子”提交 | int | 0 |
| high | ||||||
offsets.topic.num.partitions | 偏移提交topic的分區數（部署後不應更改） | int | 50 | [1,...] | high | ||||||
offsets.topic.replication.factor | 偏移量主題的複製因子（設置爲更高以確保可用性）。內部主題創建將失敗，直到集羣大小滿足此複製因子要求。
| short | 3 | [1,...] | high | ||||||
offsets.topic.segment.bytes | 偏移主題段字節應保持相對較小，以便於加快日誌壓縮和緩存加載 | int | 104857600 | [1,...] | high | ||||||
port | 棄用的：僅在未設置`listeners`時使用。 使用`listeners`代替。 | int | 9092 |
| high | ||||||
queued.max.requests | 在阻止網絡線程之前允許的排隊請求數 | int | 500 | [1,...] | high | ||||||
quota.consumer.default | 棄用的：僅當未在Zookeeper中或在Zookeeper中配置動態默認配額時使用。 由clientId / consumer組區分的任何消費者如果每秒獲取的字節數超過此值，則會受到限制 | long | 9223372036854775807 | [1,...] | high | ||||||
quota.producer.default | 棄用的：僅在未配置動態默認配額時使用，或在Zookeeper中使用。 由clientId區分的任何生產者如果每秒產生的字節數大於此值，則會受到限制
| long | 9223372036854775807 | [1,...] | high | ||||||
replica.fetch.min.bytes | 每個獲取響應所需的最小字節數。 如果沒有足夠的字節，請等待到replicaMaxWaitTimeMs | int | 1 |
| high | ||||||
replica.fetch.wait.max.ms | 由跟隨者副本發出的每個獲取器請求的最大等待時間。 此值應始終小於replica.lag.time.max.ms以防止低吞吐量topic的ISR頻繁收縮 | int | 500 |
| high | ||||||
replica.high.watermark.checkpoint.interval.ms | 保存到磁盤的頻率 | long | 5000 |
| high | ||||||
replica.lag.time.max.ms | 如果跟隨者沒有發送任何提取請求，或者至少沒有消耗到領導者日誌結束偏移，則領導者將從ISR移除跟隨者。
| long | 10000 |
| high | ||||||
replica.socket.receive.buffer.bytes | 用於網絡請求的套接字接收緩衝區 | int | 65536 |
| high | ||||||
replica.socket.timeout.ms | 網絡請求的套接字超時。 其值應至少爲replica.fetch.wait.max.ms | int | 30000 |
| high | ||||||
request.timeout.ms | 配置控制客戶端等待請求響應的最大時間量。 如果在超時時間之前沒有收到響應，客戶端將在必要時重新發送請求，如果重試次數耗盡，則請求失敗。 | int | 30000 |
| high | ||||||
socket.receive.buffer.bytes | 套接字服務器的SO_RCVBUF緩衝區插槽。 如果值爲-1，將使用操作系統默認值。 | int | 102400 |
| high | ||||||
socket.request.max.bytes | 套接字請求中的最大字節數 | int | 104857600 | [1,...] | high | ||||||
socket.send.buffer.bytes | 套接字服務器的SO_SNDBUF緩衝區插槽。 如果值爲-1，將使用操作系統默認值。 | int | 102400 |
| high | ||||||
transaction.max.timeout.ms | 事務的最大允許超時時間。如果客戶端請求的事務時間超過此，則代理將返回InitProducerIdRequest中的錯誤。這樣可以防止客戶端超時過大，這會阻止消費者從事務中包含的主題中讀取信息。
| int | 900000 | [1,...] | high | ||||||
transaction.state.log.load.buffer.size | 當將生產者ID和事務加載到緩存中時，從事務日誌段讀取的批大小。
| int | 5242880 | [1,...] | high | ||||||
transaction.state.log.min.isr | 覆蓋事務主題的min.insync.replicas配置。 | int | 2 | [1,...] | high | ||||||
transaction.state.log.num.partitions | 事務主題的分區數量（部署後不應更改）。 | int | 50 | [1,...] | high | ||||||
transaction.state.log.replication.factor | 事務主題的複製因子（設置更高以確保可用性）。 內部主題創建將失敗，直到羣集大小滿足此複製因素要求。 | short | 3 | [1,...] | high | ||||||
transaction.state.log.segment.bytes | 事務主題段字節應保持相對較小，以便於更快的日誌壓縮和緩存負載 | int | 104857600 | [1,...] | high | ||||||
transactional.id.expiration.ms | 事務協調器在未收到任何事務狀態更新之前，主動設置生產者的事務標識爲過期之前將等待的最長時間（以毫秒爲單位）。 | int | 604800000 | [1,...] | high | ||||||
unclean.leader.election.enable | 指明瞭是否能夠使不在ISR中replicas follower設置用來作爲leader | boolean | false |
| high | ||||||
zookeeper.connection.timeout.ms | 連接到ZK server的超時時間,沒有配置就使用zookeeper.session.timeout.ms | int |
|
| high | ||||||
zookeeper.session.timeout.ms | ZooKeeper的session的超時時間，如果在這段時間內沒有收到ZK的心跳，則會被認爲該Kafka server掛掉了。如果把這個值設置得過低可能被誤認爲掛掉，如果設置得過高，如果真的掛了，則需要很長時間才能被server得知。 | int | 6000 |
| high | ||||||
zookeeper.set.acl | 連接zookeeper是否使用 ACLs安全驗證 | boolean | false |
| high | ||||||
broker.id.generation.enable | 服務器是否允許自動生成broker.id；如果允許則產生的值會交由reserved.broker.max.id審覈 | boolean | true |
| medium | ||||||
broker.rack | broker的機架位置。 這將在機架感知複製分配中用於容錯。 例如：RACK1，us-east-1d | string |
|
| medium | ||||||
connections.max.idle.ms | 空閒連接超時：服務器套接字處理器線程關閉閒置超過此的連接 | long | 600000 |
| medium | ||||||
controlled.shutdown.enable | 是否允許控制器關閉broker ,若是設置爲true,會關閉在這個broker上所有分區的leader，並轉移到其他broker，這會降低在關閉期間不可用的時間。 | boolean | true |
| medium | ||||||
controlled.shutdown.max.retries | 控制器在關閉時可能有多種原因導致失敗，可以重新關閉的次數。 | int | 3 |
| medium | ||||||
controlled.shutdown.retry.backoff.ms | 在每次重新關閉前，系統需要一定的時間去恢復發生錯誤之前的狀態，這個就是在重試期間的回退(backoff)時間。 | long | 5000 |
| medium | ||||||
controller.socket.timeout.ms | 控制器到broker通道的socket超時時間 | int | 30000 |
| medium | ||||||
default.replication.factor | 自動創建topic時的默認副本的個數 | int | 1 |
| medium | ||||||
delete.records.purgatory.purge.interval.requests | 刪除記錄請求的清除間隔（請求次數） | int | 1 |
| medium | ||||||
fetch.purgatory.purge.interval.requests | 取回請求的清除間隔（請求次數）
| int | 1000 |
| medium | ||||||
group.initial.rebalance.delay.ms | 在執行第一次再平衡之前，group協調員將等待更多消費者加入group的時間。 延遲時間越長意味着重新平衡的可能性越小，但是等待處理開始的時間增加
| int | 3000 |
| medium | ||||||
group.max.session.timeout.ms | 消費者向組內註冊時允許的最大超時時間，超過這個時間表示註冊失敗。更長的超時使消費者有更多的時間來處理心跳之間的消息，代價是檢測失敗的時間更長。 | int | 300000 |
| medium | ||||||
group.min.session.timeout.ms | 消費者向組內註冊時允許的最小超時時間，更短的超時以更頻繁的消費者心跳爲代價但有更快速的故障檢測，這可能影響broker資源。 | int | 6000 |
| medium | ||||||
inter.broker.listener.name | 用於經紀人之間溝通的監聽者名稱。如果未設置，則偵聽器名稱由security.inter.broker.protocol定義。 同時設置此和security.inter.broker.protocol屬性是錯誤的。 | string |
|
| medium | ||||||
inter.broker.protocol.version | 指定將使用哪個版本的 inter-broker 協議。 在所有經紀人升級到新版本之後，這通常會受到衝擊。升級時要設置 | string | 1.0-IV0 |
| medium | ||||||
log.cleaner.backoff.ms | 檢查log是否需要clean的時間間隔。 | long | 15000 | [0,...] | medium | ||||||
log.cleaner.dedupe.buffer.size | 日誌壓縮去重時候的緩存空間，在空間允許的情況下，越大越好。 | long | 134217728 |
| medium | ||||||
log.cleaner.delete.retention.ms | 對於壓縮的日誌保留的最長時間，也是客戶端消費消息的最長時間，同log.retention.minutes的區別在於一個控制未壓縮數據，一個控制壓縮後的數據。 | long | 86400000 |
| medium | ||||||
log.cleaner.enable | 啓用日誌清理器進程在服務器上運行。使用了cleanup.policy = compact的主題，包括內部offsets主題，都應該啓動該選項。如果被禁用的話，這些話題將不會被壓縮，並且會不斷增長。 | boolean | true |
| medium | ||||||
log.cleaner.io.buffer.load.factor | 日誌清理中hash表的擴大因子，一般不需要修改。 | double | 0.9 |
| medium | ||||||
log.cleaner.io.buffer.size | 日誌清理時候用到的I/O塊(chunk)大小，一般不需要修改。 | int | 524288 | [0,...] | medium | ||||||
log.cleaner.io.max.bytes.per.second | 在執行log compaction的過程中，限制了cleaner每秒鐘I/O的數據量，以免cleaner影響正在執行的請求。 | double | 1.7976931348623157E308 |
| medium | ||||||
log.cleaner.min.cleanable.ratio | 控制了log compactor進行clean操作的頻率。默認情況下，當log的50%以上已被clean時，就不用繼續clean了。此配置可以被覆蓋。 | double | 0.5 |
| medium | ||||||
log.cleaner.min.compaction.lag.ms | 消息在日誌中保持未壓縮的最短時間。 僅適用於正在壓縮的日誌。 | long | 0 |
| medium | ||||||
log.cleaner.threads | 用於日誌清理的後臺線程的數量 | int | 1 | [0,...] | medium | ||||||
log.cleanup.policy | 此配置可以設置成delete或compact。如果設置爲delete，當log segment文件的大小達到上限，或者roll時間達到上限，文件將會被刪除。如果設置成compact，則此文件會被清理，標記成已過時狀態，詳見 4.8 。此配置可以被覆蓋。 | list | delete | [compact, delete] | medium | ||||||
log.index.interval.bytes | 當執行一個fetch操作後，需要一定的空間來掃描最近的offset大小，設置越大，代表掃描速度越快，但是也更耗內存，一般情況下不需要改變這個參數。 | int | 4096 | [0,...] | medium | ||||||
log.index.size.max.bytes | 每個log segment的最大尺寸。注意，如果log尺寸達到這個數值，即使尺寸沒有超過log.segment.bytes限制，也需要產生新的log segment。 | int | 10485760 | [4,...] | medium | ||||||
log.message.format.version | 指定broker將用於將消息添加到日誌文件的消息格式版本。 該值應該是有效的ApiVersion。 一些例子是：0.8.2，0.9.0.0，0.10.0。 通過設置特定的消息格式版本，用戶保證磁盤上的所有現有消息都小於或等於指定的版本。 不正確地設置這個值將導致使用舊版本的用戶出錯，因爲他們將接收到他們不理解的格式的消息。 | string | 1.0-IV0 |
| medium | ||||||
log.message.timestamp.difference.max.ms | broker收到消息時的時間戳和消息中指定的時間戳之間允許的最大差異。如果log.message.timestamp.type = CreateTime，如果時間戳的差值超過此閾值，則會拒絕接受這條消息。如果log.message.timestamp.type = LogAppendTime，則忽略此配置。允許的最大時間戳差異不應大log.retention.ms，以避免不必要地頻繁進行日誌滾動。 | long | 9223372036854775807 |
| medium | ||||||
log.message.timestamp.type | 定義消息中的時間戳是消息創建時間還是日誌追加時間。 該值應該是“CreateTime”或“LogAppendTime” | string | CreateTime | [CreateTime, LogAppendTime] | medium | ||||||
log.preallocate | 是否預創建新的段文件，windows推薦使用 | boolean | false |
| medium | ||||||
log.retention.check.interval.ms | 檢查日誌段文件的間隔時間，以確定是否文件屬性是否到達刪除要求。 | long | 300000 | [1,...] | medium | ||||||
max.connections.per.ip | broker上每個IP允許最大的連接數 | int | 2147483647 | [1,...] | medium | ||||||
max.connections.per.ip.overrides | 每個ip或者hostname默認的連接的最大覆蓋 | string | "" |
| medium | ||||||
num.partitions | 新建Topic時默認的分區數 | int | 1 | [1,...] | medium | ||||||
principal.builder.class | 實現KAFKAPRIN CIPuBurdor接口的類的完全限定名，用於在授權過程中使用KAFKAPRIPIPSIL對象。此配置還支持以前用於SSL的客戶端身份驗證的Debug PrimeBu建器接口。如果沒有定義主生成器，則默認行爲取決於使用的安全協議。對於SSL身份驗證，如果提供了一個主名稱，將是來自客戶端證書的區分名稱；否則，如果不需要客戶端身份驗證，則主體名稱將是匿名的。對於SASL認證，主體將使用SASL.KKBALOS.PrimPal.to.Loal.Grand規則，如果GSSAPI正在使用，以及其他機構的SASL認證ID。對於明文，校長將是匿名的。
| class |
|
| medium | ||||||
producer.purgatory.purge.interval.requests | 生產者請求的清洗間隔（請求次數）
| int | 1000 |
| medium | ||||||
queued.max.request.bytes | 在沒有讀取更多請求之前允許的排隊字節數。
| long | -1 |
| medium | ||||||
replica.fetch.backoff.ms | 發生讀取分區錯誤時的睡眠時間。
| int | 1000 | [0,...] | medium | ||||||
replica.fetch.max.bytes | 試圖爲每個分區獲取的消息字節數。這不是絕對最大值，如果取回的第一個非空分區中的第一個記錄批大於這個值，則記錄批仍將返回以確保可以進行進度。代理所接受的最大記錄批量大小定義了ViaMaseA.Max（Basic CONFIG）ORMAX。
| int | 1048576 | [0,...] | medium | ||||||
replica.fetch.response.max.bytes | 整個取回響應的最大字節數。記錄以批處理方式獲取，如果第一個非空分區中的第一個記錄批大於這個值，則仍將記錄批處理以確保可以進行進度。因此，這不是絕對最大值。代理所接受的最大記錄批量大小定義了ViaMaseA.Max（Basic CONFIG）ORMAX。
| int | 10485760 | [0,...] | medium | ||||||
reserved.broker.max.id | 最大的數字用於broker.id | int | 1000 | [0,...] | medium | ||||||
sasl.enabled.mechanisms | kafka服務器中啓用的SASL機制列表。該列表可以包含任何安全提供者可用的機制。默認情況下只有GSSAPI啓用。
| list | GSSAPI |
| medium | ||||||
sasl.kerberos.kinit.cmd | Kerberos KimIT命令路徑。 | string | /usr/bin/kinit |
| medium | ||||||
sasl.kerberos.min.time.before.relogin | 在刷新嘗試之間登錄線程睡眠時間。 | long | 60000 |
| medium | ||||||
sasl.kerberos.principal.to.local.rules | 從主名到短名稱（通常是操作系統用戶名）映射的規則列表。規則按順序進行評估，並且與主名稱匹配的第一條規則用於將其映射到短名稱。列表中的任何以後的規則將被忽略。默認情況下，窗體{用戶名}/{主機名}域}的主要名稱被映射到{用戶名}。有關格式的更多細節請參閱SeeSurvivAs授權和ACL。請注意，如果KafkaPrincipalBuilder的擴展是由PrimalPal.BuoDr.Car配置提供的，則忽略此配置。
| list | DEFAULT |
| medium | ||||||
sasl.kerberos.service.name | 卡夫卡運行的Kerberos主體名稱。這可以在卡夫卡的JAAS配置文件或卡夫卡的配置文件中定義。 | string |
|
| medium | ||||||
sasl.kerberos.ticket.renew.jitter | 隨機平衡的百分比增加到更新時間。 | double | 0.05 |
| medium | ||||||
sasl.kerberos.ticket.renew.window.factor | 登錄線程將休眠，直到從上次刷新ticket到期，此時將嘗試續訂ticket。 | double | 0.8 |
| medium | ||||||
sasl.mechanism.inter.broker.protocol | 用於代理間通信的SASL機制。默認是GSSAPI。
| string | GSSAPI |
| medium | ||||||
security.inter.broker.protocol | 用於代理之間通信的安全協議。有效值是：明文、SSL、SASLILISTER、SAASLSSL。同時設置此和It.Buff.ListNe.NoD屬性是一個錯誤。
| string | PLAINTEXT |
| medium | ||||||
ssl.cipher.suites | 密碼套件列表。用於TLS或SSL網絡協議協商網絡連接的安全設置的認證，加密，MAC和密鑰交換算法的命名組合。 默認情況下，支持所有可用的密碼套件。 | list |
|
| medium | ||||||
ssl.client.auth | 配置卡夫卡代理以請求客戶端身份驗證。以下設置是常見的：
如果需要設置客戶機身份驗證，則需要SSL.Client。Auth=需要。
SSL。Client。Auth=請求，這意味着客戶端身份驗證是可選的。與請求不同，如果設置了此選項，客戶端可以選擇不提供關於其自身的身份驗證信息。
SSL.Client，Auth=沒有，這意味着不需要客戶端身份驗證。 | string | none | [required, requested, none] | medium | ||||||
ssl.enabled.protocols | 爲SSL連接啓用的協議列表。
| list | TLSv1.2,TLSv1.1,TLSv1 |
| medium | ||||||
ssl.key.password | 密鑰存儲文件中私鑰的密碼。這對於客戶端是可選的。
| password |
|
| medium | ||||||
ssl.keymanager.algorithm | 密鑰管理器工廠用於SSL連接的算法。默認值是密鑰管理器廠算法配置java虛擬機。
| string | SunX509 |
| medium | ||||||
ssl.keystore.location | 密鑰存儲文件的位置。對於客戶端來說，這是可選的，可以用於客戶端的雙向認證。
| string |
|
| medium | ||||||
ssl.keystore.password | 密鑰存儲文件的存儲密碼。這對於客戶端是可選的，只需要配置SSL.KeStk.Lead。
| password |
|
| medium | ||||||
ssl.keystore.type | 密鑰存儲文件的文件格式。這對於客戶端是可選的。
| string | JKS |
| medium | ||||||
ssl.protocol | 用於生成SSLVIEW的SSL協議。默認設置是TLS，這對於大多數情況來說是好的。在最近的JVM中允許的值是TLS、TLV1.1和TLV1.2。SSL、SSLV2和SSLV3可以在較老的JVM中得到支持，但是由於已知的安全漏洞而阻礙了它們的使用。
| string | TLS |
| medium | ||||||
ssl.provider | 用於SSL連接的安全提供程序的名稱。默認值是JVM的默認安全性提供程序。
| string |
|
| medium | ||||||
ssl.trustmanager.algorithm | 信任管理器工廠用於SSL連接的算法。默認值爲信託經理廠算法配置java虛擬機。
| string | PKIX |
| medium | ||||||
ssl.truststore.location | 信任存儲文件的位置。
| string |
|
| medium | ||||||
ssl.truststore.password | 信任存儲文件的密碼。如果未設置密碼，仍然可以訪問信任存儲區，但禁用完整性檢查。
| password |
|
| medium | ||||||
ssl.truststore.type | 信任存儲文件的文件格式。 | string | JKS |
| medium | ||||||
alter.config.policy.class.name | ALTER配置應該用於驗證的策略類。該類應該實現Or.ApAC.KAFKA.Serv.Price。 | class |
|
| low | ||||||
authorizer.class.name | 應用於授權的授權程序類 | string | "" |
| low | ||||||
create.topic.policy.class.name | 應該用於驗證的CREATE主題策略類。該類應該實現Or.ApAC.KAFKA.Serv.Cuff.CealTePopIcRead接口。 | class |
|
| low | ||||||
listener.security.protocol.map | 在偵聽器名稱和安全協議之間映射。對於相同的安全協議，必須在多個端口或IP中定義這一點。例如，即使兩者都需要SSL，也可以分離內部和外部業務。具體來說，用戶可以定義具有內部和外部名稱的偵聽器，並且該屬性爲：“內部：SSL，外部：SSL”。如圖所示，鍵和值由冒號分隔，MAP條目用逗號分隔。每個偵聽器名稱只在地圖中出現一次。可以爲每個偵聽器配置不同的安全性（SSL和SASL）設置，通過向CONFIG名稱添加標準化前綴（偵聽器名稱爲LeLeCaseDead）。例如，爲內部偵聽器設置一個不同的密鑰存儲庫，將設置一個名爲‘偵聽器.Name .No.SSL.KyStury.Load’的配置。如果沒有設置偵聽器名稱的配置，則配置將回落到通用配置（即‘SSL.KiStk.Load’）。
| string | PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL |
| low | ||||||
metric.reporters | 作爲度量指標的類的列表。實現Or.ApHEC.KAFK.AUM.MUCICIC.MeMICCsHealthExchange接口允許插入將被通知新度量創建的類。JMXNeRead總是包含註冊JMX統計信息。
| list | "" |
| low | ||||||
metrics.num.samples | 保留計算metrics的樣本數（譯者不清楚是做什麼的） | int | 2 | [1,...] | low | ||||||
metrics.recording.level | 度量的最高記錄級別。 | string | INFO |
| low | ||||||
metrics.sample.window.ms | The window 計算度量樣本。 | long | 30000 | [1,...] | low | ||||||
quota.window.num | 在客戶機內存中保留的樣本數量
| int | 11 | [1,...] | low | ||||||
quota.window.size.seconds | 客戶配額的每個樣本的時間跨度
| int | 1 | [1,...] | low | ||||||
replication.quota.window.num | 在內存中保留用於複製配額的樣本數量 | int | 11 | [1,...] | low | ||||||
replication.quota.window.size.seconds | 複製配額的每個樣本的時間跨度
| int | 1 | [1,...] | low | ||||||
ssl.endpoint.identification.algorithm | 使用服務器證書驗證服務器主機名的端點識別算法。
| string |
|
| low | ||||||
ssl.secure.random.implementation | 用於SSL加密操作的SoCurrANDOM PRNG實現。
| string |
|
| low | ||||||
transaction.abort.timed.out.transaction.cleanup.interval.ms | 回滾已超時事務的間隔。
| int | 60000 | [1,...] | low | ||||||
transaction.remove.expired.transaction.cleanup.interval.ms | 在該區間刪除已過期的totransactional.id.expiration.mspassing交易由於 | int | 3600000 | [1,...] | low | ||||||
zookeeper.sync.time.ms | zookeeper的follower同leader的同步時間 | int | 2000 |
| low | ||||||