kafka 设计概要
吞吐量/延时
消息持久化
负载均衡和故障转移
伸缩性
一些常用命令
通过GetOffsetShell 工具类查看 topic 分区消息
./kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.2.52:9092 --topic test
查看当前topic 当前对应的信息
./kafka-topics.sh --zookeeper 192.168.2.52:2181 --describe --topic test1
Topic: test1 Partition: 0 Leader: 0 Replicas: 0 Isr: 0
Topic: test1 Partition: 1 Leader: 0 Replicas: 0 Isr: 0
修改kafka分区个数
./kafka-topics.sh -alter --zookeeper 192.168.2.52:2181 --partitions 2 --topic test
给现有topic 添加新的配置 添加压实配置
./kafka-configs.sh --zookeeper 192.168.2.52:2181 --alter --entity-type topics --entity-name test --add-config cleanup.policy=compact
查看当前topic 的配置
./kafka-configs.sh --zookeeper 192.168.2.52:2181 --describe --entity-type topics --entity-name test
对topic 进行生产者消息测试
./kafka-producer-perf-test.sh --topic topic1 --throughput -1 --num-records 50000 --record-size 100 --producer-props bootstrap.servers=192.168.2.52:9092 acks=1
查看当前存在的消费者组
./kafka-consumer-groups.sh --bootstrap-server 192.168.2.52:9092 --list
查看当前消费者组的信息
./kafka-consumer-groups.sh --bootstrap-server 192.168.2.52:9092 --describe --group topic1group
重置当前消费者组的offset
./kafka-consumer-groups.sh --bootstrap-server 192.168.2.52:9092 --group topic1group --reset-off sets --all-topics --to-earliest --execute
kafka rebalance 触发条件
消费者新增或者 移除
topic 分区的新增或减少
Kafka多线程消费两种方式
1 每个线程维护一个kafkaConsumer
2 单个kafkaConsumer 实例 一个线程对应一个分区
两种方式的优缺点
方法1 (每个线程维护专属 Ka fkaConsumer )
实现简单；速度较快，因为无线程 间交互开销：方便位移管理；易于 维护分区间的消息消费顺序
Socket连接开销大；consumer数受限于topic分区 数，扩展性差；broker端处理负载高（因为发往 broker的请求数多）；rebalance可能性增大
方法2 (全局consumer多 worker 线程）
消息获取与处理解耦：可独立扩展 consumer数和woricer数，伸缩性 好
实现负载：难于维护分区内的消息顺序；处理链路 变长，导致位移管理困难；worker线程异常可能导 致消费数据丢失
写入消息的时候， 什么情况下 导致HW 会和LEO 不同步呢
follwer请求速度追不上，leader的接受消息的速度， 可能原因 follwer 副本所在的broker 的网络I/O开销过大导致备份消息的速度满于 leader处获取的消息速度
进程卡住： follwer在一段时间内无法向leader 请求数据， 比如之前提到的频繁gc 或者程序bug
LEO log end offset 日志末端唯一， 代表kafka 当前分区存了多少条数据， 12代表存在11条数据
HW 高水印 代表 这个kafka consumer 可见的 ，当前能够读取的 最大offset ， 8 代表kafka消费者最多可以获取到7条数据
HW 必须小于或者等于 LEO 代表所有消息，已提交，或者已备份
分区中的HW 为 ISR 中所有副本LEO 的最小值
log compaction 日志压实(必须设置key) 确保kafka topic 每个分区中，具有相同的key的消息， 至少会保存最新的value 的消息
_consumer_offsets 就使用了日志压实的策略， 最会保存(groupId + topic + 分区号)最新的
broker 中的controller 的作用
更新集群元数据信息
创建topic 删除topic 分区重新分配
prefered leader 副本选举
topic 分区扩展， broker 加入集群 ， broker 崩溃
受控关闭， controller leader 选举
生产者如何实现，消息的精确一次处理的语义呢， 从kafka 0.11.0.0后 kafka提供了幂等性， enable.idempotence=true
kafka调优方向
1 吞吐量
2 延时
3 持久性
4 可用性
OS 级别的错误
connection refused
too many open files
address in use connect
解决方案 ，基础设置
1 禁止atime(最新的访问时间) 更新 可以使用 mount -o noatime
2 可以通过禁止记日志操作， 的方式来提高写的速度，
commit=N_secs 该选项是 没N秒 同步一次数据和元数据 ， 默认是5秒。 如果该值设的比较小，
可以减少崩溃发生时带来的数据丢失， 但若设置的较大， 则会提升整体的吞吐量，以及降低延时， 生产环境 推荐用户设置一个较大的值 1-2分钟
swapiness 设置
2 设置swapiness linux 默认为 60 s 一般建议设置为 0 禁用来提升 内存的使用率，
这里存在一个问题， 当内存用完后， linux OOM Killer 回去杀掉一个进程， 这样可能会导致数据丢失，
坐着建议， 设置为 1-10 之间，
jvm 设置
由于kafka 并没有大量使用堆上内存 所以堆内存设置为 6G，差不多可以满足
-Xmx6g -Xms6g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize—128m -XX:+UseG1GC
-XX:MaxGCPauseMillis— 20 -XX: InitiatingHeapOccupancyPercent 35 -XX:
GlHeapRegionSize—16M -XX: MinMetaspaceFreeRatio—50 -XX:
MaxMetaspaceFreeRatio=85
设置 单个jvm 最大支持的线程数 vm.max_map_count 65530
调优吞吐量，
1producer 设置 batch.size 和linger.ms 通常情况下， 会提升producer 端的TPS
会增加了 消息的延时性，
2合理设置分区个数， 分区的增大到某个数值，后由于锁竞争，和内存占用过多 降低tps, 在实际中，
可以用两倍数来逐步测试 ，直到性能拐点
3设置compression.type 对数据进行压缩，降低I/O的方式来提高tps ,压缩的话主要时针对batch的，
kafka 支持的压缩格式又， gzip ,snappy,lz4 相比来说，lz4组合的性能最好，
4 设置acks 参数， 当参数为1 代表leaderx写入底层文件系统即返回，无须等待follower 响应，acks=0,
表示 producer 端不理会 broker 端的响应， 会提升tps 但是牺牲了消息的持久化，
5 当 producer 端 retries 参数设置的值，进行指定次数的重试，如果消息能够忍受偶尔的数据丢失， 可以将
retries 设置为0 ， tps 会有提升， 但是 消息发生失败后， 就不会重试，
6 max.block.ms 当producer 端的缓冲区被填满后， producer 将会进入阻塞状态， 最大的阻塞时长，
一旦超过， producer 就会抛出 TimeoutException 因此，设置 buffer.memeory(默认32MB) 的值 能使
producer 使得阻塞的情况得到缓解，
consumer 端 fetch.min.bytes 的作用， 设置leader 副本没错返回 consumer 的最小字节数，
通过增加该参数 fafka 会为每个fetch 请求的response 填入更多的数据， 减少网络开销， 提升TPS， 另一方面，
会导致延时的增加，
broker ，num。replica.fetchers 的值， 该值控制follower 从leader 副本中，获取的最大线程数， 默认使1 表示
follower 只有一个线程去实时拉去leader 的最新消息， 当 acks=all 的 producer 而言， 主要的延时可能都耽误在follower于leader 同步的过程，
增加 该值能够缩短同步的实际间隔， 提升producer的tps
参数总结
broker 端
•适当增加num.replica.fetchers,但不要超过CPU核数。
•调优GC避免经常性的Full GC。
producer 端
•适当增加batch.size，比如100-512KB。
•适当增加linger.ms，比如10-00毫秒。
•设置 compression.type=lz4。
• acks=0 或 1
• retries=0
•若多线程共享producer或分区数很多，增加buffer.memory。 consumer 端
•采用多consumer实例。
•增加 fetch.min.bytes，比如 100000。
调优延时， 大体和调优吞吐量相反，
broker 端
• 适 度 增 加 num.replica.fetchers。
•避 免 创 建 过 多 topic分 区 。
producer 端
•设 置 linger.ms=0
• 设 置 compression.type=none
•设 置 acks=l或 0
consumer 端
设 置 fetch.min.bytes=l
调优持久性
broker 端 调优持久性， 有两个重要的参数可以调节，log.flush.interval.ms 和 log.flush.interval.message，
默认情况下， log.flush.interval.ms=0, log.flush.interval.message=long.max_value，一般不需要调节
broker 端
•设置 unclean.leader.election.enable=false (0.1 丨 .0.0之前版本）《
•设置 auto.create.topics.enable=false。
•设置 replicat丨 on.factor = 3， min.insync.replicas = replication.factor - 1»
•设置 default.replication.factor = 3。
•设 置 brokcr.rack属性分散分区数据到不同机架。
•设置丨 og.flush.interval.message 和 丨 og.flush.interval.ms 为一个较小的值
producer 端
•设置 acks=all。
•设 罝 retries为一个较大的值，比如 10-30。
•设置 max.in.flight.requesls.per.connection=l
•设置 enabIe.idempotence=true 启用幂等性。
consumer 端
•设置 auto.commit.enable=false。
•消息消费成功后调用commitSync提交位移。
调优可用性
broker 端
避 免 创 建 过 多 分
设 置 unclean.leader.election.enable=true。
设 置 min.insync.replicas=l。
设 置 num.recovery.threads.per.data.dir=brolcer 端 参 数 log.dirs 中 设 置 的 目 录 数 9
producer 端
•设 罝 acks=l，若一定要设置为all，则遵循h面broker端的min.insyn.replicas配置。
consumer 端
•设 置 session.timeout.ms为 较 低 的 值 ， 比 如 10000。
• (0.丨0.1.0及之后版本）设罝max.poll.imerva丨.ms为比消息平均处理时间稍大的值。
• (0.10.1.0 之前版本）设置 max.poll.records 和 max.partition.fetch.bytes 减少 consumer 处理 消 息 的 总 时 长 ， 避 免 频 繁 rebalance。
笔记来源于 胡夕的apache kafka实战， 有兴趣的可以去看看那本书，