在之前的文章《技術干貨：人大金倉KFS精準過濾和分片并行入庫技術解析》中，KFS利用分片并行入庫技術，解決了某金融POC數據同步項目中數據入庫持續積壓問題。經過優化后，在200并發的壓測場景中，整體同步性能指標從壓測30分鐘延遲10-20分鐘，變為準實時同步，延遲2秒以內。
分片并行入庫技術的核心原理是將原本需要順序入庫的數據，以事務為單位進行拆分，然后并行入庫。
引入分片并行入庫特性后的入庫邏輯
舉例：在原本單車道的路上，每輛汽車載客一人，為了提高通行效率修建為雙車道或者多車道（雙車道的目的地是同一個城市的不同站），將汽車按照隨機或者輪詢的方式分配到不同的車道上，從而提高通行效率。
但在另外一個金融項目中，由于客戶的業務邏輯非常復雜，數據庫表之間的關聯盤根錯節，為了配置“分片并行入庫”，現場人員耗費了幾天時間在表關聯的梳理上。然而在成功配置“分片并行入庫”方案后，整體的同步性能依然無法滿足客戶訴求。
1問題深度定位
分片并行入庫方案中，為了解決數據一致性問題，引入了Critical數據區的概念。在復雜的數據同步場景中，對整體性能和易用性帶來了比較大的沖擊。
1.1“Critical數據區”的性能瓶頸
KFS“Critical數據區”把需要處理具有多表關聯事務的表標記為“Critical”，當處理“Critical”表的事務數據時，需要保證數據串行入庫。比如下圖所示的9個事務，假設每個事務入庫需要1秒，如果使用3個通道并行入庫，在不考慮數據有序性的情況下每個通道平均分得3個事務，總共需要3秒執行完成。
但是，如果表D被標記為“Critical”，處理所有事務就需要分為三個階段：
階段一：在處理事務5前，要等待所有通道中的數據處理完成；
階段二：串行處理事務5，此時退化成單通道模型；
階段三：事務5處理完成后，恢復成多通道模型，并行處理事務6~9。
舉例：將“Critical”表事務比喻成一輛大貨車，普通表事務比喻成一輛小轎車，在通過一個三車道的隧道時，普通小轎車可以并行通過，但是一旦大貨車過此隧道時，整個隧道就只能允許大貨車單獨通過，并且在大貨車進入隧道中時設置等待指示，不允許小轎車進入。等待大貨車出隧道后，才允許小轎車并行通過。
上述整個事務處理中，事務1~4分3個通道并行處理，需要2次共耗時2秒，處理事務5單獨耗時1秒，事務6~9分3個通道并行處理，需要2次共耗時2秒。所以整體耗時5秒，相比無“Critical”時耗時增加了60%。
實際上現場業務相對復雜，“Critical”表的事務頻繁出現，導致了數據入庫時并行和串行交替切換，即使配置了“分片并行入庫”方案，性能提升效果也不好。
1.2復雜業務場景中的新問題
引入分片并行入庫技術后，KFS在應付簡單業務的數據同步壓測場景中游刃有余，但是在實際的復雜業務中還存在一些問題，比如：
（1）對同一張表的同一行數據先后做不同的操作可能引起數據不一致，例如：
事務1：將表1中key=1數據的key修改為2
事務2：將表1中key=2數據的key修改為3
如果兩個事務被分配在不同分片中，就有可能出現事務2先執行導致最終數據修改失敗。
舉例：車隊中有兩輛車的乘客是一家人，并且希望父母和孩子能夠在同一個車道到到達同一個站點，由先到站的父母帶著后到站的孩子一起去旅行。如果這兩輛車沒有被分配到一個車道，就有可能導致孩子先到站并且后續父母和孩子沒有到達一個站點，導致孩子無人接收，發生孩子丟失的悲劇。
（2）多表關聯交叉事務如果分配在不同通道同時執行，可能產生死鎖。
舉例：車隊中有兩輛車分別有2位乘客，前面一輛車的的乘客為A孩子的父親和B孩子；后面一輛車的乘客為B孩子的父親和A孩子；原本計劃到站后互相交換孩子，繼續各自的旅程。如果這兩輛車沒有被分配到一個車道，就會出現兩個父親互相帶著別人的孩子在錯誤的站點等待自己孩子的情形，誰也無法將孩子交還給對方，誰也無法領回自己的孩子。
（3）具有外鍵約束的表，如果分配在不同通道執行，可能產生數據入庫異常。比如針對主外鍵依賴的兩張表，總是希望被依賴表中的數據先插入，依賴表的數據后插入，才能不違反外鍵約束。如果有外鍵約束的兩張表分配在不同通道，就可能導致依賴表的數據先插入，從而引發數據入庫報錯。
舉例：車隊中有兩輛車的乘客是一家人，并且希望父母先到，孩子后到，由先到站的父母帶著后到站的孩子一起去旅行。如果這兩輛車沒有被分配到一個車道，就有可能導致孩子先到站無人接收，發生孩子丟失的悲劇。
由單通道改為多通道后，原本需要串行執行的事務被人為的并行起來。多個通道執行數據入庫的性能不同，多分區如何記錄斷點，以及分區斷點恢復也是一個棘手問題。
2實戰演練，終結行業痛點
針對以上問題，KFS 引入了“基于分區索引分片入庫”方案，在完美解決以上問題的前提下，相較于無差別分片并行入庫還沒有性能損失。
以下我們將通過實際測試結果來驗證在不同場景下“基于分區索引分片入庫”方案和其他方案的性能差異。
2.1模擬測試場景中的效果
2.1.1 測試模型
在數據庫中建立5張表，使用Jmeter工具并行壓測不同的事務數據，分別測試以下幾種場景的性能：
（1）多表純INSERT開啟和關閉分片并行入庫的性能對比；
（2）多表混合事務開啟和關閉分片并行入庫的性能對比；
2.1.2 測試環境
硬件：X86、8核CPU、16GB內存、1TB NVME硬盤
操作系統：CentOS 7.6
JDK：1.8
KES版本：V8R6
2.1.3 測試結果
多表INSERT事務場景下入庫性能對比
5張表并發插入10萬條insert數據（一條insert一個事務），可以看到純INSERT小事務模型下，新引入的“基于分區索引分片入庫”方案和之前無差別“分片并行入庫”方案性能基本持平，相比較原始的單線程入庫性能提升到3倍左右。
多表混合事務場景下入庫性能對比
5張表并發執行增、刪、改操作（約包含18%比例的多表混合事務，混合事務中包含1至5條SQL），合計50萬條數據，可以看到由于多表混合事務的影響，之前無差別“分片并行入庫”方案性能較原始的單線程入庫性能已無多少優勢，而新引入的“基于分區索引分片入庫”方案較比原始的單線程入庫性能提升到2.4倍左右。
2.1.4 總結
“基于分區索引分片入庫”方案，可以在不損失無差別分片并行入庫方案性能的前提下，彌補無差別分片并行入庫方案的缺陷。
2.2客戶問題解決效果
在配置了“基于分區索引分片入庫”方案后，實際業務場景的表現效果和模擬測試基本一致，開啟4通道并行入庫后，入庫性能基本達到了單通道的2倍多，原先的并發24小時業務延遲持續拉大，變為了準實時同步。
3極致性能背后的黑科技
3.1關鍵技術 基于分區索引分片入庫方案
引入Critical數據區概念的分片并行入庫技術最大的問題是需要預先清楚業務場景，才能將正確的表放入Critical數據區中。針對實際業務動態變化的場景，可能出現因配置遺漏導致數據不一致性。本次，我們使用了一種基于分區索引自動分區的關鍵技術，在不降低性能的前提下，很好的解決了這些問題。
3.1.1 使用分區索引來指導事務分片
自動分區技術解決的關鍵問題是：維護未提交事務的信息。其核心原理為：分發事務時，根據分區索引確認分發的具體通道，最大限度的減少觸發Critical數據區。
分區索引中僅記錄了未提交的事務。數據同步過程中存在相互依賴的事務和總事務數量比起來，占比很小。
因此僅需要很小的內存空間，就解決掉了使用“Critical數據區的分片并行入庫技術”中存在的需要客戶自行配置Critical表的易用性問題。使分片并行入庫技術向產品化更進了一步。
3.1.2使用分區屏障來解決分區失效問題
分區索引方案中當入庫器寫數據庫速度不足（比如數據庫性能瓶頸）時，一旦出現多表關聯事件，會導致后續事件全部發送到同一分區，從而引發多分區機制的失效
為了解決多分區失效問題，又配套引入分區屏障機制，當某個分區隊列滿時，對此分區設置一個屏障，后續準備發送到此分區的數據暫時阻塞。入庫器在寫出事務，更新分區索引時，會自動檢查當前分區的使用容量，如果使用容量小于某閾值（例如50%），則移除此分區上的屏障，允許后續事務被分發至次分區。
使用了分區屏障機制后，有效解決了數據集中分發至某一分區時導致分區失效的連鎖反應。
4結語
在使用了分區索引和分區屏障技術后，KFS的并行分區入庫技術走向成熟。KFS并行分區入庫技術目前已成功被運用到多個關鍵項目中，幫助客戶極大的縮短數據集成時間，提升業務系統的運行效率。
KFS作為一款自主研發的國產數據同步軟件，深耕于各種國產化數據改造項目。面對每一次數據同步的性能挑戰，奮力創新，更多黑科技已經蓄勢待發，讓我們拭目以待！
