Oracle實踐需要解決哪些問題

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

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

為了解答這個問題，首先我們要理解去 Oracle 架構(gòu)改造的本質(zhì)是什么？去 Oracle 架構(gòu)改造的本質(zhì)其一是讓系統(tǒng)架構(gòu)具備在線更換數(shù)據(jù)庫的能力，無論去 Oracle 的目標庫是 MySQL，或是其他的關(guān)系型數(shù)據(jù)庫，最終都是要解決這樣一個問題。

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

1. 如何無感知的實時動態(tài)數(shù)據(jù)的遷移？

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

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

2. 如何管理和協(xié)調(diào)好高頻迭代的去 Oracle 改造和功能改造？

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

3. 如何穩(wěn)妥落地數(shù)據(jù)庫流量的在線切換？

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

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

4. 如何有效拆分去Oracle 的任務(wù)？

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

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

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

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

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

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

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

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

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