隨着一個網站的業務不斷擴展，數據不斷增加，數據庫的壓力也會越來越大，對數據庫或者SQL的基本優化可能達不到最終的效果，我們可以采用讀寫分離的策 略來改變現狀。讀寫分離現在被大量應用於很多大型網站，這個技術也不足為奇了。ebay就做得非常好。ebay用的是oracle，聽說是用Quest Share Plex 來實現主從復制數據。
讀寫分離簡單的說是把對數據庫讀和寫的操作分開對應不同的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操作，從數據庫提 供讀操作，其實在很多系統中，主要是讀的操作。當主數據庫進行寫操作時，數據要同步到從的數據庫，這樣才能有效保證數據庫完整性。Quest SharePlex就是比較牛的同步數據工具，聽說比oracle本身的流復制還好，MySQL也有自己的同步數據技術。mysql只要是通過二進制日志來復制數據。通過日志在從數據庫重復主數據庫的操作達到復制數據目的。這個復制比較好的就是通過異步方法，把數據同步到從數據庫。
主數據庫同步到從數據庫后，從數據庫一般由多台數據庫組成這樣才能達到減輕壓力的目的。讀的操作怎么樣分配到從數據庫上？應該根據服務器的壓力把讀的操作分配到服務器，而不是簡單的隨機分配。mysql提供了MySQL-Proxy實現讀寫分離操作。不過MySQL-Proxy好像很久不更新了。oracle可以通過F5有效分配讀從數據庫的壓力。
上面說的數據庫同步復制，都是在從同一種數據庫中，如果我要把oracle的數據同步到mysql中，其實要實現這種方案的理由很簡單，mysql免費，oracle太貴。好像Quest SharePlex也實現不了改功能吧。好像現在市面還沒有這個工具吧。那樣應該怎么實現數據同步？其實我們可以考慮自己開發一套同步數據組件，通過消息，實現異步復制數據。其實這個實現起來要考慮很多方面問題，高並發的問題，失敗記錄等。其實這種方法也可以同步數據到memcache中。聽說oracle的Stream也能實現，不過沒有試過。
讀寫分離，基本的原理是讓主數據庫處理事務性增、改、刪操作（INSERT、UPDATE、DELETE），而從數據庫處理SELECT查詢操作。數據庫復制被用來把事務性操作導致的變更同步到集群中的從數據庫。
為什么要分庫、分表、讀寫分？
單表的數據量限制，當單表數據量到一定條數之后數據庫性能會顯著下降。數據多了之后，對數據庫的讀、寫就會很多。分庫減少單台數據庫的壓力。接觸過幾個分庫分表的系統，都是通過主鍵進行散列分褲分表的。這類數據比較特殊，主鍵就是唯一的獲取該條信息的主要途徑。比如：京東的訂單、財付通的交易記錄等。。。該類數據的用法，就是通過訂單號、交易號來查詢該筆訂單、交易。
還有一類數據，比如用戶信息，每個用戶都有系統內部的一個userid，與userid對應的還有用戶看到的登錄名。那么如果分庫分表的時候單純通過userid進行散列分庫，那么根據登錄名來獲取用戶的信息，就無法知道該用戶處於哪個數據庫中。
或許有朋友會說，我們可以維護一個email----userid的映射關系，根據email先查詢到userid，在根據userid的分庫分表規則到對應庫的對應表來獲取用戶的記錄信息。這么做是可以的，但是這個映射關系的條數本身也是個瓶頸，原則上是沒有減少單表內數據的條數，算是一個單點。並且要維護這個映射關系和用戶信息的一致性（修改登錄名、多登錄名等其他特殊需求），最大一個原因，其實用戶信息是一個讀大於寫的庫，web2.0都是以用戶為中心，所有信息都和用戶信息相關聯，所以對用戶信息拆分還是有一定局限性的。
對於這類讀大於寫並且數據量增加不是很明顯的數據庫，推薦采用讀寫分離+緩存的模式，試想一下一個用戶注冊、修改用戶信息、記錄用戶登錄時間、記錄用戶登錄IP、修改登錄密碼，這些是寫操作。但是以上這些操作次數都是很小的，所以整個數據庫的寫壓力是很小的。唯一一個比較大的就是記錄用戶登錄時間、記錄用戶登錄IP這類信息，只要把這些經常變動的信息排除在外，那么寫操作可以忽略不計。所以讀寫分離首要解決的就是經常變化的數據的拆分，比如：用戶登錄時間、記錄用戶登錄IP。這類信息可以單獨獨立出來，記錄在持久化類的緩存中（可靠性要求並不高，登陸時間、IP丟了就丟了，下次來了就又來了）
以oracle為例，主庫負責寫數據、讀數據。讀庫僅負責讀數據。每次有寫庫操作，同步更新cache，每次讀取先讀cache在讀DB。寫庫就一個，讀庫可以有多個，采用dataguard來負責主庫和多個讀庫的數據同步。
