《大規模分布式存儲系統》第九章 分布式存儲引擎

• 概述

    本章主要介紹 OceanBase 分布式引擎層各子產品的實作細節。涉及到資料結構、RPC開發架構、記憶體優化等細節，即使介紹的較為詳細但是對于深入學習還是不夠的，隻能在日常工作中大量的實踐才能充分體會。本部分隻以個人視角，記錄較為重要的技術。

• 公共子產品（基礎庫）

記憶體管理：全局的記憶體池（64Kb、2MB兩種），每個線程單獨的記憶體管理。全局記憶體池好處有兩個，第一是可以統計各子產品的記憶體使用情況，第二是友善調試，空閑記憶體用特殊值填充，異常情況下及時core。在系統開發初期，滿足可控性 和 減少記憶體碎片的需求，雖然技術不那麼高深（效率差等問題）。

資料結構

    HashMap：位鎖，一個桶一個位級别的鎖。延遲初始化，每次初始化一段桶，省時高效。

    B樹：增加并發性能、寫時複制技術更新時不影響讀、删除操作通過葉子節點追加删除标記實作，好處是不改變索引。

    鎖：互斥鎖 與 共享鎖機制公用一個資料結構，通過标志位區分，且可以互相轉換（更高效）。

任務隊列：單生産者多消費之，單純的任務隊列，鎖會成為瓶頸。解決方案，消息隊列中預先配置設定好線程号，消費者每次隻會去指定的槽位check，減少了鎖的占用時間。

• RootServer實作機制

    RootTable記錄了子表的元資訊，使用了寫時複制技術，提高讀的性能。持有UpdateServer的Token，如果RootServer本身更新，租約過期，無法進行寫請求，暴漏一個接口，可以讓UpdateServer持有Token的時間較長（30min）。

    注：期間主挂了呢？還需要更完備的方案。

• UpdateServer實作機制

    記錄檔通過Direct IO寫入磁盤，避免感染系統緩存，因為系統緩存針對的主要是資料，可以提高性能。MemTable采用的資料結構是B樹，葉子節點是連結清單，記錄了修改日志。所有的表格公用一個SSTable。網絡架構，Tbnet使用的是讀寫單線程，pusk、pull任務隊列，然後分發給工作線程，上下文切換成為性能瓶頸，通過epoll + 多線程直接調用業務邏輯，減少上下文切換。

• ChunkServer實作機制

    CPU與磁盤IO實作異步，通過雙緩存實作。定期合并需要控制速度，請求分級、ChunkServer增加随機延時、控制每次合并的行數。

• 消除更新瓶頸

    資料旁路導入（SSTable加載），通過MapReduce等技術（主要是OLAP業務）跑出子表并生成相關SSTable檔案，傳輸到ChunkServer上，批量執行加載操作，然後彙報給RootServer（具體實作還是較為複雜的，涉及到各種容錯、完備性校驗等等）。UpdateServer可以通過主鍵hash為叢集，跨主鍵事務需要2PC。需要明确的是，針對OLTP業務尤其天生的天花闆，例如，全球50億人，每天又五分之一産生一筆交易，也僅僅10億條資料。