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