Apache Kafka 2.1.0正式支持ZStandard —— ZStandard是Facebook開源的壓縮算法，旨在提供超高的壓縮比(compression ratio)，具體細節參見https://facebook.github.io/zstd/。本文對Kafka支持的這幾種壓縮算法(GZIP、Snappy、LZ4、ZStandard)做了一下基本的性能測試，希望能夠以不同維度去衡量不同壓縮算法在Kafka中的表現。
一、環境准備
本次測試使用了兩台雲主機，一台作為Kafka的服務器，跑broker進程；另一台作為client，運行Kafka的客戶端程序(producer和consumer)，具體配置如下：
軟件配置如下：
二、測試topic准備
依次創建4個topic：test1、test2、test3、test4，分別用於LZ4、ZStandard、Snappy和GZIP的測試，這些topic都是單分區單副本。
三、測試producer端
使用kafka-producer-perf-test.sh腳本依次為4個topic發送60,000,000條消息，每條消息1KB大小，去計算各種壓縮算法的TPS以及其他指標。結果如下：
1、客戶端CPU使用率統計圖
結論：Snappy算法使用的CPU資源最多，其他3種壓縮算法相差不多。
2、Broker服務器帶寬統計
結論：Snappy算法占用的帶寬最多且遙遙領先，LZ4次之，而新引入的ZStandard使用的帶寬最少。一個可能的原因是ZStandard有較高的壓縮比，減少了總體的網絡IO傳輸量。
3、producer吞吐量(TPS)統計
結論：配置LZ4的producer TPS最高——LZ4算法有着最快的壓縮時間（至少是top3），故整體TPS最高也不令人驚訝。Snappy次之，ZStandard位居第三位。說明ZStandard不是一個很快的壓縮算法。
4、producer延時分布統計
結論：GZIP算法的延時最低，ZStandard次之。有意思的是，Snappy算法的平均值和99.9分位均值比較接近，而LZ4算法方差較大（當然也可能因為異常點導致）。總之從延時角度來看GZIP最優。
5、磁盤占用統計
結論：配置ZStandard算法producer生產的消息有着最高的壓縮比，這符合ZStandard算法官方的定位："Zstd can trade compression speed for stronger compression ratios." —— 即該算法犧牲一部分壓縮速度去換取更高的壓縮比。
四、測試consumer端
使用kafka-consumer-perf-test.sh腳本依次消費4個topic，每個topic消費60,000,000條消息，去計算consumer端解壓縮性能以及其他核心指標，結果如下：
1、客戶端CPU使用率統計
結論：基本上4種壓縮算法的客戶端CPU使用率基本持平，ZStandard算法略高一些
2、Broker端帶寬占用統計
結論：Snappy占用帶寬最多，ZStandard最少——同理，這是因為ZStandard有最高的壓縮比，極大地降低了網絡IO傳輸量。
3、consumer吞吐量(TPS)統計
結論：配置LZ4算法的consumer有着最高的TPS，而ZStandard算法最低。
五、總結
相比於其他壓縮算法，ZStandard有着最高的壓縮比，相同的消息量占用最少的磁盤容量，因此帶寬的占用也是比較少的，但是在TPS方面的表現並不搶眼，因此對於那些在乎磁盤和帶寬資源的用戶而言，配置ZStandard算法似乎是個不錯的選擇，但如果追求應用TPS，就目前的Kafka而言LZ4依然是最好的選擇。