文章目录
1.硬件配置选择
1.场景说明
100万日活，每人每天100条日志，每天总共的日志条数是100万100条=1亿条。
1亿/24小时/60分/60秒=1150条/每秒钟。每条日志大小：0.5k-2k（取1k）。
1150条/每秒钟 1k≈1m/s。
高峰期每秒钟：1150条*20倍=23000条。每秒多少数据量：20MB/s。
2.服务器台数选择
服务器台数=2 （生产者峰值生产速率副本/ 100）+ 1
= 2 *（20m/s * 2/100）+ 1
= 3台建议3台服务器。
3.磁盘选择
kafka底层主要是顺序写，固态硬盘和机械硬盘的顺序写速度差不多。建议选择普通的机械硬盘。
每天总数据量：1亿条* 1k≈100g
100g副本2保存时间3天/ 0.7≈1T建议三台服务器硬盘总大小，大于等于1T。
4.内存选择
kafka 内存组成：堆内存+页缓存
1) 堆内存配置
kafka 堆内存建议每个节点：10g~15g
修改kafka-server-start.sh
默认配置
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"
fi
建议修改为：
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
export KAFKA_HEAP_OPTS="-Xmx10G-Xms10G"
fi
2）页缓存配置
页缓存：页缓存是Linux系统服务器的内存。我们只需要保证1个segment（1g）中25%的数据在内存中就好。
每个节点页缓存大小=（分区数1g 25%）/节点数。例如10个分区，页缓存大小=（101g25%）/3≈1g
建议服务器内存大于等于11G (堆内存10g+页缓存1g)
5. cpu选择
num.io.threads=8负责写磁盘的线程数，整个参数值要占总核数的50%。
num.replica.fetchers=1副本拉取线程数，这个参数占总核数的50%的1/3。
num.network.threads=3数据传输线程数，这个参数占总核数的50%的2/3。
建议32个cpu core。
6.网络选择
网络带宽=峰值吞吐量≈20MB/s选择千兆网卡即可。100Mbps单位是bit；10M/s单位是byte;1byte=8bit，100Mbps/8=12.5M/s。一般百兆的网卡（100Mbps）、千兆的网卡（1000Mbps）、万兆的网卡（10000Mbps）。
2.生产者
batch.size：只有数据积累到batch.size之后，sender才会发送数据。默认16k•linger.ms：如果数据迟迟未达到batch.size，sender等待linger.ms设置的时间到了之后就会发送数据。单位ms，默认值是0ms，表示没有延迟。
•0：生产者发送过来的数据，不需要等数据落盘应答。
•1：生产者发送过来的数据，Leader收到数据后应答。
•-1（all）：生产者发送过来的数据，Leader和ISR队列里面的所有节点收齐数据后应答。-1和all等价。
| 参数名称 | 描述 |
|---|---|
| bootstrap.servers | 生产者连接集群所需的broker地址清单。例如hadoop102:9092,hadoop103:9092,hadoop104:9092，可以设置1个或者多个，中间用逗号隔开。注意这里并非需要所有的broker地址，因为生产者从给定的broker里查找到其他broker信息。 |
| key.serializer和value.serializer | 指定发送消息的key和value的序列化类型。一定要写全类名。 |
| buffer.memory | RecordAccumulator缓冲区总大小，默认32m。 |
| batch.size | 缓冲区一批数据最大值，默认16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。 |
| linger.ms | 如果数据迟迟未达到batch.size，sender等待linger.time之后就会发送数据。单位ms，默认值是0ms，表示没有延迟。生产环境建议该值大小为5-100ms之间。 |
| acks | 0：生产者发送过来的数据，不需要等数据落盘应答。1：生产者发送过来的数据，Leader收到数据后应答。-1（all）：生产者发送过来的数据，Leader+和isr队列里面的所有节点收齐数据后应答。默认值是-1，-1和all是等价的。 |
| max.in.flight.requests.per.connection | 允许最多没有返回ack的次数，默认为5，开启幂等性要保证该值是1-5的数字。 |
| retries | 当消息发送出现错误的时候，系统会重发消息。retries表示重试次数。默认是int最大值，2147483647。如果设置了重试，还想保证消息的有序性，需要设置MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1否则在重试此失败消息的时候，其他的消息可能发送成功了。 |
| retry.backoff.ms | 两次重试之间的时间间隔，默认是100ms。 |
| enable.idempotence | 是否开启幂等性，默认true，开启幂等性。 |
| compression.type | 生产者发送的所有数据的压缩方式。默认是none，也就是不压缩。支持压缩类型：none、gzip、snappy、lz4和zstd。 |
3.kafka broker
| 参数名称 | 描述 |
|---|---|
| replica.lag.time.max.ms | ISR中，如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值，默认30s。 |
| auto.leader.rebalance.enable | 默认是true。自动LeaderPartition平衡。建议关闭。 |
| leader.imbalance.per.broker.percentage | 默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。 |
| leader.imbalance.check.interval.seconds | 默认值300秒。检查leader负载是否平衡的间隔时间。 |
| log.segment.bytes | Kafka中log日志是分成一块块存储的，此配置是指log日志划分成块的大小，默认值1G。 |
| log.index.interval.bytes | 默认4kb，kafka里面每当写入了4kb大小的日志（.log），然后就往index文件里面记录一个索引。 |
| log.retention.hours | Kafka中数据保存的时间，默认7天。 |
| log.retention.minutes | Kafka中数据保存的时间，分钟级别，默认关闭。 |
| log.retention.ms | Kafka中数据保存的时间，毫秒级别，默认关闭。 |
| log.retention.check.interval.ms | 检查数据是否保存超时的间隔，默认是5分钟。 |
| log.retention.bytes | 默认等于-1，表示无穷大。超过设置的所有日志总大小，删除最早的segment。 |
| log.cleanup.policy | 默认是delete，表示所有数据启用删除策略；如果设置值为compact，表示所有数据启用压缩策略。 |
| num.io.threads | 默认是8。负责写磁盘的线程数。整个参数值要占总核数的50%。 |
| num.replica.fetchers | 默认是1。副本拉取线程数，这个参数占总核数的50%的1/3 |
| num.network.threads | 默认是3。数据传输线程数，这个参数占总核数的50%的2/3。 |
| log.flush.interval.messages | 强制页缓存刷写到磁盘的条数，默认是long的最大值，9223372036854775807。一般不建议修改，交给系统自己管理。 |
| log.flush.interval.ms | 每隔多久，刷数据到磁盘，默认是null。一般不建议修改，交给系统自己管理。 |
4. 服役新节点，退役旧节点
创建three主题，4个分区，2个副本
[root@node2 kafka_2.12-3.0.0]# bin/kafka-topics.sh --bootstrap-server node1:9092 --create --topic three --partitions 4 --replication-factor 2
Created topic three.
查看下分区和副本情况
[root@node2 kafka_2.12-3.0.0]# bin/kafka-topics.sh --bootstrap-server node1:9092 --describe --topic three
Topic: three TopicId: 7GQ8d0fRRK2xULnj3pbhjg PartitionCount: 4 ReplicationFactor: 2 Configs: segment.bytes=1073741824
Topic: three Partition: 0 Leader: 2 Replicas: 2,1 Isr: 2,1
Topic: three Partition: 1 Leader: 1 Replicas: 1,0 Isr: 1,0
Topic: three Partition: 2 Leader: 0 Replicas: 0,2 Isr: 0,2
Topic: three Partition: 3 Leader: 2 Replicas: 2,0 Isr: 2,0
现在我们想把three主题的所有副本存储在0 和1 节点上
vim increase-replication-factor.json
{
"version":1,
"partitions":[
{
"topic":"three","partition":0,"replicas":[0,1]
},
{
"topic":"three","partition":1,"replicas":[0,1]
},
{
"topic":"three","partition":2,"replicas":[0,1]
},
{
"topic":"three","partition":3,"replicas":[0,1]
}
]
}
[root@node2 kafka_2.12-3.0.0]# bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file increase-replication-factor.json --execute
Current partition replica assignment
{"version":1,"partitions":[{"topic":"three","partition":0,"replicas":[2,1],"log_dirs":["any","any"]},{"topic":"three","partition":1,"replicas":[1,0],"log_dirs":["any","any"]},{"topic":"three","partition":2,"replicas":[0,2],"log_dirs":["any","any"]},{"topic":"three","partition":3,"replicas":[2,0],"log_dirs":["any","any"]}]}
Save this to use as the --reassignment-json-file option during rollback
Successfully started partition reassignments for three-0,three-1,three-2,three-3
[root@node2 kafka_2.12-3.0.0]#
验证副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file increase-replication-factor.json --verify
查下该topic 信息
[root@node2 kafka_2.12-3.0.0]# bin/kafka-topics.sh --bootstrap-server node1:9092 --topic three --describe
Topic: three TopicId: 7GQ8d0fRRK2xULnj3pbhjg PartitionCount: 4 ReplicationFactor: 2 Configs: segment.bytes=1073741824
Topic: three Partition: 0 Leader: 0 Replicas: 0,1 Isr: 1,0
Topic: three Partition: 1 Leader: 1 Replicas: 0,1 Isr: 1,0
Topic: three Partition: 2 Leader: 0 Replicas: 0,1 Isr: 0,1
Topic: three Partition: 3 Leader: 0 Replicas: 0,1 Isr: 0,1
1）创建一个要均衡的主题。
vimtopics-to-move.json
{
"topics":[
{"topic":"first"}
],
"version":1
}
2) 生成一个负载均衡的计划
[root@node2 kafka_2.12-3.0.0]# bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate
Current partition replica assignment
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[1,0,2],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[2,1,0],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[0,2,1],"log_dirs":["any","any","any"]}]}
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[1,2,0],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[2,0,1],"log_dirs":["any","any","any"]}]}
[root@node2 kafka_2.12-3.0.0]#
执行副本存储计划
vim increase-replication-factor-first.json
{“version”:1,“partitions”:[{“topic”:“first”,“partition”:0,“replicas”:[1,0,2],“log_dirs”:[“any”,“any”,“any”]},{“topic”:“first”,“partition”:1,“replicas”:[2,1,0],“log_dirs”:[“any”,“any”,“any”]},{“topic”:“first”,“partition”:2,“replicas”:[0,2,1],“log_dirs”:[“any”,“any”,“any”]}]}
[root@node2 kafka_2.12-3.0.0]# bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file increase-replication-factor-first.json --execute
验证副本存储计划
[root@node2 kafka_2.12-3.0.0]# bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file increase-replication-factor-first.json --verify
Status of partition reassignment:
Reassignment of partition first-0 is complete.
Reassignment of partition first-1 is complete.
Reassignment of partition first-2 is complete.
Clearing broker-level throttles on brokers 0,1,2
Clearing topic-level throttles on topic first
leader分布不均匀解决办法
减少分区(会报错)，增加分区
[2023-01-29 16:55:40,828] ERROR org.apache.kafka.common.errors.InvalidPartitionsException: Topic currently has 3 partitions, which is higher than the requested 2.
(kafka.admin.TopicCommand$)
[root@node2 kafka_2.12-3.0.0]# bin/kafka-topics.sh --bootstrap-server node1:9092 --alter --topic first --partitions 4
[root@node2 kafka_2.12-3.0.0]# bin/kafka-topics.sh --bootstrap-server node1:9092 --topic first --describe
Topic: first TopicId: IcU6kbglSSWOkruuSmgryg PartitionCount: 4 ReplicationFactor: 3 Configs: segment.bytes=1073741824
Topic: first Partition: 0 Leader: 2 Replicas: 1,0,2 Isr: 2,1,0---
Topic: first Partition: 1 Leader: 2 Replicas: 2,1,0 Isr: 2,0,1
Topic: first Partition: 2 Leader: 2 Replicas: 0,2,1 Isr: 2,0,1
Topic: first Partition: 3 Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
发现leader都是2，将node1，node2，node3上的kafka停止后，重启
如果leader集中的部分机器上，那么该机器的请求压力，吞吐压力就很大，而其他机器的请求量很少，分布不均匀，容易导致数据堆积
vim test.json
{
“partitions”:[
{
“partition”:0,
“topic”:“first”
},
{
“partition”:1,
“topic”:“first”
},
{
“partition”:2,
“topic”:“first”
}
]
}
[root@node2 kafka_2.12-3.0.0]# bin/kafka-leader-election.sh --path-to-json-file test.json --bootstrap-server node1:9092 --election-type PREFERRED
[root@node2 kafka_2.12-3.0.0]# bin/kafka-topics.sh --bootstrap-server node1:9092 --topic first --describe
Topic: first TopicId: IcU6kbglSSWOkruuSmgryg PartitionCount: 4 ReplicationFactor: 3 Configs: segment.bytes=1073741824
Topic: first Partition: 0 Leader: 2 Replicas: 2,0,1 Isr: 2,1,0
Topic: first Partition: 1 Leader: 0 Replicas: 0,1,2 Isr: 2,1,0
Topic: first Partition: 2 Leader: 1 Replicas: 1,2,0 Isr: 2,1,0
Topic: first Partition: 3 Leader: 2 Replicas: 2,1,0 Isr: 2,1,0
直接kafka-leader-election.sh可以把所有topic的所有分区都执行一遍重新平衡，如果集群中需要重平衡的副本较多，则会对客户端带来一定的影响，所以一般生产环境中在使用的时候，会加参数path-to-json-file来指定一个json文件，以对部分分区进行leader重平衡。
例如我们只对topic video_features的分区12、13进行优先副本选举，需要编写一个json文件test1.json：
{
“partitions”:[
{
“partition”:12,
“topic”:“video_features”
},
{
“partition”:13,
“topic”:“video_features”
}
]
}
参考文档：https://blog.csdn.net/worldchinalee/article/details/108213917
kafka集群重启后，leader容易分布不均匀，这个如何一劳永逸的解决呢？不能每次重启以后，重重新分布leader吧？？？？？
生产环境需要关闭的属性
auto.leader.rebalance.enable：ture/false------是否允许定期进行 Leader 选举
若开启，默认300s即5分钟扫描一次，每次若发现每个broker之间的leader对比 比率超过10%，则重新发起选举。不建议开启虽然在一定条件下，才会触发leader选举，但是如果把auto.leader.rebaleance.enable设置为true，可能一段时间后leaderA就被强行换成Leader B了
leader更换代价很高的，原本向A发送的请求的所有客户端都要切换到向B发送请求，而且这种更换leader本质上没有任何性能收益，
但是如果关闭，leader一旦宕机，就没有leader了
unclean.leader.election.enable，版本不一样默认值也不一样，建议设置为false
注：虽然设置为false会可能导致该partition不可用，但是设置为ture会有丢数据的风险。