01  ODP 介紹

「ODP 簡介」

ODP 是 OceanBase 的代理伺服器，對外提供統一的訪問入口：

• ODP 完全相容 MySQL 協議，使用者訪問 ODP 的方式與訪問 MySQL 保持一致，ODP 透明轉發來自客戶端的 SQL 至 OceanBase。使用者無需修改現有的資料庫訪問程式碼，即可正常訪問資料庫。

• 相容 MySQL 的各種語言客戶端，包括 Java/C++/Python/Go/Rust等。

• ODP 無狀態、輕量，CPU 最低需要1c，記憶體啟動約百M，可以在任意 linux 機器上部署。

通過使用 ODP，使用者可以訪問 OceanBase 不同叢集下的不同租戶，簡單方便。

「特性介紹」

除了作為訪問鏈路的入口，ODP 還具有如下核心能力：

• 高效能轉發：ODP 完整相容 MySQL 協議，採用多執行緒非同步框架和透明流式轉發的設計，既保證了資料的高效能轉發，也確保了自身對機器資源的最小消耗。

• 最佳路由：ODP 會充分考慮使用者請求涉及的副本位置、使用者配置的讀寫分離路由策略、OceanBase 多地部署的最優鏈路，以及 OceanBase 各機器的狀態及負載情況。ODP 將使用者的請求路由到最佳的 OBServer，最大程度保證了 OceanBase 整體的高效能運轉。

• 連線管理：針對一個客戶端的物理連線，ODP 維持自身到後端多個 OBServer 的連線，採用基於版本號的增量同步方案維持了每個 OBServer 連線的會話狀態，以此保證了客戶端高效訪問各個 OBServer。

• 專有協議：ODP 與 OBServer 預設採用了 OceanBase 專有協議，如增加報文的 CRC 校驗保證與 OBServer 鏈路的正確性，增強傳輸協議以支援 Oracle 相容性的資料型別和互動模型。

• 安全可信：ODP 支援使用 SSL 訪問資料，並和 MySQL 協議做了相容，以滿足客戶的安全需求。

• 易運維：ODP 本身無狀態，不僅支援無限水平擴充套件，還支援同時訪問多個 OceanBase 叢集。ODP 可以通過豐富的內部命令實現對自身狀態的實時監控，以此實現極大的運維便利性。

我們以下圖為例說明 ODP 的特性：

圖中 APP 是我們的業務程式，APP 前面有三臺 OBProxy（ODP 的程式名叫做 OBProxy）。在實際部署中，OBProxy 和 APP 之間一般會有一個負載均衡如 F5。F5 將請求分散到多臺 OBProxy 上面，而 OBProxy 後面就是 OBServer，圖中有6臺 OBServer。使用 ODP 好處如下：

連線管理：OBServer 叢集規模龐大，機器、軟體出現問題或者本身運維機器上線、下線概率較大，如果直連 OBServer，碰到上面情況客戶端就會發生斷連。ODP 遮蔽了 OBServer 本身分散式的複雜性，客戶連線 ODP，ODP 可以保證連線的穩定性，自身對 OBServer 的複雜狀態進行處理。

資料路由：ODP 知道 OBServer 中資料分佈資訊，可以將使用者 SQL 高效轉發到資料所在機器，使執行更加地高效。如表 t1 資料在圖中 P1 內，表 t2 資料在圖中 P2 內，條 t3 資料在圖中 P3 內，紅色表示主副本，藍色表示備副本，對於 insert into t1 語句 ，ODP 可以將 SQL 轉發到 IDC2 中含有 P1 主副本的機器上。update t2 語句保證了 ODP 可以將 SQL 轉發到 IDC1 中含有 P2 主副本的機器上。

「設計實現」

ODP 主要業務架構如下圖：

ODP 的非同步框架採用了多執行緒 Epoll +非阻塞的模式，非同步轉發框架非常高效。單獨測試非同步框架和 Nginx 對比，ODP 轉發效能和 Nginx 非常接近。在高效轉發基礎上，ODP 實現了 MySQL 通訊協議，進行了生態相容，使 MySQL 客戶端可以無成本使用，並且 ODP 還可以解決通訊過程中和多臺 OBServer 的狀態同步問題。

