2019-2020年，隨著計費、佣金、結算專案的相繼上線，分散式記憶體資料庫(後述ZMDB)承擔了計費、賬務、餘額、場景三、佣金、結算等各個系統的核心資料，在各業務專案中佔據著越來越重要的作用。
ZMDB充分發揮分散式的特性，作為公共平臺元件，為業務實現資料去O、資源整合、效能提升、持續線上等各種優勢，助力各接入的業務單元騰飛。19年隨著重慶、甘肅、新疆三省BSS3.0上線，最後一個TT記憶體庫的堡壘——餘額庫，也被ZMDB完全替代，並助力大量業務(餘額繳費、查詢等場景三及介面類業務)實現功能、效能的飛躍。
ZMDB在部分省餘額庫資料支撐概況
我司自研的ZMDB是一個支援SQL92標準的、共享記憶體實現的關係型資料庫，在具有完整的SQL處理、事務控制、行級鎖上，還支援水平分片、分散式事務處理、主機故障自動切換等功能。此外，ZMDB還為業務提供了標準的JDBC/ODBC訪問介面，實現了業務從傳統關係型資料庫(指ORACLE\INFORMIX\MYSQL等以檔案儲存為核心的物理資料庫)到ZMDB的快速遷移。ZMDB在資料關係表示、事務特性、SQL標準上與傳統關係型資料庫的平臺標準高度一致，為高速發展的各類熱點資料訪問場景提供了一種更優的選擇。
記憶體資料庫本質上是與傳統資料庫和快取的互補，它的優勢在於既完美實現了基於關係型資料庫的SQL標準、事務特性、資料關係表達，又實現了記憶體操作微秒級的高效能指標，為當前電信業務脫離傳統資料庫的束縛提供了一種更優的解決方案。
記憶體資料庫架構提升迫在眉睫
在計費2.8時代，記憶體資料庫例項主要是部署在記憶體較大的單個主機上(一般是AIX機器)，提供業務資料直連訪問的能力。在這樣的架構下，隨著業務規模和資料的不斷擴充套件，就需要增加大量主機冗餘儲存資料。臨近3.0時代，當前的架構模式越來越難以支撐海量增長的資料和應用，為了有效的整合資源、建造可容納上萬連結的分散式叢集，ZMDB的分散式架構提升勢在必行。
作為計費核心的關係型資料庫，為了對業務系統的高效支撐，ZMDB在進行分散式架構演進時必然面臨諸多方面的考慮：
首先，在實現分散式框架後，應用如何透明接入ZMDB是首當其衝需要考慮的問題。必須保證業務在最少改造的前提下，實現資料分片訪問、分散式事務、分散式鎖控制等核心功能，否則現網核心業務中(比如批價、合賬)的大量事務一致性需求就沒法滿足。隨之帶來的，將是整個計費系統的準確性和穩定性的下降，對其他接入ZMDB的系統(佣金、結算、OCS等)來說也存在不小的風險。
其次，在將平臺從AIX遷移到X86上後，作業系統的穩定性也隨之下降，主機隨時有可能出現宕機的情況。而在計費系統中，大量場景三業務(餘額充值、查詢等關鍵介面)也是訪問記憶體庫的，這些業務不僅涉及集團考核，也影響著眾多電信使用者的體驗感知，不允許出任何差錯。因此，實現ZMDB的高可用，在單點故障時可以實現業務無感知的自動切換，也是重中之重的工作。
最後，如何彌補系統從直連訪問切換到遠端訪問所帶來的時延影響，也是我們要解決的關鍵問題。MDB本地訪問單條記錄的時延約1微秒，而1次網路互動帶來的時延就已經有上百微秒，業務切換到遠端訪問後單筆交易效能下降近百倍。當然，隨著分散式系統帶來的連結數擴容，大部分業務可以透過增加併發處理流程，保證系統整體TPS提升。但是，對於某些嚴格序列執行的業務，比如計費出賬相關的部分業務流程(日租日優惠、下賬等)，就沒辦法透過簡單的併發拆分提升效能，最終會導致出賬效能急劇下降，無法實現集團1號8點出賬的規範要求。
綜上所述，進入BSS3.0階段，如何針對MDB的例項資料進行資源整合，適應業務規模和資料的不斷擴充套件，並保證對業務系統的高效能、高可靠、高穩定支撐，成為MDB演進道路上迫在眉睫的重點工作。
分散式架構提升的路該往哪走
MDB的分散式架構演進過程，在功能上面臨跨節點分散式事務、分散式死鎖的挑戰；在效能上面臨從本地直連訪問切換到遠端訪問帶來的時延提升挑戰；在高可用上面臨主備資料一致性、線上切換恢復的挑戰。起初，這些問題我們準備直接按照行業標準進行，完全參考業內開源分散式資料庫解決方案，但是經過方案的預研和對比，發現照搬的效果差強人意。
為什麼現成的不能直接用，存在哪些問題呢？
首先，計費後臺核心業務邏輯大多是由C++實現的，透過公共介面實現對MDB、ORACLE、INFORMIX、TT等資料庫的訪問，相關協議也都支援SQL繫結變數。在計費3.0改造過程中，保持原有介面的可用性，可以讓業務具備在多種資料庫下動態切換的能力；反之，則需要重新進行大規模的介面和協議改造。開源的資料庫訪問介面與協議大多是基於JDBC和MYSQL協議演進而來，在功能、效能、及改造量上都沒法滿足計費需求。同時，其中大多是以動態SQL的形式實現資料繫結，與計費使用繫結變數的形式有著本質的差異，在安全性、可靠性，以及程式碼適配程度上都有著不同程度的影響。一旦直接採用開源方案，將導致整個系統從業務層、資料訪問層再到協議層的全面重構，這個代價是巨大的。
計費C++業務資料庫訪問架構
其次，開源的分散式協議在解決分散式事務、分散式死鎖等問題上，依賴於所引入的控制節點，而這些節點無一例外需要透過犧牲系統整體TPS為代價。此外，分散式事務的處理難度不僅是在保證不同節點的事務一致性上，而且還會在併發操作的場景下，在網路時延和CPU切換的共同作用下，觸發難以預警的分散式死鎖。面臨國內電信行業複雜的資料關係(三戶模型、產品例項關係等)，這些問題是必然會發生，也必須要解決的。
分散式死鎖問題時序概念圖
最後，在效能上要達到微秒級、在高可用切換上要達到秒級、單節點TPS要達到十萬級，大部分開源架構都沒法滿足這些硬性的指標要求。
綜上所述，在我們經過一段時間的預研、學習、實踐後，明確得出ZMDB的分散式架構演進之路，必須以創新自研為出發點、以借鑑學習為方式、以結果為導向，並緊貼國內業務現狀和訴求，一步一個腳印，踏踏實實的走出來。
自研分散式框架解決的關鍵問題
應用如何透明接入：多層動態分散式協議
ZMDB多層動態分散式協議
叢集統籌層
統一封裝資料訪問介面，包括客戶資料訪問介面、實時帳單訪問介面、揀重存檔訪問介面、規則資料訪問介面、清單資料訪問介面等，實現計費2.8遷移到3.0的所有C++、JAVA應用零改造接入ZMDB。
完成對例項叢集的節點拓撲、分片資訊進行統籌管理。
節點分管層
動態完成節點選擇、連結控制、節點狀態控制、事務控制、結果集合並，並實現對業務透明的分散式記憶體資料庫訪問。
增加業務跨節點操作的多種模式，實現動態調配業務序列、並行訪問節點，徹底解決分散式死鎖問題。
資料互動層
完美對接使用者資料資料、累積量資料、餘額資料、賬單資料、信控資料、流控資料、撿重資料等多鍾資料型別。透過自定義的協議進行訪問控制，實現單例項百億級資料高速訪問，平均單條訪問時延生產約120微秒。
保證系統高線上率：節點故障自動切換
ZMDB的分散式架構透過抽象出叢集中的關鍵節點屬性，構造叢集狀態切換的狀態機，實現對所有正常、異常下的節點狀態進行精確維護。叢集執行期間，每個節點都區分成主讀節點和讀寫節點，而狀態的維護變更由管理節點統一進行，直接避免了分散式系統中的腦裂問題。各節點的狀態拓撲，在每個DBC介面處也進行了維護，由上述分散式協議確認叢集拓撲並進行重試、重連。目前，ZMDB已經具備配置1秒內檢測主備故障，並在線自動切換的能力，切換期間應用完全無感知。
低時延的業務訴求：本地快取記憶體
ZMDB本地快取記憶體功能架構
部分業務對於資料訪問時延有著較高要求，比如賬期類的業務應用(日租日優惠等)，這些業務具有掃描大量重複資料的訴求。ZMDB助力於這樣的業務場景，提供了本地快取記憶體，以較少的本地記憶體儲存，實現業務透過DBC介面無感知接入快取和切換叢集查詢，並達到1微秒級的訪問效能。此外，基於我們提出的《一種基於SQL特徵的改進資料庫快取記憶體非同步重新整理的方法》，快取資料也可以準時的與叢集進行同步。目前，使用本地快取記憶體的業務處理效能均可以上升數倍，在各種對效能苛刻的業務場景下有著廣泛應用。
擔當使命，接過時代的接力棒
2019年下半年，隨著ZMDB在計費、佣金、結算、OCS等專案的廣泛應用，我們不僅實現所有使用單機MDB的專案成功遷移至ZMDB，還新增了對場景三、餘額、佣金、結算等專案的高度支援。ZMDB在業務承載力、系統穩定性、系統高可用、叢集效能上表現卓越，在電信行業的場景上承擔著越來越重要的角色：
訪問效能有保障：場景三(餘額查詢、套餐餘量查詢、話費充值等)遷入ZMDB提效支撐，特別是甘肅、新疆、重慶等省份餘額資料使用ZMDB替換TT，極大的優化了業務訪問效能，保障了各省集團考核名列前茅；出賬(累積量初始化、下賬、批衝等)基於ZMDB效率最佳化，助力新疆在全國出賬比武勇奪第一。此外，ZMDB也與業內廣泛使用的TT資料庫進行對標，訪問效能在業內保持領先水平。
ZMDB與TT效能對標(單鏈接)
業務支撐有經驗：ZMDB始終堅持易接入、高效能、可擴充套件的方式擁抱各類業務，為業務的資料去O、效能最佳化、持續線上提供強有力的解決方案。目前ZMDB已經在計費、賬務、OCS、佣金、結算等幾十個專案中承載了各種型別的海量關鍵資料，單例項可容納五千張表和上萬連結，大量核心資料(使用者資料、使用者餘額、使用者累積量、使用者賬單等)也已完全基於ZMDB穩定性執行。
ZMDB在部分計費省份上支撐的使用者及資料概況
系統穩定有成績：ZMDB作用在各專案後，對於生產中各類單點故障(主機宕機、網路中斷、更換硬體)，目前均已做到高可用支撐。透過系統的故障線上切換方案，為業務提供高度線上不間斷的可靠服務，並配合客戶進行多次驗證，得到廣泛認可。目前大部分例項均已接近一年連續提供高強度的業務支撐，部分關鍵例項(餘額、累積量等)在上線至今也均實現系統故障率為零的成績。
ZMDB在完成自研的分散式架構提升後交出了一份令人認可的答卷，我們在系統架構不斷最佳化的過程中也獲益良多。分散式記憶體資料庫為paas平臺在資料庫方向的遺漏做了完美的補充和闡釋，應用的場景也越來越廣泛。而當前的架構提升只是我們擁抱未來的第一步，如何讓ZMDB具備助力更多業務場景的能力，具備承接5G時代的要求，是我們接下來首當其衝要考慮的核心問題。
目前，我們已經同步開展覆蓋更多複雜SQL型別的預研工作，透過與分散式資料庫進行更深層次的對標，探索並實現ZMDB更多的應用場景。同時，隨著基礎設施的不斷升級，我們也會在可擴充套件、易運維的方向持續進行最佳化，尋求突破。只有不斷持續迭代，不斷學習和追求更有益於生產的技術，才能讓我們有更好的機會把握未來的無限機遇。