消息压缩
最近更新时间: 2024-10-17 17:10:00
背景描述
由于 Pulsar 限制消息最大为 5MB，消息体过大将会导致消息发送失败。这时需要客户端端需要将大消息进行压缩，以支持20M大小的消息体发送。
Pulsar 大消息处理
Pulsar 的消息最大限制默认是 5MB，Producer发送的消息大小超过5MB会导致消息发送失败。如果客户端发送单条消息大小超过该限制，我们可以采用如下两种方式来处理：
Chunk Message：Plusar 提供 Chunk Message 功能，开启 Chunk 机制时，客户端能够自动对大消息进行拆分，并保证消息的完整性，在 Consumer 能自动整合消息。
压缩消息：主要是对消息数据中相同字符序列进行替换，来压缩消息的大小。Pulsar支持 LZ4、ZLIB、ZSTD、SNAPPY四种压缩算法
我们这里推荐压缩消息对大消息进行处理。
压缩算法分析比较
算法介绍
LZ4
LZ4是一种无损数据压缩算法，可以提供极快的压缩和解压缩速度，对于 CPU 占用少。
ZLIB
ZLIB 压缩算法是一种常用的无损数据压缩技术，它可以有效地减少收发数据的大小，从而提高网络传输效率和网络容量。ZLIB 压缩算法是基于 Lempel-Ziv 压缩算法的一种变体，可以将原始数据压缩到原来的一半大小以下，并且支持压缩和解压缩操作。
ZSTD
ZSTD 压缩算法是一种 Huffman 编码的压缩算法，是 LZ77 的一种变种，可以针对不同数据进行有效压缩。它是一种实时编码算法，在处理大数据时可以更快速、更高效地压缩数据。相比其他压缩算法，ZSTD在提高数据压缩率的同时兼顾压缩速度。
SNAPPY
SNAPPY 压缩是一种无损压缩技术，它依赖于 LZ77 原理来实现压缩效果。SNAPPY 压缩的核心原理是：只要数据流找到两个字符串之间的重复，就会用一组更短的代码来表示这个字符串，这样就可以减少数据流的大小。
算法对比
| 压缩算法 | 压缩比 | 压缩速度 | 解压速度 |
|---|---|---|---|
| ZLIB 1.2.11 -1 | 2.743 | 110MB/S | 400MB/S |
| LZ4 1.8.1 | 2.101 | 750MB/S | 3700MB/S |
| ZSTD 1.3.4-1 | 2.877 | 470MB/S | 1380MB/S |
| SNAPPY 1.1.4 | 2.091 | 530MB/S | 1800MB/S |
吞吐量：LZ4 > SNAPPY > ZSTD > ZLIB
压缩比：ZSTD > ZLIB > LZ4 > SNAPPY
物理资源方面，SNAPPY算法占用的网络带宽最多，ZSTD算法占用的网络带宽最少
各压缩算法测试
测试结果
注意，以下测试结果仅供参考。压缩效果，需要根据具体消息体内容来验证。
| 消息大小 | 消息 | 压缩算法 | topic监控消息大小 | 客户端消息压缩耗时 | 消息发送耗时 |
|---|---|---|---|---|---|
| 5M | 随机消息体 | LZ4(阀值5M) | 9.95M | 31ms | 0.049ms |
| ZLIB | 7.26M | 31ms | 0.038ms | ||
| ZSTD | 8.20M | 31ms | 0.039ms | ||
| SNAPPY(阀值5M) | 9.70M | 33ms | 0.046ms | ||
| 6M | 随机消息体 | ZLIB(阀值6M) | 8.71M | 35ms | 0.044ms |
| ZSTD(阀值6M) | 9.84M | 35ms | 0.046ms | ||
| 20M | 相同消息体 | LZ4 | 0.16M | 41ms | 0.006ms |
| ZLIB | 0.20M | 42ms | 0.006ms | ||
| ZSTD | 0.01M | 42ms | 0.003ms | ||
| SNAPPY | 2.47M | 41ms | 0.021ms | ||
| 40M | 相同消息体 | LZ4 | 0.32M | 123ms | 0.008ms |
| ZLIB | 0.39M | 122ms | 0.008ms | ||
| ZSTD | 0.01M | 124ms | 0.004ms | ||
| SNAPPY | 4.95M | 123ms | 0.036ms | ||
| 80M | 相同消息体 | LZ4 | 0.63M | 241ms | 0.009ms |
| ZLIB | 0.39M | 244ms | 0.01ms | ||
| ZSTD | 0.01M | 243ms | 0.004ms | ||
| SNAPPY(阀值80M) | 9.9M | 243ms | 0.056ms | ||
| 160M | 相同消息体 | LZ4 | 1.26M | 484ms | 0.013ms |
| ZLIB | 1.56M | 479ms | 0.016ms | ||
| ZSTD | 0.03M | 481ms | 0.004ms | ||
| 320M | 相同消息体 | LZ4 | 2.5M | 1035ms | 0.03ms |
| ZLIB | 3.1M | 1008ms | 0.027ms | ||
| ZSTD | 0.03M | 949ms | 0.004ms | ||
| 585M | 相同消息体 | LZ4 | 4.59M | 1705ms | 0.027ms |
| ZLIB | 5.67M | 1733ms | 0.03ms | ||
| ZSTD | 0.11M | 1722ms | 0.006ms |
总结：
1、在纯随机数据流中，四种压缩算法压缩效率都不是很高。消息大小超过 5MB，四种压缩算法都无法将消息压缩到 5MB 以内；
2、在重复数据较多的数据流中，四种压缩算法可以实现很高的压缩速率，其中LZ4、ZLIB、ZSTD压缩算法可以实现将600MB内的消息压缩到5MB以内。
消息压缩 Demo 及使用测试
使用方式
生产端调用参数
java -jar tdmq-sdk-demo-1.0-SNAPSHOT-jar-with-dependencies.jarpulsar://xxxx:6650eyJrZXlJZCI6ImRlZmF1bHRfa2V5SWQiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdXBlcnVzZXIifQ.dYcCfp4XrdWRKdKaWylobY-_xEExfRCi1pMvNyZXbqU pulsar-78ra8ownxb7d/BigMSGSpace/BigMSGTopic subname 1 500 0 1 20480 1 0
消费端调用参数：
java -jar tdmq-sdk-demo-1.0-SNAPSHOT-jar-with-dendencies.jarpulsar://xxxx:6650eyJrZXlJZCI6ImRlZmF1bHRfa2V5SWQiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdXBlcnVzZXIifQ.dYcCfp4XrdWRKdKaWylobY-_xEExfRCi1pMvNyZXbqU pulsar-92d7w2mjwmv9/BigMessSpace/BigMessTopic subname 1 500 1