020网站建设合同范本,源码制作网站教程,如何做一个微笑公众号推文,支付网站建设费会计分录压缩 (compression) : 用时间换空间的思想
用较小的 CPU 开销获得磁盘少占用或网络 I/O 少传输
Kafka 消息分两层#xff1a;
消息日志组成 : n 个消息集合消息集合 (message set) 组成 : n 条日志项 (record item)日志项封装了消息 (message)Kafka 在消息集合层上进行写入…压缩 (compression) : 用时间换空间的思想
用较小的 CPU 开销获得磁盘少占用或网络 I/O 少传输
Kafka 消息分两层
消息日志组成 : n 个消息集合消息集合 (message set) 组成 : n 条日志项 (record item)日志项封装了消息 (message)Kafka 在消息集合层上进行写入操作
消息格式
Kafka 消息格式的引入版本 :
V0 版本 : Kafka 0.10.0.0 前V1 版本 : Kafka 0.10.0.0 后引入V2 版本 : Kafka 0.11.0.0 后引入
V0/V1
V0 消息格式 :
CRC 在每个消息中没有时间戳 V1 消息格式 :
CRC 依然在每个消息中增加了时间戳 , 记录该消息的事件时间attribute 的第4位 : 时间戳类型 : CREATE_TIME (Producer 创建时间) , LOG_APPEND_TIME (Broker 写入时间) V0/V1的消息集合格式 :
offset : 该消息的 offset (未压缩) ; 该批消息中最后一条消息的 offset (压缩) V0/V1的缺点 :
空间使用率低 : 固定 4 字节保存 key 或 value 的长度消息总长度未保存 : 要实时计算总字节数只保存最新消息位移 : 压缩后只保留最后一条 offset冗余 CRC 校验 : 每条消息都有 CRC
V2
V2 消息格式 :
增加了消息总长度改为可变长的时间增量 (以消息集合中的起始时间戳)去除了 CRC 验证 V2 消息集合格式 :
增加 CRC 验证增加支持幂等性及事务的 PID , producer epoch , 序列号 CRC
CRC 校验对比
V1 的每条消息都要执行 CRC 校验当出现 CRC 变化时对每条消息都执行 CRC 校验 会浪费空间还耽误 CPU 时间V2 把消息的 CRC 校验移到了消息集合层
CRC 变化情况
Broker 对消息时间戳字段更新时CRC 值会更新Broker 对消息格式转换时 (兼容老版本客户端CRC 值会变化
压缩
各格式的压缩情况
V1 把多条消息进行压缩再保存到外层消息的消息体字段中V2 对整个消息集合进行压缩
V2 / V1 对比 压缩
压缩的地方生产者端和 Broker 端
Broker 从 Producer 收到消息后 而不会重新压缩 (有特例)
开启 GZIP 的 Producer 对象 :
Properties props new Properties();
props.put(bootstrap.servers, localhost:9092);
props.put(acks, all);
props.put(key.serializer, org.apache.kafka.common.serialization.StringSerializer);
props.put(value.serializer, org.apache.kafka.common.serialization.StringSerializer);
//指定 GZIP 压缩
props.put(compression.type, gzip);ProducerString, String producer new KafkaProducer(props);Broker 重新压缩消息情况
Broker 和 Producer 用不同的压缩算法Broker 发生消息格式转换
不同算法
例子 Producer 用 GZIP; Broker 用 SnappyBroker 接收到 GZIP 压缩消息后只能解压缩后用 Snappy 重新压缩一遍不同算法会引发 Broker 端 CPU 使用率飙升
消息格式转换 : 为了兼容老版本的消费者
Broker 会对新版本消息向老版本格式的转换该过程会对消息的解压缩和重新压缩这种消息格式转换对性能影响很大失去压缩Zero Copy 特性
零拷贝 (Zero Copy) 当数据在磁盘和网络进行传输时, 避免昂贵的内核态数据拷贝而实现快速的数据传输
解压缩
信息压缩流程
Producer 发送压缩消息到 Broker 后 Broker 原样保存当 Consumer 请求消息时Broker 原样发送过去当消息到达 Consumer 后由 Consumer 自行解压成原来消息
Consumer 用那种压缩算法
压缩算法封装在消息集合中当 Consumer 读取到消息集合时就得知消息用哪种压缩算法
Broker 端会解压缩 (与消息格式转换不同)
每个压缩过的消息集合在 Broker 写入时会发生解压缩目的为了对消息执行各种验证会提高 CPU 的使用率
京东说明去掉 Broker 消息校验而引入的解压缩 Broker 端的 CPU 使用率减少 50% ( Kafka 2.4 后实现)
压缩算法对比
Kafka 2.1.0 前支持 3 种压缩算法GZIP、Snappy、LZ4
2.1.0 后支持 Zstandard 算法 (zstd)
压缩算法的指标
压缩比原 100 空间压缩后占 20 空间压缩比是 5。压缩比越高越好压缩/解压缩吞吐量每秒能压缩或解压缩多少 MB。吞吐量越高越好
压缩算法比较
吞吐量LZ4 Snappy zstd 和 GZIP压缩比 : zstd LZ4 GZIP Snappy用 Snappy 占带宽最多zstd 最少 启用压缩的时机 :
Producer 的 机器 CPU 充足带宽资源有限。当客户端机器 CPU 吊建议用 zstd 压缩能节省网络带宽
