2.新版本更改了libbinlogevents，並添加了Transaction_payload_event作為壓縮的事務表示。
class Transaction _ payload _ event:public Binary _ log _ event { protected:？const char * m _ payload？uint64 _ t m _ payload _ size？transaction::壓縮::type m _ compression _ type？uint64 _ t m _ uncompressed _ size
3.添加Transaction_payload_event編碼器/解碼器，實現壓縮事務的編碼和解碼。
命名空間binary_log {
命名空間事務{
命名空間壓縮{
枚舉類型{
/*無壓縮。*/
無= 0，
/* ZSTD壓縮。*/
ZSTD = 1，
};
4.設計並實現mysqlbinlog中每個事務的解壓縮和解碼。讀取的日誌與未壓縮的原始日誌相同，打印出壓縮算法、事務形式、壓縮大小和未壓縮大小作為註釋。
#200505 16:24:24服務器id 116655110？end _ log _ pos 2123 CRC32 0x 6 add 0216 Transaction _ Payload Payload _ size = 863 compression _ type = ZSTD？uncompressed_size=2184#壓縮事件開始！
5.從庫(或MGR-member)在接收壓縮的二進制日誌時識別Transaction_payload_event，並且不執行二次壓縮或解碼。以原始壓縮狀態寫入中繼日誌；保持壓縮狀態。回放日誌的解碼和解壓縮過程由SQL線程負責。
摘要日誌壓縮過程如下:
1)公司交易需要提交並binlog記錄。
2)壓縮編碼器通過ZSTD算法對緩存中的事務進行壓縮編碼。
3)將緩存中的壓縮事務寫入日誌並註銷。
日誌讀取過程如下:
客戶端工具(mysqlbinlog，sql thread)對壓縮的日誌進行解壓縮和解碼。解壓縮原始的未壓縮日誌，以便閱讀或回放。
需要註意的事項
1.壓縮函數壓縮事務，不支持非事務引擎。
2.只能壓縮行模式下的binlog。
3.目前只支持ZSTD壓縮算法，但底層設計是開放的，後續官方可能會根據需要添加其他壓縮算法(如zlib或lz4)。
4.壓縮操作是並行執行的，發生在binlog被刪除之前的緩存步驟中。
5.壓縮過程會占用本地CPU和內存資源。在主從延遲的場景下，如果性能是瓶頸，網絡帶寬和壓縮功能可以有效緩解主從延遲；但是，如果性能瓶頸是機器本身的處理能力，壓縮功能反而可能增加主從延遲。