讀寫分離是架構分佈式系統的一個重要思想。不少系統整體處理能力並不能同業務的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬件並不能一勞永逸。針對業務類型特點，需要從架構模式上進行一系列的調整，比如業務模塊的分割，數據庫的拆分等等。
集中式和分佈式是兩個對立的模式，不同行業的應用特點也決定了架構的思路。如互聯網行業中一些門戶站點，出於技術和成本等方面考慮，更多的採用開源的數據庫產品(如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在容災、數據分發和同步方面將大行其道。
當然，架構好一個可靠的分佈式讀寫分離的系統，還需要應用上做大量設計，不在本文討論範圍內。
