阜阳手机网站建设,一个企业该如何进行网络营销,湖北设计公司,怎样为企业设计网站存储机制
kafka通过topic作为主题缓存数据#xff0c;一个topic主题可以包括多个partition#xff0c;每个partition是一个有序的队列#xff0c;同一个topic的不同partiton可以分配在不同的broker#xff08;kafka服务器#xff09;。
关系图 partition分布图
名称为t…存储机制
kafka通过topic作为主题缓存数据一个topic主题可以包括多个partition每个partition是一个有序的队列同一个topic的不同partiton可以分配在不同的brokerkafka服务器。
关系图 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
示例
[root192 zd-first-topic-0]$ls
00000000000000000000.index 00000000000000000000.timeindex partition.metadata
00000000000000000000.log leader-epoch-checkpoint
[root192 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
[root192 zd-first-topic-0]$参数说明
baseOffset当前消息起始位置的offsetposition消息在日志分段文件中对应的物理地址size消息长度
关系图 副本机制
kafka副本机制提高了数据可靠性Kafka默认副本1个生产环境一般配置为2个保证数据可靠性但性能相对降低Kafka中将副本分为Leader副本和Follower副本Kafka生产者只会把数据发往Leader副本Follower副本找Leader副本进行数据同步Kafka分区中的所有副本统称为ARAssigned RepllicasAR ISR OSR ISR表示和Leader保持同步的Follower集合。如果Follower长时间未向Leader发送通信请求或同步数据则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定默认30s。Leader发生故障之后就会从ISR中选举新的LeaderOSRFollower与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和deletecompaction
日志删除
基于时间的删除策略
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.enabletrue
# 设置压缩后的日志保留的最长时间
log.retention.hours168
# 设置日志清理进程的运行频率以小时为单位
log.cleanup.policycompact
# 设置压缩后的日志文件保留的最大大小
log.retention.bytes1073741824
# 设置segment文件的压缩类型
log.cleaner.io.buffer.size524288
log.cleaner.io.max.bytes.per.second1048576
log.cleaner.dedupe.buffer.size134217728
log.cleaner.threads2
log.cleaner.min.cleanable.ratio0.5压缩流程
Kafka的后台线程会定时将topic遍历两次第一次将每个Key的哈希值最后一次出现的offset记录下来第二次检查每个offset对应的Key是否在较为后面的日志中出现过如果出现了就删除对应的日志日志压缩是针对Key的在使用时应注意每个消息的Key值不为NULL压缩是在Kafka后台通过定时的重新打开Segment来完成的
