多級多路歸并

在上篇文章中，我們通過一系列的測試，針對全局binlog的同步能力，得出了幾個核心結(jié)論 BPS可以達(dá)到500M+/s EPS可以達(dá)到220w+/s * TPS可以達(dá)到35w+/s

測試實例的的規(guī)格為：8CN + 8DN + 2CDC 單CN節(jié)點規(guī)格：32核128GB 單DN節(jié)點規(guī)格：32核128GB * 單CDC節(jié)點規(guī)格：16核32GB

此處我們將DN節(jié)點的數(shù)量由8個調(diào)整為16個，進(jìn)行復(fù)測，看看性能是否依然可以達(dá)到如上標(biāo)準(zhǔn)。以TPS為例，使用上篇中的48張表的sysbench數(shù)據(jù)導(dǎo)入進(jìn)行測試

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8' --tables='48' --threads='48' --table-size='10000000' oltp_point_select prepare

測試結(jié)論

TPS只能達(dá)到19w+/s的水平，鏈路出現(xiàn)比較高的延遲，如下圖所示：

并且此時多路歸并線程已經(jīng)滿負(fù)荷運轉(zhuǎn)，如下圖所示：

并且此時多路歸并線程已經(jīng)滿負(fù)荷運轉(zhuǎn)，如下圖所示：

這是因為系統(tǒng)默認(rèn)只開啟了單級歸并，如下圖所示：

隨著DN數(shù)量的增多，參與歸并排序的隊列長度也會隨之增大，性能則相應(yīng)出現(xiàn)衰減(另附多路歸并核心代碼:LogEventMerger.java)，解決辦法是開啟多級歸并，通過“分治”和“并發(fā)”來解決性能瓶頸，如下所示：

開啟多級歸并后，吞吐能力恢復(fù)至正常水平，如下所示：

如上是多級歸并的邏輯示意圖，反映到實際的運行時拓?fù)?，多級歸并可以是線程級的，如下所示：

也可以是進(jìn)程級的，如下所示：

前者用來解決較小規(guī)模集群(<=64DN)的性能瓶頸，后者用來解決更大規(guī)模集群(>64DN)的性能瓶頸。當(dāng)DN數(shù)量不太多時(如32個)，優(yōu)先考慮通過提升單個節(jié)點的配置，采用線程級別的多級歸并來提升性能，避免不必要的網(wǎng)絡(luò)傳輸開銷；當(dāng)DN數(shù)量非常多時(如256個)，很難靠單個節(jié)點承擔(dān)計算、內(nèi)存或網(wǎng)絡(luò)資源的壓力，此時可以通過進(jìn)程級別的多級歸并來提升性能。當(dāng)然，多級歸并也不是“銀彈”，全局Binlog會有一個Global Merge Point，當(dāng)DN數(shù)量足夠多時，仍然會有單點瓶頸問題(尤其是網(wǎng)絡(luò)瓶頸)，可以通過多流Binlog進(jìn)行解決，我們的后續(xù)文章會對PolarDB-X的多流Binlog進(jìn)行介紹。

下面表格是oltp_insert場景下的測試數(shù)據(jù)，分隔行以上的部分是單級歸并可支撐的壓力范圍，當(dāng)QPS高于20w之后，會出現(xiàn)明顯的延遲，開啟多級歸并后，QPS達(dá)到35w時，延遲時間仍然保持在1s以內(nèi)

流水線&并行

全局Binlog數(shù)據(jù)流生產(chǎn)線，采用了類似SEDA(Staged Event-Driven Architecture)的架構(gòu)，共劃分為6個Stage，相鄰的Stage之間以及Stage內(nèi)部組件之間，通過隊列進(jìn)行串聯(lián)，每個Stage內(nèi)部通過異步或多線程并行技術(shù)對數(shù)據(jù)處理進(jìn)行加速。

Extract Stage Extract Stage用于完成一級排序，涉及binlog解析、數(shù)據(jù)整形、元數(shù)據(jù)維護(hù)、ddl處理等，每個DN對應(yīng)一個處理線程，單個DN最大可支持的EPS吞吐為25w/s，采用的性能優(yōu)化手段主要在內(nèi)存管理和緩存管理層面，見下文的內(nèi)存使用優(yōu)化章節(jié)。

Merge Stage Merge Stage用于完成全局排序，保證全局Binlog中數(shù)據(jù)操作的線性一致，采用的性能優(yōu)化手段主要是多級歸并，上文已經(jīng)有詳細(xì)描述，此處不再贅述。

Collect Stage Collect Stage用于實現(xiàn)事務(wù)的合并，將分布式事務(wù)的分散到各個DN的binlog數(shù)據(jù)進(jìn)行排序和合并，采用的性能優(yōu)化手段主要有： 通過RingBuffer，進(jìn)行并行處理，大大提升合并速度 支持“預(yù)序列化”，某個事務(wù)合并完成之后，如果事務(wù)大小小于設(shè)定閾值(如果太大，預(yù)序列化可能會占用大量內(nèi)存)，會直接構(gòu)建Transmit Message并序列化，為Transmit Stage減輕壓力(Transmit Stage序列化操作是單線程處理)

Transmit Stage Transmit Stage用于實現(xiàn)Task和Dumper之間的網(wǎng)絡(luò)傳輸，使用Grpc構(gòu)建Data Stream，采用的性能優(yōu)化手段主要有： Batch模式，多個事務(wù)的event封裝為一個數(shù)據(jù)包，提升吞吐率 Single模式，自動檢測大事務(wù)，單個事務(wù)獨立封裝數(shù)據(jù)包，避免內(nèi)存溢出 異步處理，耗時的序列化和反序列化操作放到獨立線程 動態(tài)反壓控制，避免內(nèi)存溢出

