對於每個用戶不一樣的那些數據來說，緩存的命中率就沒有那麼高，還是有相當一部分查詢請求因爲命中不了緩存，打到 MySQL 上。隨着系統用戶數量越來越多，打到 MySQL 上的讀寫請求也越來越多，當單臺 MySQL 支撐不了這麼多的併發請求時，讀寫分離是提升 MySQL 併發的首選方案。
對於很多系統，數據庫需要應對的絕大部分請求都是隻讀查詢請求。
一個分佈式的存儲系統，想要做分佈式寫是非常非常困難的，因爲很難解決好數據一致性的問題。但實現分佈式讀就相對簡單很多，保證這這些只讀實例上的數據都隨時一樣，這些只讀的實例就可以分擔大量的查詢請求。
實施 MySQL 的讀寫分離方案。需要做兩件事兒：
1.部署一主多從多個 MySQL 實例，並讓它們之間保持數據實時同步。
2.分離應用程序對數據庫的讀寫請求，分別發送給從庫和主庫。
MySQL 自帶主從同步的功能，經過簡單的配置就可以實現一個主庫和幾個從庫之間的數據同步，部署和配置的方法，看MySQL 的官方文檔照着做就可以。
分離應用程序的讀寫請求方法有下面這三種：
純手工方式：修改應用程序的 DAO 層代碼，定義讀寫兩個數據源，指定每一個數據庫請求的數據源。
組件方式：也可以使用像 Sharding-JDBC 這種集成在應用中的第三方組件來實現，這些組件集成在你的應用程序內，代理應用程序的所有數據庫請求，自動把請求路由到對應數據庫實例上。
代理方式：在應用程序和數據庫實例之間部署一組數據庫代理實例，比如說 Atlas 或者 MaxScale。對應用程序來說，數據庫代理把自己僞裝成一個單節點的 MySQL 實例，應用程序的所有數據庫請求被髮送給代理，代理分離讀寫請求，然後轉發給對應的數據庫實例。
如果配置了多個從庫，推薦使用“HAProxy+Keepalived”這對經典的組合，來給所有的從節點做一個高可用負載均衡方案，既可以避免某個從節點宕機導致業務可用率降低，也方便後續隨時擴容從庫的實例數量。因爲 HAProxy 可以做 L4 層代理，也就是說它轉發的是 TCP 請求，所以用“HAProxy+Keepalived”代理 MySQL 請求。
注意讀寫分離帶來的數據不一致問題
對於這種主從延遲帶來的數據不一致的問題，沒有什麼簡單方便而且通用的技術方案可以解決，我們需要重新設計業務邏輯，儘量規避更新數據後立即去從庫查詢剛剛更新的數據。