カフカの引数は、詳細な
各カフカブローカー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
システムパラメータ
＃ユニーク要件は正の数であり、クラスタIDを識別する。
= 0 broker.id
＃サービスポート、デフォルトの9092
ポート= 9092の
＃はアドレスを聞く
host.name = debugo01
＃処理ネットワークは、スレッドの最大数の要求
= 2 num.network.threads
スレッドの＃処理ディスクI / O数
num.io.threadsを8 =
バックグラウンドの＃番号スレッド
background.threadsの=を4
IO処理要求キュー最大待っ＃スレッド数
queued.max.requests = 500
＃ソケット送信バッファ（SO_SNDBUF）は
1048576 = socket.send.buffer.bytes
＃ソケット（SO_RCVBUF）受信バッファ
socket.receive.buffer.bytes = 1048576
要求されたバイトの＃ソケット最大数。メモリのオーバーフローを防ぐために、message.max.bytesは未満にバインド
socket.request.max.bytes = 104857600
トピックパラメータ
＃各トピックのためのパーティションの数は、より多くのパーティションが生成されます。より多くのファイルセグメント
num.partitions = 2
、あなたは話題のコマンドを作成する必要がfalseの場合＃は、自動的にトピックを作成するために許可されている
auto.create.topics.enableを=真
＃トピックは、デフォルトのパーティションの複製の数は、ブローカクラスタの数よりも大きくすることはできません。
default.replication.factor = 1つの
バイトのメッセージ本体の最大サイズ位、
message.max.bytes = 1000000
ZooKeeperのパラメータ
＃飼育係の定足数の設定。コンマが複数存在する場合に分離
2181、debugo02、debugo03：zookeeper.connect = debugo01
＃ZK接続タイムアウト
zookeeper.connection.timeout.ms = 1000000
実際のクラスタ＃ZooKeeperのリーダーとフォロワーの間の同期
zookeeper.sync.timeを.MS = 2000
パラメータをログに記録
＃ログ格納ディレクトリ、コンマで区切って複数のディレクトリ
log.dirs =は/ var / log /カフカ
＃クリーンアップ作戦（削除|コンパクト）のログ
の削除= log.cleanup.policy
＃は時間（時間|分）をログ保存、デフォルトは7日（168時間）です。この時間以上は、ポリシーデータに基づいて処理されます。バイトと分が最初に到達した方がトリガされます。
= 168 log.retention.hours
バイトの最大数に格納された＃ログデータ。この時間以上は、ポリシーデータに基づいて処理されます。
＃log.retention.bytes = 1073741824
＃ログファイルの制御セグメントのサイズ、新しいログファイルのセグメントを超えて付加された大きさ（-1制限を意味しない）
log.segment.bytes = 536870912
＃時間は以下に達したとき、新しいセグメント強制する
log.rollを。時間= 24 * 7
検査サイクル＃ログファイルの断片彼らは削除ポリシー（log.retention.hoursまたはlog.retention.bytes）のセットに達したかどうかを確認するために
log.retention.check.interval.ms = 60000
＃圧縮開くかどうかを
log.cleaner.enable = falseを
圧縮ログに予約最長時間のために＃
log.cleaner.delete.retention.ms = 1日
インデックスファイル＃ログセグメントのサイズ制限のために
log.index.size.max.bytes =×1024×1024 10
バッファ指標算出#Yは、一般的に設ける必要はありません。
log.index.interval.bytes = 4096
パラメータのコピー
自動的ブローカとの間の割り当てポリシーバランスさせるかどうか＃
auto.leader.rebalance.enable =偽
アンバランス比＃リーダーを、この値以上ならば、パーティションが再バランスになり
leader.imbalance.per.broker.percentage = 10
＃リーダーの不均衡間隔かどうかを確認
leader.imbalance.check.interval.seconds = 300台の
＃クライアントの最大オフセット情報空間を保持する
offset.metadata.max.bytes = 1024
消費者パラメータ
コア構成の＃消費者側がgroup.idで、zookeeper.connect
＃は消費者の家庭のためにユニークなグループIDを決定し、プロセスを設定することで、同じことがすべてそれらが同じのコンシューマ・グループですグループIDの複数のパートことを示します。
group.idの
＃の消費者IDは、設定されていない場合、インクリメントする
consumer.id
好ましくは同じgroup.idと、追跡IDのため位
client.id = <GROUP_ID>
＃ソケットタイムアウト、実際のタイムアウト期間はsocket.timeout.ms + max.fetch.waitある。
= 30 * 1000 Socket.timeout.msは
＃ソケットバッファスペースサイズ受信
= 64 * 1024 socket.receive.buffer.bytesを
メッセージ＃は制限から、各パーティションのサイズは、フェッチ
fetch.message.max.bytes = 1024 * 1024
オフセット後の消費者のニュースを飼育係する場合は＃真、消費者の同期、消費者が失敗したなどとして、新たな消費者は飼育係のからのオフセット最新入手することができるようになります
trueに= auto.commit.enableを
時間間隔に自動的に提出＃1
auto.commit。 = 60×1000 interval.ms
＃消費バッファサイズブロックに対するメッセージの最大数は、各ブロックは、値fetch.message.max.bytesと同等であってもよい
queued.max.message.chunks = 10
新しい消費者がグループに追加され、新たな消費者に移行するreblance、消費者側パーティションを試みる場合＃、試行回数が提供される
rebalance.max.retriesを4 =
＃reblance各間隔
rebalance.backoff 2000 = .MS
それぞれの時間の＃再選出されたリーダー
refresh.leader.backoff.ms
それは指定されたサイズを満たすまで、この値が待機する満たしていない場合は＃サーバーは、最小消費者側にデータを送信します。デフォルトは1すぐに受信を表しています。
=。1 fetch.min.bytes
＃もし満たさないときfetch.min.bytes、最終消費者が時間待ちの最大の要求を待っ
= 100 fetch.wait.max.msを
全く新しいメッセージがスローするように、指定した時間内に消費するために使用することができない場合には＃異常のデフォルトは-1は無制限であることを示し
= consumer.timeout.msを-1
生産パラメータ
消費者はメッセージのメタ情報（トピック、パーティションとレプリカ）を取得＃アドレス、設定形式は次のとおりです。HOST1：ポート1、ホスト2：ポート2には 、 また外にVIPを設定することができます
metadata.broker.list
メッセージの確認応答モード＃1
＃0：確認がちょうど送信され、メッセージの到着が保証されていませんが、低レイテンシメッセージの損失はビットTCPのように、サーバーに障害が発生した場合には、表示されます
。＃1：メッセージを送信し、リーダーの近くを待ちます確認後、いくつかの信頼
＃-1：メッセージを送信した後、確認応答リーダーの受信を待ち、コピー操作は、のみ返すように、最大の信頼性
request.required.acks = 0
非同期モード＃での最大時間バッファデータ。例えば、100に設定さが100ミリ秒に設定されたメッセージを送信した後、これはスループットを増加させるが、遅延メッセージ送信増加する
queue.buffering.max.ms = 5000
バッファ＃非同期モードでのメッセージの最大数は、上記の
キュー。 = 10000 buffering.max.messages
＃非同期モード、待ち時間はメッセージキューを入力します。0に設定すると、何のメッセージがキューに入らない場合は、直接廃棄され、待機していない
= queue.enqueue.timeout.ms -1
＃非同期モードで、メッセージの数は、ときqueue.buffering.max.messagesたびに送信、またはqueue.buffering.max.ms生産が送られたときの条件のいずれかがトリガされます満たしています。
batch.num.messages = 200
以下のリスト（説明用）Server.propertiesすべての構成パラメータ：
| パラメータ |
説明（説明） |
| broker.id = 0 |
一意クラスタに表される各ブローカーは、要件は、正の数です。サーバーのIPアドレスが変更された場合、変更されませんbroker.idは、状況はニュースの消費者に影響を与えません。 |
| log.dirs = /データ/カフカ、ログ |
カフカ格納アドレスデータ、カンマで区切られたアドレス複数の単語/データ/カフカ-ログ-1、/データ/カフカ-ログ-2 |
| ポート= 9092 |
ブローカーサーバーのサービスポート |
| message.max.bytes = 6525000 |
これは、バイト単位で、メッセージ本文の最大サイズを表します |
| num.network.threads = 4 |
メッセージを処理するスレッドブローカーの最大数は、一般的に変更する必要はありません |
| num.io.threads = 8 |
スレッドブローカーのディスクIO処理の数は、値がハードドライブの数よりも大きくなければなりません |
| background.threads = 4 |
いくつかのバックグラウンドタスク処理スレッドは、例えば、あなたが変更する必要はありません通常の状況下では、古くなったメッセージファイルを削除します |
| queued.max.requests = 500 |
要求がIOを待っている場合は、要求のキュー最大数を待っているIOスレッドがこの値を超えると、それは外部メッセージの受け入れを停止します、それは自己保護メカニズムである必要があります。 |
| host.name |
ブローカーのホストアドレスを設定した場合、それはすべてのインターフェースにバインドされますされていない場合、それは、このアドレスにバインドします、と一般的に設定しないでください、ZKにそれらのいずれかを送信します |
| socket.send.buffer.bytes = 100 * 1024 |
ソケットの送信バッファ、ソケットのチューニングパラメータSO_SNDBUFF |
| socket.receive.buffer.bytes = 100 * 1024 |
ソケットは、バッファ、ソケットのチューニングパラメータを受け取るSO_RCVBUFF |
| socket.request.max.bytes = 100 * 1024 * 1024 |
指定されたパラメータのserverOOMを防止するためのカバーは、socket.request.max.bytes未満にバインドmessage.max.bytesは、トピックを作成されるソケット要求された最大値、 |
| log.segment.bytes * 1024 = 1024×1024 |
セグメントに格納されているファイルの束に基づいて、トピック・パーティションは、指定されたパラメータをカバーする各セグメントのサイズの制御が作成されるときにトピック |
| log.roll.hours = 24 * 7 |
このパラメータは、トピックを作成される新しいセグメントを作成することを余儀なくされ、時間指定されたパラメータをカバーし、ログ・セグメントに設定されたlog.segment.bytesの大きさに達していません |
| log.cleanup.policy =削除 |
トピックがカバーされたときに、データ処理のために主に有効期限が切れたとコンパクト削除、または作成されたファイルは、指定されたパラメータの量に限界に達したログ：クリーンアップ戦略を選択したログ |
| log.retention.minutes = 3日 |
最大データ蓄積時間がこの時間はどのくらい消費データに消費者側ができ、つまり、ポリシープロセスデータlog.cleanup.policyに応じて設定される超え log.retention.bytesといずれかのパラメータを指定して、削除を実行し、要件を満たすためにlog.retention.minutesはトピックがカバーされたときに作成されます |
| log.retention.bytes = -1 |
トピックの各パーティションの最大ファイルサイズ、話題のサイズ制限=パーティション* log.retention.bytesの数。-1はサイズ制限log.retention.bytesと要件を満たすためにいずれかをlog.retention.minutesは、削除を実行しませんトピックを作成するときに、指定したパラメータによってカバーされます |
| log.retention.check.interval.ms = 5分 |
罰がポリシーで設定したかどうか、サイクルタイムのファイルサイズを確認してくださいlog.cleanup.policy |
| = log.cleaner.enable 偽 |
ログの圧縮がオンになっています |
| log.cleaner.threads = 2 |
ログ圧縮を実行しているスレッドの数 |
| log.cleaner.io.max.bytes.per.second =なし |
最大サイズを扱うログの圧縮 |
| 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之间的同步实际那 |
kafka命令和参数
1.查看topic的详细信息 ./kafka-topics.sh -zookeeper 127.0.0.1:2181 -describe -topic testKJ1 2、为topic增加副本 ./kafka-reassign-partitions.sh -zookeeper 127.0.0.1:2181 -reassignment-json-file json/partitions-to-move.json -execute 3、创建topic ./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic testKJ1 4、为topic增加partition ./bin/kafka-topics.sh –zookeeper 127.0.0.1:2181 –alter –partitions 20 –topic testKJ1 5、kafka生产者客户端命令 ./kafka-console-producer.sh --broker-list localhost:9092 --topic testKJ1 6、kafka消费者客户端命令 ./kafka-console-consumer.sh -zookeeper localhost:2181 --from-beginning --topic testKJ1 7、kafka服务启动 ./kafka-server-start.sh -daemon ../config/server.properties 8、下线broker ./kafka-run-class.sh kafka.admin.ShutdownBroker --zookeeper 127.0.0.1:2181 --broker #brokerId# --num.retries 3 --retry.interval.ms 60 shutdown broker 9、删除topic ./kafka-run-class.sh kafka.admin.DeleteTopicCommand --topic testKJ1 --zookeeper 127.0.0.1:2181 ./kafka-topics.sh --zookeeper localhost:2181 --delete --topic testKJ1 10、查看consumer组内消费的offset ./kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper localhost:2181 --group test --topic testKJ1
1，删除操作：
$bin/kafka-topics.sh --zookeeper hadoop108:2181 --delete --topic first
默认是标记删除，如果要真的删除，需要设置：delete.topic.enable=true
2，创建一个主题，该主题有三个分区，有两个副本
$bin/kafka-topics.sh --zookeeper hadoop108:2181 --create --topic first --partitions 3 --replication-factor 2
3，查看当前有多少主题：
$ bin/kafka-topics.sh --zookeeper hadoop108:2181 --list
first
因为主题相关的信息都存储在zookeeper中，所以我们需要连接到zookeeper集群，获取到主题相关的数据
4，查看某个topic的详情：
$ bin/kafka-topics.sh --zookeeper hadoop108:2181 --describe --topic first Topic:first PartitionCount:3 ReplicationFactor:2 Configs: Topic: first Partition: 0 Leader: 9 Replicas: 9,10 Isr: 9,10 Topic: first Partition: 1 Leader: 10 Replicas: 10,8 Isr: 10,8 Topic: first Partition: 2 Leader: 8 Replicas: 8,9 Isr: 8,9
这里，主题是名称是first，分区0，的leader在9上，副本在9 和10 上，分区1的leader在10上，副本在8和10 上；分区2的leader在8上，副本在8,9 上；ISR：in sync replication，正在同步的副本；
如此此时我们kill掉10；
bin/kafka-topics.sh --zookeeper hadoop108:2181 --describe --topic first Topic:first PartitionCount:3 ReplicationFactor:2 Configs: Topic: first Partition: 0 Leader: 9 Replicas: 9,10 Isr: 9 Topic: first Partition: 1 Leader: 8 Replicas: 10,8 Isr: 8 Topic: first Partition: 2 Leader: 8 Replicas: 8,9 Isr: 8,9
此时，分区1的leader变为8等待一会时间之后，分区会自平衡，所谓的自平衡就是leader均匀的分布，在本题中就是partition2的leader会重新恢复为10
5，生产数据：数据的生产和zookeeper没有关系
$ bin/kafka-console-producer.sh --broker-list hadoop108:9092 --topic first >hello >kafka
生产数据的时候需要获得消息队列集群的broker，这样才能知道生产完毕的数据放在哪里，所以需要指定kafka消息队列的集群在集群通信的端口号。c除此之外，还需要指定该数据是在哪个分区的。
6，数据的消费，需要连接到zookeeper，这样才能获取上次消费的offset，从而决定从哪里消费，还要指定消费的主题
[isea@hadoop108 kafka]$ bin/kafka-console-consumer.sh --zookeeper hadoop108:2181 --from-beginning -topic first
hello
kafka
在生产者中生产数据之后，在消费者端能够接收到数据
我们在查看一下数据：
[isea@hadoop108 kafka]$ bin/kafka-topics.sh --zookeeper hadoop108:2181 --describe --topic first Topic:first PartitionCount:3 ReplicationFactor:2 Configs: Topic: first Partition: 0 Leader: 9 Replicas: 9,10 Isr: 9,10 Topic: first Partition: 1 Leader: 10 Replicas: 10,8 Isr: 8,10 Topic: first Partition: 2 Leader: 8 Replicas: 8,9 Isr: 8,9
当前的机器是8，分区2的数据，保存了两份，在8 9 两台机器上，leader在8，所以我们查看一下logs下的first2，下面是有数据的，为kafka；
[isea@hadoop108 first-2]$ strings 00000000000000000000.log
kafka
对于分区0 ，在9 10 机器上有数据信息，leader在9上，所以查看一下logs下面的first0，有数据为hello
hello[isea@hadoop109 first-0]$ strings 00000000000000000000.log
hello
分析：我们产生的消息是 hello 和 kafka，这是一份完整的数据被标记为first主题，该first主题有三个分区，被标记为first主题的每一粒数据，进入消息队列的时候将会被存储到这三个分区中的一个，这里hello被存储到了分区0，分区0在9号机器上，同时分区0还有一个备份在10号机器上；而kafka被存储到了分区1，在10号机器上，同时分区1在8号机器上还有一个备份
在kafka0.9及其之后，kafka消费者做了相应的变化，将原本放在zookeeper中的offset数据放在了kafka的集群本地，于是我们还可以使用下面的客户端命令来进行消费：
[isea@hadoop101 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop101:9092 --topic first
hello
kafka
此时我们在查看一下log日志的：
[isea@hadoop101 logs]$ tree . ├── cleaner-offset-checkpoint ├── __consumer_offsets-0 │ ├── 00000000000000000000.index │ ├── 00000000000000000000.log │ ├── 00000000000000000000.timeindex │ └── leader-epoch-checkpoint
发现offset的信息存储在了log中，而且偏移量的信息保存在了集群中，也即所有的机器中，但是整个集群合起来是所有的偏移量的信息。
参考：
https://www.jianshu.com/p/49f23183a6a3
https://www.jb51.net/article/99923.htm