那个网站是专门做机械设备小程序如何推广运营
存储机制
kafka通过topic作为主题缓存数据，一个topic主题可以包括多个partition，每个partition是一个有序的队列，同一个topic的不同partiton可以分配在不同的broker（kafka服务器）。
关系图
partition分布图
名称为t_zd的topic为3分区2副本，其在3节点kafka集群的分布如下：
概念
topic
主题，即消息存放的目录。
Partition
-
一个topic可以分为多个partition；
-
每个partition是一个有序的队列；
-
每个partition实际对应一个文件夹，包含多个segment文件；
-
partition中的每条消息都会分配一个有序的id，即offset；
segment
- Kafka用于存储消息的基本单元；
- segment指partition文件夹下产生的文件；
- segment文件命名与offset有关，为log start offset；
- 每个分段都有一个起始偏移量和一个结束偏移量，用于定位消息的位置；
- 一个segment对应一个日志文件（[offset].log）、时间索引文件（[offset].timeindex）和索引文件（[offset.index]），日志文件是用来记录消息，索引文件用来保存消息的索引；
- segment的大小可以通过server.properties配置文件中log.segment.bytes来配置，默认1G；
索引文件(index)
- 记录固定消息量的索引编号范围；
- Kafka在查询时，先从Index中定位到小范围的索引编号区间，再去Log中在小范围的数据块中查询具体数据，此索引区间的查询方式称为：稀疏索引；
日志文件(log)
- 负责消息的追加、读取和索引等操作；
- 每条消息有自增编号，只追加不修改；
消息（message）
示例
[root@192 zd-first-topic-0]$ls
00000000000000000000.index 00000000000000000000.timeindex partition.metadata
00000000000000000000.log leader-epoch-checkpoint
[root@192 zd-first-topic-0]$sh bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.log --print-data-logDumping 00000000000000000000.log
Log starting offset: 0
baseOffset: 0 lastOffset: 0 count: 1 baseSequence: 0 lastSequence: 0 producerId: 0 producerEpoch: 0 partitionLeaderEpoch: 0 isTransactional: false isControl: false deleteHorizonMs: OptionalLong.empty position: 0 CreateTime: 1712889750352 size: 79 magic: 2 compresscodec: none crc: 3489688351 isvalid: true
| offset: 0 CreateTime: 1712889750352 keySize: -1 valueSize: 11 sequence: 0 headerKeys: [] payload: hello kafkabaseOffset: 1 lastOffset: 1 count: 1 baseSequence: 1 lastSequence: 1 producerId: 0 producerEpoch: 0 partitionLeaderEpoch: 0 isTransactional: false isControl: false deleteHorizonMs: OptionalLong.empty position: 79 CreateTime: 1712889754967 size: 84 magic: 2 compresscodec: none crc: 2134132965 isvalid: true
| offset: 1 CreateTime: 1712889754967 keySize: -1 valueSize: 16 sequence: 1 headerKeys: [] payload: kafka first testbaseOffset: 2 lastOffset: 2 count: 1 baseSequence: 2 lastSequence: 2 producerId: 0 producerEpoch: 0 partitionLeaderEpoch: 0 isTransactional: false isControl: false deleteHorizonMs: OptionalLong.empty position: 163 CreateTime: 1712889762442 size: 85 magic: 2 compresscodec: none crc: 3019058576 isvalid: true
| offset: 2 CreateTime: 1712889762442 keySize: -1 valueSize: 17 sequence: 2 headerKeys: [] payload: kafka second test
[root@192 zd-first-topic-0]$
参数说明
- baseOffset：当前消息起始位置的offset；
- position：消息在日志分段文件中对应的物理地址；
- size：消息长度；
关系图
副本机制
- kafka副本机制提高了数据可靠性；
- Kafka默认副本1个，生产环境一般配置为2个，保证数据可靠性，但性能相对降低；
- Kafka中将副本分为Leader副本和Follower副本；
- Kafka生产者只会把数据发往Leader副本，Follower副本找Leader副本进行数据同步；
- Kafka分区中的所有副本统称为AR（Assigned Repllicas），AR = ISR + OSR；
- ISR：表示和Leader保持同步的Follower集合。如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认30s。Leader发生故障之后，就会从ISR中选举新的Leader；
- OSR：Follower与Leader副本同步时，延迟过多的副本；
producer的acks参数表示当生产者生产消息的时候，写入到副本的要求严格程度。
- acks为0：生产者将消息发送至主副本，不等确认可继续发送下一条消息，数据可能丢失。
- acks为1：生产者将消息发送至主副本，等主副本确认可继续发送下一条消息。
- acks为-1或all：生产者将消息发送至主副本，等主副本和从副本同步完成后可继续发送下一条消息。
日志清理机制
配置参数
log.retention.hours: 控制日志文件保留的最长时间；log.retention.bytes: 控制日志文件保留的最大大小；log.retention.minutes: 控制日志文件保留的最短时间；log.retention.check.interval.ms: 日志清理器检查日志是否满足清理条件的频率；log.cleaner.enable: 是否启用日志清理；log.cleanup.policy: 对于超过保留时间的日志文件，如何处理，默认delete。支持日志压缩（compaction）和delete+compaction；
日志删除
基于时间的删除策略
log.retention.hours: 控制日志文件保留的最长时间，默认168小时（7天）；log.delete.delay.ms：执行延迟时间，默认1分钟；
执行日志分段的删除任务时，会首先从Log对象中维护的日志分段的跳跃表中移除需要删除的日志分段，然后将日志分段所对应的数据文件和索引文件添加.deleted后缀。最后转交给名称为delete-file任务来删除以.deleted为后缀的文件，执行延迟时间可通过参数log.delete.delay.ms控制，默认为1分钟。
基于日志大小的删除策略
log.retention.bytes: 控制日志文件保留的最大大小；log.delete.delay.ms：执行延迟时间，默认1分钟；
该策略会依次检查每个日志中的日志分段是否超出指定的大小（log.retention.bytes），对超出指定大小的日志分段采取删除策略。
日志压缩
压缩方式
- 通过GZIP或Snappy压缩器压缩日志段；
- 通过删除不必要的元数据来减少日志的大小；
参数配置
# 对于segment log进行压缩
log.cleaner.enable=true
# 设置压缩后的日志保留的最长时间
log.retention.hours=168
# 设置日志清理进程的运行频率（以小时为单位）
log.cleanup.policy=compact
# 设置压缩后的日志文件保留的最大大小
log.retention.bytes=1073741824
# 设置segment文件的压缩类型
log.cleaner.io.buffer.size=524288
log.cleaner.io.max.bytes.per.second=1048576
log.cleaner.dedupe.buffer.size=134217728
log.cleaner.threads=2
log.cleaner.min.cleanable.ratio=0.5
压缩流程
- Kafka的后台线程会定时将topic遍历两次，第一次将每个Key的哈希值最后一次出现的offset记录下来，第二次检查每个offset对应的Key是否在较为后面的日志中出现过，如果出现了就删除对应的日志；
- 日志压缩是针对Key的，在使用时应注意每个消息的Key值不为NULL；
- 压缩是在Kafka后台通过定时的重新打开Segment来完成的；
