Oracle實踐需要解決哪些問題

Oracle實踐需要解決哪些問題，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

“去 Oracle”一直是最近 10 年描述系統架構改造中最常出現的詞之一。雖然“去 Oracle”被很多工程師和技術從業者津津樂道，但業界真正能實現把系統全部去Oracle，特別是金融場景的核心系統全部去 Oracle 的案例并不多。那么去Oracle到底難在哪里呢。

為了解答這個問題，首先我們要理解去 Oracle 架構改造的本質是什么？去 Oracle 架構改造的本質其一是讓系統架構具備在線更換數據庫的能力，無論去 Oracle 的目標庫是 MySQL，或是其他的關系型數據庫，最終都是要解決這樣一個問題。

在線更換數據庫到底難在哪里，會遇到哪些問題呢？

1. 如何無感知的實時動態數據的遷移？

首先數據庫作為交易型系統最核心的組件沒有之一，這一點對于數據庫的重要性評價一點都不夸張。當前大部分知名的網站和系統都是 7x24 小時對外提供服務，數據庫也是 7*24 小時無時不刻處理著大量的讀寫服務，要實現去Oracle 就意味著你要在一個 Oracle 庫還在對外提供服務的時候，在某個時間點讓一個 MySQL 庫快速替換掉 Oracle 庫，并平穩的接管 Oracle 的所有服務。

不同于無狀態的系統組件切換把流量切走即完成切換工作，而數據庫作為有狀態的系統組件，如何設計一套從應用改造、到數據同步、再到數據庫流量切換的穩妥去 Oracle 方案，可以非常謹慎的把一個正在對外提供服務，數據處在實時變化狀態的 Oracle 庫上的數據無縫的方式遷移至 MySQL 中。

2. 如何管理和協調好高頻迭代的去 Oracle 改造和功能改造？

其次去Oracle 架構改造的主體工作是對應用層代碼的重構，特別對 DAO（數據訪問層）的重構，對于某些復雜的系統來說，重構的時間會持續數月甚至更久。在這段漫長的去Oracle 改造時間窗口里，不但 Oracle 庫的數據在動態發生變化，對于一個處在高速迭代中的網站和系統來說，應用的功能代碼也在不斷發生變化。如果 A 團隊在為應用做去 Oracle架構改造，而這個期間 B 團隊在不斷的給應用開發新的功能，如何進行去 Oracle 的工作拆分可以有效的管理和協調好兩個開發團隊的編碼和上線節奏呢。

3. 如何穩妥落地數據庫流量的在線切換？

當某個庫的應用去Oracle 改造完成并上線后，會實施生產環境 Oracle 的流量切換到 MySQL 上。在這個切換過程中，如何確保 Oracle 上的最后一筆事務提交成功，并同步到 MySQL 后完成數據一致性校驗，且針對這個 Oracle 庫的所有寫操作能在快速、全部切換到 MySQL 上，不會出現部分寫流量 Oracle，部分寫流量 MySQL，兩庫雙寫的異常狀態。

當流量切換到 MySQL 后 a，如果出現應用報錯或 bug、MySQL 性能問題等在前期壓測或準備工作中未覆蓋到的突發情況，如何實現流量快速回切到 Oracle 上，且確保在 MySQL 中寫入的數據也能完全一致的回到 Oracle 中。

4. 如何有效拆分去Oracle 的任務？

要實現全站去 Oracle，必然面臨著對一些復雜、龐大的核心系統進行去 Oracle 改造。以陸金所為例，在全站中像用戶中心、資產中心、資金賬戶等這種給全站所有金融產品線都提供基礎服務的子系統就是這類復雜和龐大的核心系統，同時包括基金、主賬戶等專屬金融產品線的業務邏輯復雜，所以子系統也非常龐大。

所以對于這類子系統，如果需要在一個大版本里全部去 Oracle 改造完成，并在一個晚上業務低峰期一次性全部從 Oracle 切換到 M，無論是當晚的切換風險，還是切換完成后，在第二天業務高峰期出現問題和 bug 的風險，包括開發團隊短時間內去 Oracle 改造的工作量和出現重大 bug 的機率都是非常大且不可控的。

如何把一個龐大且重要的復雜子系統拆分成多個去 Oracle 的版本按批次上線和切換流量，且做到單個批次影響可控，也是全站去 Oracle 中需要謹慎設計的方案。

上面提到了去 Oracle中在架構層實現在線換庫需要解決的四大問題。除了在線換庫外，去 Oracle 架構改造的本質其二是引入更多的存儲引擎在合適的場景來承接 Oracle 數據庫的計算和存儲能力。這就引出了第五個問題。

5. 如何使用合適的開源存儲引擎去Oracle，并在架構上進行融合

首先 Oracle 是個非常強大的關系型數據庫，無論在 OLTP 和 OLAP 場景表現都很出色，且具備一整套完善、好用的運維和監控工具。但于此同時 Oracle 雖然對各種場景支持較為全面，但在各個特定場景下，一些開源的數據庫或存儲引擎在性能或成本投入的綜合考量上勝過 Oracle，都會是比 Oracle 更合適的選擇方案。

所以全站去 Oracle 不僅僅是去 Oracle 到 MySQL 中，MySQL 能承接的只是 Oracle 的部分計算和存儲能力，在整個陸金所的全站去 Oracle 落地過程中，除了 MySQL 外，我們還在不同的場景下使用 ES、HBase、TiDB、Impala+kudu 等存儲引擎，甚至是應用層的代碼來承接和替換 Oracle，并且整體收益比使用 Oracle 更好。

上述是陸金所在全站去 Oracle 過程中遇到的 5 個實戰問題大類，整個全站去 O 過程中需要解決細節問題還有很多，這里無法一一列舉，因為去 Oracle 作為一個復雜的系統架構改造本身就要求技術團隊事無巨細的處理好各種細節問題。

關于Oracle實踐需要解決哪些問題問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。