PolarDB-X提供了兩種形態的Binlog日志消費訂閱能力，且兩種形態可同時共存。
單流形態，即單流Binlog日志變更（Global Binlog）能力，將所有DN的Binlog歸并到同一個全局隊列，提供了保證事務完整性和有序性的日志流，可以提供更高強度的數據一致性保證。例如，在轉賬場景下，基于Global Binlog，接入PolarDB-X的下游MySQL，可以在任何時刻查詢到一致的余額。
多流形態，即多流Binlog日志（Binlog-X）變更能力，并不是將所有DN的Binlog歸并到一個全局隊列，而是將數據進行Hash打散并分發到不同的日志流，在一定程度上犧牲了事務的完整性，但大大提升了擴展性，可以解決大規模集群下單流Binlog存在的單點瓶頸問題。
Binlog單流形態
將所有DN節點的原始Binlog日志歸并到一個隊列，并進行排序和合并，剔除內部細節，對外提供兼容MySQL Binlog格式和dump協議的日志流。當購買PolarDB-X實例時，會默認開通單流Binlog服務。
注意事項
CDC的Master節點和Slave節點之間會進行binlog文件的復制，并保證兩邊數據完全一致，即下游按照filename+position的方式進行消費訂閱，當CDC發生主從切換時，無需擔心文件名和位點會發生變化。
僅當事務策略指定為TSO時，才支持對分布式事務的合并，否則只能保證數據的最終一致性，PolarDB-X默認的事務策略為TSO。
當需要對某行數據進行分區鍵值變更時，需在采用TSO事務策略的分布式事務內進行，才能保證delete事件在binlog中的位置早于insert事件，從而保證數據一致。具體來講，首先需要采用TSO事務策略，然后按如下任意一種進行操作都可以實現分區鍵值的變更，并可以保證數據一致。
執行一條update sql進行分區鍵值的修改；
執行一條replace sql進行分區鍵值的修改；
顯示開啟事務，先執行delete，調整分區鍵值，重新insert。
Binlog多流形態
多流Binlog依然完全兼容MySQL Binlog文件格式和dump協議，可以將每條Binlog日志流看作一個單機MySQL，針對單個日志流，可執行諸如change master... 、show binlog events ...等SQL命令消費或查看Binlog數據。
多流服務不會默認開通，需通過控制臺單獨開通，對于同一個PolarDB-X實例，可支持同時開通多個多流服務，不同服務之間是完全隔離的，每個服務可單獨設置不同的流拆分數量、不同的數據拆分級別、不同的參數規則等，可根據實際需求開通不同形態的多流服務。
拆分級別
多流Binlog提供了3種形式的數據拆分級別，在開通多流服務時可進行設定，滿足不同場景下的使用需求。
庫級別有序
按照數據庫的名字計算Hash值并進行分發，即對應同一個庫的Binlog數據，會始終按序路由給同一個Binlog數據流，適用于單個PolarDB-X實例上數據庫比較多的場景，如果事務不涉及跨庫操作，該策略下不僅可以具備多流能力，還可以保證事務的完整性。
表級別有序
按照數據表的名字計算Hash值并進行分發，即對應同一張表的Binlog數據，會始終按序路由給同一個Binlog數據流，適用于表的數量較多且希望針對單張表的操作（DML/DDL等）在Binlog日志流中保持有序的場景。
行級別有序
按照數據行的主鍵計算Hash值并進行分發，即對應同一數據行的Binlog數據，會始終按序路由給同一個Binlog數據流，適用于希望將數據充分打散且不要求日志數據按庫或按表保持有序的場景，該策略要求數據表必須含有主鍵，無主鍵表的數據會被直接丟棄。
數據拆分級別支持分層配置，分別為服務層和庫表層，不管是哪個層級的配置，一旦設置成功就不再支持修改，否則會觸發相同數據在不同流之間的“漂移”，導致數據一致性問題。所以，在開通多流服務前，需結合實際業務場景進行評估，預先規劃好拆分級別。
服務層
該多流服務的默認拆分級別，如果針對某個庫或表沒有單獨設置拆分級別，則使用服務層的默認配置。
庫表層
可以針對某個庫或表單獨設置拆分級別，該配置會對服務層的配置進行重載，以滿足差異性需求。
當使用行級別有序的拆分級別時，存在一個使用限制，如果數據表包含唯一性約束，并且會發生唯一鍵交換的場景，按照行級別有序進行分發，可能會觸發數據一致性問題，如下所示，uk(name)=a會先后被id=1和id=2的數據所持有，但因無法保證delete(id=1,name=1)和insert(id=2,name=a)在目標庫的執行順序，當insert(id=2,name=2)先于delete(id=1,name=1)執行時，會出現寫入沖突。如果存在類似場景，建議使用表級別有序的拆分級別。
注意事項
在創建多流服務后，流的個數就無法再進行調整，需提前進行好數量規劃，一般建議要大于等于DN的個數。
在創建多流服務后，已經生效的拆分級別就無法再進行調整，需提前進行好規劃。
當需要新增數據表時，如果希望針對該表獨立設置拆分級別，請在該表有數據寫入之前進行配置。
當使用表級別有序的拆分級別時，依然可以對表進行Rename操作，系統會始終依據初始表名進行數據分發。
當使用表級別有序的拆分級別時，為了規避大表數據集中到少數幾個流，出現數據傾斜，可單獨設定路由規則
如果想調整流的個數和已經生效的數據拆分級別，可以通過開通一個新的多流服務來進行替換，此時會涉及下游消費鏈路的一些運維調整。
關于DDL語句在每條Binlog日志流上的分布情況的說明：
拆分級別
分布方式
描述
庫級別
單播+廣播
CREATE DATABASE和DROP DATABASE對應的DDL語句會廣播到每條Binlog日志流，這是因為可以為庫中的某張表設置單獨的拆分級別，因此建庫和刪庫需要采用廣播的方式。
其它類型的DDL語句會單播到某條固定的Binlog日志流。
表級別
單播+廣播
CREATE DATABASE和DROP DATABASE對應的DDL語句會廣播到每條Binlog日志流，這是因為可以為庫中的某張表設置單獨的拆分級別，因此建庫和刪庫需要采用廣播的方式。
其它類型的DDL語句會單播到某條固定的Binlog日志流。
行級別
廣播
所有類型的DDL語句會廣播到每條Binlog日志流。
Binlog透明消費
CDC會優先把構建好的Binlog文件保存在本地磁盤，并支持實時上傳到遠端存儲（如OSS），本地磁盤上的文件一般具有較短的存活周期，遠端存儲上的文件具有較長的存活周期（如15天）。針對遠端存儲上的文件，CDC提供了透明消費能力，即屏蔽了本地和遠端的存儲差異，下游系統無需為訪問遠端存儲上的Binlog數據做任何額外適配。透明消費能力從CDC 2.0.0版本開始支持。
