1. 开启压缩功能后，通过 ZSTD 算法对每个事务进行压缩，写入二进制日志。
2. 新版本更改了 libbinlogevents，新增 Transaction_payload_event 作为压缩后的事务表示形式。
class Transaction_payload_event : public Binary_log_event { protected: const char *m_payload; uint64_t m_payload_size; transaction::compression::type m_compression_type; uint64_t m_uncompressed_size;
3. 新增 Transaction_payload_event 编码器/解码器，用于实现对压缩事务的编码和解码。
namespace binary_log {
namespace transaction {
namespace compression {
enum type {
/* No compression. */
NONE = 0,
/* ZSTD compression. */
ZSTD = 1,
};
4. 在 mysqlbinlog 中设计和实现每个事务的解压缩和解码，读取出来的日志与未经压缩的原日志相同，并打印输出所用的压缩算法，事务形式，压缩大小和未压缩大小，作为注释。
#200505 16:24:24 server id 1166555110 end_log_pos 2123 CRC32 0x6add0216 Transaction_Payload payload_size=863 compression_type=ZSTD uncompressed_size=2184# Start of compressed events!
5. 从库（或 MGR-member）在接收已压缩的 binlog 时识别 Transaction_payload_event，不进行二次压缩或解码。以原本的压缩状态写入中继日志；保持压缩状态。回放日志的解码和解压缩过程由 SQL 线程负责。
总结日志压缩过程为：
1）单位事务需要提交并记录 binlog。
2）压缩编码器在缓存中通过 ZSTD 算法压缩以及编码该事务。
3）将缓存中压缩好的事务写入日志中，落盘。
日志读取过程为：
客户端工具（mysqlbinlog、sql 线程）对压缩日志进行解压缩、解码。解压出原本未压缩的日志进行读取或回放。
注意事项
1. 压缩功能以事务为单位进行压缩，不支持非事务引擎。
2. 仅支持对 ROW 模式的 binlog 进行压缩。
3. 目前仅支持 ZSTD 压缩算法，但是，底层设计是开放式的，因此后续官方可能会根据需要添加其他压缩算法（例如 zlib 或 lz4）。
4. 压缩动作是并行进行的，并且发生在 binlog 落盘之前的缓存步骤中。
5. 压缩过程占用本机 CPU 及内存资源。在主从延迟的场景中，如果性能瓶颈时，网络带宽、压缩功能可以有效缓解主从延迟；但是如果性能瓶颈是本机自身处理能力，那么压缩功能反而可能加大主从延迟。