Write Stage Write Stage處于數(shù)據(jù)流的末端，用來構(gòu)建終態(tài)的全局Binlog文件，主要采用了3種優(yōu)化手段： 并行構(gòu)建 使用RingBuffer構(gòu)建緩沖區(qū)，將構(gòu)建binlog event的操作(創(chuàng)建event、更新event內(nèi)容、計算CRC32校驗值等)并行化處理，解決單線程瓶頸。 直接內(nèi)存 采用直接內(nèi)存進(jìn)行IO操作，減小用戶態(tài)和內(nèi)核態(tài)上下文切換 * Write Cache 引入寫緩存，并保證緩存大小為page頁的整數(shù)倍，降低IO頻率和提升page命中率

Backup Stage Backup Stage用于實現(xiàn)全局Binlog文件的備份，支持Dumper之間的主備復(fù)制，和到中心化存儲(如OSS)的冷備份，主要的性能優(yōu)化手段是多線程上傳和下載。

內(nèi)存使用優(yōu)化

全局Binlog系統(tǒng)是一個數(shù)據(jù)密集型的系統(tǒng)，對內(nèi)存資源的管理是一個核心關(guān)鍵問題，下面介紹全局Binlog在內(nèi)存優(yōu)化層面的優(yōu)化手段。

事務(wù)數(shù)據(jù)持久化 排序是全局Binlog系統(tǒng)最核心的功能，在對數(shù)據(jù)進(jìn)行處理時，需要將某個事務(wù)的binlog數(shù)據(jù)全部接收完之后，才能進(jìn)行排序操作，當(dāng)遇到大事務(wù)或者超長事務(wù)空洞時，如果沒有數(shù)據(jù)的持久化機制，很容易把內(nèi)存撐爆，導(dǎo)致full gc或內(nèi)存溢出，影響鏈路的正常運行。對此系統(tǒng)設(shè)計了支持內(nèi)存和磁盤混合存儲的Hybrid KV Store，用來解決內(nèi)存不足的問題，數(shù)據(jù)鏈路的幾個核心Stage深度依賴該Store，如下所示

KV Store的主要特點有： 支持大事務(wù)swap到磁盤，動態(tài)監(jiān)測事務(wù)大小，超過指定閾值后，該事務(wù)數(shù)據(jù)swap到磁盤 支持大事件swap到磁盤，遇到超過指定閾值的binlog event，直接保存到磁盤 支持動態(tài)監(jiān)測內(nèi)存使用率，超過指定閾值后，自動將存量數(shù)據(jù)和新增數(shù)據(jù)swap到磁盤 全磁盤存儲相比純內(nèi)存存儲，性能大概有20%的降低

元數(shù)據(jù)持久化 元數(shù)據(jù)是全局Binlog系統(tǒng)的核心命脈，在庫表非常多的情況下，元數(shù)據(jù)會消耗大量內(nèi)存，可以多達(dá)10幾GB，影響數(shù)據(jù)鏈路的正常運行。舉例來說，48w張數(shù)據(jù)表占用了接近8G的內(nèi)存，如下所示:

系統(tǒng)提供了針對元數(shù)據(jù)的持久化機制，開啟持久化能力之后，元數(shù)據(jù)會被序列化并保存至RocksDB，并支持在內(nèi)存和磁盤之間的動態(tài)Swap，涉及元數(shù)據(jù)持久化的參數(shù)為： meta.persist.basePath : 配置元數(shù)據(jù)持久化目錄 meta.persist.schemaObject.switch : 是否開啟元數(shù)據(jù)持久化

接上面例子，當(dāng)開啟元數(shù)據(jù)持久化之后，內(nèi)存占用大幅降低到只有240M，如下所示:

優(yōu)化內(nèi)存分配 雖然KV Store提供了swap機制，保證了內(nèi)存不夠用時數(shù)據(jù)可以轉(zhuǎn)儲到磁盤，但畢竟會對性能造成影響，最優(yōu)的策略還是盡量減少內(nèi)存的占用，系統(tǒng)提供的主要優(yōu)化手段有： 不同stage對內(nèi)存的要求不一樣，合理控制隊列緩沖區(qū)的大小，規(guī)避不必要的數(shù)據(jù)堆積 規(guī)避不必要的數(shù)據(jù)復(fù)制，如針對ByteString的使用 ByteString.copyFrom方法可以替換為UnsafeByteOperations.unsafeWrap方法，免去字節(jié)數(shù)組copy操作 ByteString.toByteArray方法可以替換為DirectByteOutput.unsafeFetch方法，免去字節(jié)數(shù)組copy操作

總結(jié)

本篇從技術(shù)原理的角度，對全局Binlog的一些核心的性能優(yōu)化手段做了簡要的介紹，通過SEDA流水線架構(gòu)實現(xiàn)了異步和并行處理，通過多級歸并解決了集群規(guī)模擴張時的性能衰減問題，通過一系列的內(nèi)存優(yōu)化手段保證了數(shù)據(jù)鏈路的高效運行，這些優(yōu)化措施，保證了全局Binlog在TPCC 150w tpmC的壓力下，延遲仍可以控制在1s以內(nèi)(參見:性能白皮書）

當(dāng)然，全局Binlog在架構(gòu)上也有天然的劣勢，其在應(yīng)對超大規(guī)模集群時存在單點瓶頸，PolarDB-X的多流Binlog通過犧牲事務(wù)的完整性解決了單點問題，在應(yīng)對超大規(guī)模集群時，能夠保證性能的線性提升，敬請關(guān)注我們的系列文章。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。