java中的路飛
現在絕大部分軟件項目，都會使用到關係型數據庫，比如MySQL、Oracle、DB2等等，目前這些數據庫的單機性能已經是不斷優化和提高了，但是隨著數據增長的速度和併發訪問量的增加，在某些公司、某些場景下，單機數據庫已經很難滿足業務的需要了，所以必須考慮數據庫集群的方式來提高系統的可用性；最常見的兩種方法：
分庫分表：把數據分散到不同的數據庫上，每臺數據庫中存儲的數據是不相同的（這裡先不考慮每個庫做備份或讀寫分離）；分庫分表既可以分散數據庫訪問的壓力，也可以分散數據存儲的壓力；但是使用分庫分表方案的時候，會帶來擴容、事務、關聯查詢等問題和難點，具體這裡就不展開講了。
讀寫分離：將數據庫讀操作和寫操作分散到不同的節點上，通常是一臺數據庫做寫操作，1到N臺做讀操作；讀寫分離的架構，每一臺數據中的數據是相同的（這裡先忽略延遲的問題），所以只分散了數據庫訪問的壓力，並沒有分散數據存儲的壓力；我們這裡主要講一講讀寫分離。
讀寫分離基本架構
MySQL讀寫分離的基本架構，可以參考下圖：
如上圖，讀寫分離實現的基本步驟是：
數據庫服務器搭建多臺，一主N從（N大於等於1）；
主數據庫只負責寫操作，從數據庫只負責讀操作；
主數據庫複製數據到從數據庫上；
客戶端寫操作路由到主數據庫上，讀操作路由到從數據庫上。
讀寫分離還有另外一種架構，就是在MySQL數據庫和客戶端之間，增加一層中間代理層，客戶端只連接代理， 由代理根據請求類型，把請求分發到不同的數據庫上：
第一種架構，整體架構比較簡單直接，性能會稍微高一些，但是如果才用直連的方式，客戶端可能會稍微麻煩一些（通常需要引入一些組件，負責管理數據庫）；
第二種架構，對客戶端比較友好，因為客戶端只需要和代理交互，並不用關注數據庫的具體信息；但是因為多了一層代理，多多少少會對性能有一定的影響。
讀寫分離帶來的好處
讀寫分離結構中，會有兩臺甚至更多臺數據庫，這種冗餘的設計，可以提高數據的安全性和系統的可用性；就算是在分庫分表的架構中，每一臺子庫，也可以一主多備的部署方式；
讀寫分離更多的時候使用在讀操作遠遠大於寫操作的場景下，這樣可以保證寫操作的數據庫承受更小的壓力，也可以緩解X鎖和S鎖爭用；
服務器數量的增加，意味著可以有效地利用多臺服務器的資源；讀操作被分攤，提高了系統的性能；
如果寫操作比讀操作多，或者相近，可以採用雙主相互複製的架構。
讀寫分離會帶來的問題
之前的文章，我也反覆強調過，任何的架構、軟件、框架、組件...在解決一部分問題的時候，一定會帶來其他的問題；讀寫分離最大的一個問題就是，數據從主複製到從的過程中，可能會存在延遲的，如果客戶端在執行完一個讀操作後，立刻從存庫中查詢的話，可能會讀取到舊數據的情況（我們不斷優化，也只能縮短這個時間，並不能完全消除掉這個時間）。
那麼針對這個問題，有哪些處理方法呢？
根據具體場景進行評估，是否可以接收這個延遲（這好像是一句廢話，但是大多數業務場景，是可以接收這點兒延遲的）；
對於實時性要求很高的場景（查詢的數據必須是最新的結果），將這些請求強制路由到主庫上；
執行完寫操作之後，在讀操作發生之前，讓中間的時間變長（也就是從業務操作角度來做一些控制，不一定操作完了立刻查詢）；
判斷主備無延遲，可以通過判斷seconds_behind_master參數、對比GTID、對比位點等方式，判斷從數據庫是否和主數據庫一致。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
什麼是讀寫分離
讀寫分離指的是在數據庫集群架構中，讓Master處理事務性的查詢，比如增刪改的操作；讓Slave負責查詢的操作。
讀寫分離的好處
從讀的方面來看：我們知道MySQL數據庫有兩種引擎，其中InnoDb和 MyISAM，兩者在查詢性能上MyISAM顯然要比InnoDB要強，但是由於MyISAM不支持事務，所以對於寫操作顯然不太友好，此時如果我們將讀數據的引擎設置為MyISAM，那麼性能又會得到一個提升。
從寫的方面來看：寫的過程中，會由於索引，unique的問題會進行插入前的準備工作，這些操作一方面會損耗性能，另一方面會因為表鎖/行鎖導致數據不可查，那麼查詢請求就會被阻塞，而如果我們將寫請求單獨分配到主數據中，那麼就不會影響查詢操作，兩者並行效率更好
讀寫綜合來看：讀寫分離是以加數據庫為代價消除兩者的弊端，也就是寫由於事務影響了讀，而讀的本身可以更快卻因為寫不得不使用InnoDb引擎。
而且拋開性能，讀寫使用了複製功能，增加冗餘，保證了數據丟失的可能性下降。
使用場景
可以根據自己服務器的配置，業務的複雜性，數據請求數量級去分析：
如果服務器配置一般，那可以採用讀寫分離
如果項目自身業務複雜，可以採用讀寫分離
如果數據請求量很大，可以採用讀寫分離(根據讀多還是寫多，增加主或者從數據庫)
希望我的回答對你有所幫助，謝謝
程序猿開發日記
MySQL讀寫分離本質上是解決因數據庫的讀寫性能差異造成的用戶平臺操作體驗的問題，由於數據庫本身進行寫入操作的性能消耗較大，而讀取數據的性能響應較快，故為提升用戶操作的體驗將數據庫的讀、寫進行分離，而典型MySQL進行讀寫分離的過程中會伴隨著數據庫的主從複製，在主服務器進行修改，數據同步至從服務器上，而從服務器只能進行數據讀取，不能寫入，實現數據備份，同時實現數據庫性能的優化，增加數據的安全性，落地的方案為由MySQL的主服務器負責數據的寫入（增、改、刪），由從服務器負責讀取；
典型實現MySQL讀寫分離的方式分為以下兩種：
1.基於程序代碼內部實現：在代碼中根據select、insert進行路由分類，這類方法也是目前生產環境下應用最廣泛的。優點是性能較好，因為程序在代碼中實現，不需要增加額外的硬件開支，缺點是需要開發人員來實現，運維人員無從下手，可擴展性弱。
2.由中間代理層實現：代理一般介於應用服務器和數據庫服務器之間，代理數據庫服務器接收到應用服務器的請求後根據判斷後，轉發到後端數據庫。
總則：MySQL的讀寫分離能夠一定程度上優化數據庫的性能，對於數據庫查詢多而更新少的情況下可引用讀寫分離的模式，但優化並不是全部僅限於讀寫分離，如：創建索引、配置IO、使用分區查詢、數據結構優化、系統配置優化等。
數通暢聯
類似淘寶網這樣的網站，海量的數據存儲和訪問，數據庫的負載很大，數據操作的成本高，對系統穩定性和擴展性的要求也極高。無論怎樣升級硬件資源，單臺服務器的資源有限，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。
如果將數據庫的讀和寫都放在同一個數據庫服務器中，在安全性、高可用性、高併發等方面，都是完全不能滿足實際場景需求的。MySQL性能優、成本低、資源豐富，使用MySQL讀寫分離，可以解決數據庫寫入影響查詢效率的問題，較大程度地提升系統性能。
本篇知識點綱要
讀寫分離的原理
使用讀寫分離的原因
讀寫分離的適用場景
讀寫分離的原理
讓主數據庫（master）處理事務性增（INSERT）、改（UPDATE）、刪（DELETE）操作，從數據庫（slave）處理SELECT查詢操作。數據庫複製被用來把事務性操作導致的變更同步到集群中的從數據庫。
使用讀寫分離的原因
使用讀寫分離的具體原因包括：
提升查詢性能、節約成本
數據庫為IO寫入，在寫入過程中，通常會涉及唯一性校驗、索引排序等操作，資源消耗大，操作耗時，一次寫操作的響應時間往往是讀操作的幾倍、幾十倍甚至更多。譬如，寫20000條數據到oracle，大概要3-10分鐘，從oracle讀20000條數據，只要幾秒鐘。
緩解X鎖和S鎖爭用
寫操作很多時候需要加鎖，包括表級鎖、行級鎖等，這類鎖都是排他鎖，一個會話佔據排它鎖之後，其他會話是不能讀取數據的，極大影響數據讀取性能。
因此，MySQL部署往往會採用讀寫分離方式，主庫用來寫入數據及部分時效性要求很高的讀操作，從庫用來承接大部分讀操作，這樣數據庫整體性能能夠得到大幅提升。
讀寫分離的適用場景
數據庫不一定都要讀寫分離，讀寫分離適用於“讀遠大於寫”場景，對於讀操作為主的應用，使用讀寫分離將是最好的優化方案，既能讓寫的服務器壓力更小，而讀又可以接受點時間上的延遲。
當然了，數據庫還有其它的優化方案，譬如Memcache、表拆分或搜索引擎等。由於涉及的知識點很多，Mike在這裡也只是拋磚引玉，最後，送大家一套【BAT架構技術專題合集500+】，想要獲取更多關於MySQL的知識詳解，關注並私信回覆【架構師進階】，即可查看。
優知學院
MYSQL讀寫分離可以極大提升性能表現。具體原因包括：
寫操作本身耗費資源
數據庫寫操作為IO寫入，寫入過程中通常會涉及唯一性校驗、建索引、索引排序等操作，對資源消耗比較大。一次寫操作的響應時間往往是讀操作的幾倍甚至幾十倍。
鎖爭用
寫操作很多時候需要加鎖，包括表級鎖、行級鎖等，這類鎖都是排他鎖，一個會話佔據排它鎖之後，其他會話是不能讀取數據的，這會會極大影響數據讀取性能。
所以MYSQL部署往往會採用讀寫分離方式，主庫用來寫入數據及部分時效性要求很高的讀操作，從庫用來承接大部分讀操作，這樣數據庫整體性能能夠得到大幅提升。
魚飛飛
多寫分離，是為了處理大數據而誕生的，如果你做的是小項目，那麼這些東西是感覺不到的，如果你做的是百萬級甚至千萬級的數據量的話，那麼多分離是很有必要的，如果這麼大的數據量同時讀圖是血的話，數據庫的負擔是很重的，那麼讀寫分離之後呢，主要負責讀那個附表那個支付的取了這樣的話，分開寫作，大大減輕了數據庫的運行負擔