此外，ODP 還實現了連線管理，能有效 處理和 OBServer 之間的各種網路情況，遮蔽 OBServer 異常，保證 Client 和 ODP 之間連線的穩定。除了這些，ODP 還能有效處理路由問題，確保 SQL 執行效率最佳。

接下來，我們以路由為例說明 ODP 核心功能的實現邏輯。下圖展示了路由的核心模組，主要包含4個步驟：

1. 解析 SQL：ODP 實現了 Parser 技術，ODP 可以從 SQL 中獲取表名、Hint、分割槽鍵等關鍵路由資訊；

2. 路由規則：獲取完 SQL 資訊後，ODP 需要確定路由規則，以實現豐富路由策略，從而應對不同場景挑戰；

3. 路由表：根據規則，ODP 會查詢路由表獲取滿足規則的機器列表，路由表從 OBServer 拉取，通過快取形式儲存在記憶體中；

4.  容災檢查：從機器列表中 ODP 會選擇一個 OBServer 做容災檢查。檢查內容包括 Server是否當機、是否發生過不可用情況等，通過檢查才會將請求發往該機器。

上面每一部分都有很多細節，ODP 本身也經過大量場景打磨，確保其在各種場景中廣泛使用。

「小結」

ODP 是訪問 OceanBase 資料庫的重要工具，在螞蟻集團內部、私有云場景、公有云場景都有廣泛使用，上面介紹了服務 OceanBase 的核心能力。除了這些，ODP 還具有一些中介軟體產品的特性，如 Sharding、連線池、安全、限流熔斷、全鏈路診斷等。目前，ODP 不斷打磨產品的易用性，滿足客戶需求，讓大家使用 OceanBase 更加方便。

02   OCP 介紹

「何為 OCP」

對於資料庫系統來說，想要提升使用者的使用效率，管控平臺的使用必不可少。OceanBase 資料庫作為一個金融級別的分散式資料庫來說，更是如此。OCP 是針對 OceanBase 設計開發的一款資料庫管控平臺，能夠提供白屏化的 OceanBase 運維監控能力，無論是讓新手使用者快速上手使用 OceanBase，還是在生產環境，作為 DBA 日常的運維工具都非常合適。OCP 降低了 OceanBase 運維的複雜性，能夠將 OceanBase 的執行狀態直觀地展示出來，使 OceanBase 不僅兼具高效能和高可用，同時也能做到可運維和可監控。

「為什麼要使用 OCP」

1. 降低運維 OceanBase 的複雜性

相比傳統資料庫，OceanBase 分散式的架構設計帶來了更好的容災能力和近乎無限的擴充套件能力，但是整個系統也更加複雜：

新使用者想要體驗 OceanBase 常常卡在瞭如何將 OceanBase 執行起來的第一步；在生產系統中，想要運維好 OceanBase 也不是一件容易的事情。

OCP 提供了 OceanBase 的運維管控能力，從 OceanBase 叢集的建立到日常使用運維到最終下線，全部都可以通過 OCP 在 Web 端完成。

場景1：我是新手使用者，如何快速建立一個 OceanBase 叢集進行體驗

在 OCP 中，將主機資源新增進去，按照頁面提示，發起建立叢集的任務，任務完成後，叢集就建好了，全程只需要 Web 頁面上填寫一些資訊。

場景2：在大規模生產環境，主機故障經常發生，如何快速進行恢復？

OceanBase 提供了不同級別的容災能力，都依賴多數派予以實現，對於發生少數派的故障可以容忍，但是一定要及時處理，避免其發展成多數派故障，影響可用性。一般處理方式是直接將故障主機進行替換。OCP 提供了一鍵替換故障主機的能力，選擇要替換的主機，發起任務即可。

2. 作為診斷 OceanBase 的利器

好的系統不僅要好用，可監控也是一項重要的能力，OceanBase 提供了各種檢視，記錄自身的執行狀態。要通過這些檢視來排查問題，需要對 OceanBase 足夠了解，而且有些檢視只能記錄當前的狀態值，無法看到一段時間的趨勢。OCP 收集了 OceanBase 主要的監控指標，並且進行了整理，支援實時和歷史趨勢的查詢，能夠以不同的邏輯和時間維度來分析問題。

問題1：OCP 的監控和 OBAgent 有什麼區別，應該怎麼選

OCP 是一個全功能的平臺，包含了監控資料的採集、計算和展示，OBAgent 僅做採集，需要配合 Prometheus 和 Grafana 來使用。

