[轉]Oracle讀寫分離架構

From : http://www.easyora.net/blog/oracle_read_write_separated_architecture.html

       讀寫分離是架構分布式系統的一個重要思想。不少系統整體處理能力並不能同業務的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬體並不能一勞永逸。針對業務類型特點，需要從架構模式上進行一系列的調整，比如業務模組的分割，資料庫的拆分等等。

       集中式和分布式是兩個對立的模式，不同行業的應用特點也決定了架構的思路。如互連網行業中一些門戶網站，出於技術和成本等方面考慮，更多的採用開源的資料庫產品(如MYSQL)，由於大部分是典型的讀多寫少的請求，因此為MYSQL及其複製技術大行其道提供了條件。而相對一些傳統密集交易型的行業，比如電信業、金融業等，考慮到單點處理能力和可靠性、穩定性等問題，可能更多的採用商用資料庫，比如DB2、Oracle等。

       就資料庫層面來講，大部分傳統行業核心庫採用集中式的架構思路，採用高配的小型機做主機載體，因為資料庫本身和主機強大的處理能力，資料庫端一般能支撐業務的運轉，因此，Oracle讀寫分離式的架構相對MYSQL來講，相對會少。

       前段時間一直在規劃公司新的資料庫結構描述，考慮到我們的業務特點，採用Oracle讀寫分離的思路，Writer DB和Reader  DB採用日誌複製軟體實現即時同步； Writer DB負責交易相關的即時查詢和交易處理，Reader DB負責唯讀接入，處理一些非即時的交易明細,報表類的匯總查詢等。同時，為了滿足高可用性和擴充性等要求，對讀寫端適當做外延，比如Writer DB採用HA或者RAC的架構模式，Reader DB可以採用多套，通過負載平衡或者業務分離的方式，有效分擔讀庫的壓力。

       對於Shared-nothing的資料庫結構描述模式，核心的一個問題就是讀寫庫的即時同步；另外，雖然Reader  DB只負責業務查詢，但並不代表資料庫在功能上是唯讀。唯讀是從應用角度出發，為了保證資料一致和衝突考慮，因為查詢業務模組可能需要涉及一些中間處理，如果需要在資料庫裡面處理(取決與應用需求和設計)，所以Reader  DB在功能上仍然需要可寫。

 

 

       下面談一下資料同步的技術選型問題：

       能實現資料即時同步的技術很多，基於OS層(例如VERITAS VVR)，基於儲存複製(中高端儲存大多都支援)，基於應用分發或者基於資料庫層的技術。因為資料同步可能並不是單一的DB整庫同步，會涉及到業務資料選擇以及多源整合等問題，因此OS複製和儲存複製多數情況並不適合做讀寫分離的技術首選。

       基於日誌的Oracle複製技術，Oracle自身組件可以實現，同時也有成熟的商業軟體。選商業的獨立產品還是Oracle自身的組件功能，這取決於多方面的因素。比如團隊的相應技術營運能力、項目投入成本、業務系統的負載程度等。

      採用Oracle自身組件功能，無外乎Logical Standby、Stream以及11g的Physical Standby(Active Data Guard)，對比來說，Stream最靈活，但最不穩定，11g Physical Standby支援恢複與唯讀並行，但由於並不是日誌的邏輯應用程式機制，在讀寫分離的情境中最為局限。如果技術團隊對相關技術掌握足夠充分，而選型方案的處理能力又能支撐資料同步的要求，採用Oracle自身的組件完全可行。

     選擇商業化的產品，更多出於穩定性、處理能力等考慮。市面上成熟的Oracle複製軟體也無外乎幾種，無論是老牌的Shareplex，還是本土DSG公司的RealSync和九橋公司的DDS，或是Oracle新貴Goldengate，都是可供選擇的目標。隨著GoldenGate被Oracle收購和推廣，個人認為GoldenGate在容災、資料分發和同步方面將大行其道。

      當然，架構好一個可靠的分布式讀寫分離的系統，還需要應用上做大量設計，不在本文討論範圍內。