OCP 的指標經過篩選，頁面也是按照 OceanBase 的資源進行設計，而 OBAgent 的配置更加靈活，採集計算的邏輯以及 Grafana 的展示頁面都可以自己配置，每部分更專注自身的邏輯。

問題2：OCP 的監控資料如何與其他系統整合

OCP 採集監控資料是通過 Exporter 的形式進行的採集，可以和 Prometheus 進行整合。OCP 提供了 OpenAPI 進行監控資料的查詢，可以直接查詢到計算好的監控資料。

3. 為其他元件提供配置服務

OCP 作為 OceanBase 生態中的一個重要成員，除了具有 OceanBase 的運維監控功能之外，也為其他元件提供了 OceanBase 的原資料查詢功能，OCP 中記錄了 OceanBase 的 Rootservice 地址資訊，並保證了同步，可以為其他元件提供連線 OceanBase 的方式。

03   OCP 系統架構簡介

「 OCP 模組簡介」

OCP 最重要的模組包括  OCP 管理服務、OCP Agent、儲存資料庫三個部分：

• OCP 管理服務：一個由 java 實現的服務，實現了管控 OceanBase 的主要邏輯，提供 http 服務；

• OCP Agent：部署在 OCP 管理的主機上，負責執行 OCP server 傳送的運維命令、採集監控指標；

• 儲存資料庫：包含元資訊資料庫和監控資料庫，元資訊資料庫記錄了 OCP 管理的資源，包括主機、OceanBase 叢集、OBProxy 等，監控資料庫記錄了採集到的監控原始資料和聚合計算之後的結果。

「OCP 運維功能實現簡介」

OceanBase 作為一款分散式資料庫，相較於傳統資料庫有更多的節點和元件需要管理。為了保證系統的持續可用性，OceanBase 運維過程往往更復雜，同時也較容易遇到異常情況，我們需要考慮每一步操作的原子性。OCP 為了解決以上問題，設計了一個任務引擎以支撐 OceanBase 的運維場景。

OCP 通過將 OceanBase 的運維流程拆分為一個個獨立的原子任務，並將這些原子任務按照 DAG 圖的方式組織起來，按照順序執行，互相不依賴的節點可以併發執行，在某個節點出錯時，支援重試任務，能夠讓運維任務的執行更加高效可靠。

在不同平臺上，命令的表現行為可能不同，OCP-Agent 將常用的命令抽象成介面，底層根據平臺進行了不同的實現，對外暴露出來的是相同的介面，涉及到在主機上的運維操作，由 OCP-Server 呼叫 OCP-Agent 的介面來實現。

「OCP 監控功能實現簡介」

一方面，OCP 的監控功能參考了 Prometheus 的實現方式，OCP-Agent 提供了 Exporter 能力，會根據配置的採集邏輯來採集資料，將採集到的資料以 Prometheus 協議的格式返回，OCP-Server 週期性地拉取資料並進行快取，定期將快取資料寫入資料庫中實現持久化，由此，OCP-Server 實現了 PromQL 查詢表示式的子集，能夠以 PromQL 的語法進行監控資料的聚合計算查詢。

另一方面，OceanBase SQL 的相關資料，由 OCP-Agent 通過推送的方式，將採集到的資料，直接寫入到監控資料庫，而 OCP-Server 端存在定期聚合的邏輯，可以直接查詢到聚合後的資料。

「使用 OCP 需要注意的問題」

OCP 作為一個重要的元件，要長期穩定執行，需要為 OCP 準備好執行環境，包括準備好依賴和做好主機規劃 。

此外，工欲善其事，必先利其器。OCP 對 OceanBase 的運維有特定的依賴和限制，提前瞭解和準備好這些依賴能夠避免 99% 的問題。

更多詳細內容歡迎大家收看  2月17日週四晚 19:30 OceanBase 社群版教程直播第八期： 詳細解讀 ODP&OCP 兩大生態工具。

往期推薦:

攜程DBA負責人俞榕剛：OceanBase在攜程的落地和實踐

2021 OceanBase 年度報告 | 用技術讓海量資料的管理和使用更簡單！

2021 OceanBase 開源半年度報告 | 不忘初心，感恩同行

開源實踐 | OceanBase 在紅象雲騰大資料場景下的實踐與思考

參與更多技術交流，請至 OceanBase 社群版 。