Mysql的讀寫分離可以使用MySQL Proxy和Amoeba實作，其實也可以使用MySQL-MMM實作讀寫分離的自動切換。MySQL Proxy有一項強大功能是實作"讀寫分離"，基本原理是讓主資料庫處理寫方面事務，讓從庫處理SELECT查詢；Amoeba for MySQL是一款優秀的中間件軟體，同樣可以實作讀寫分離，負載均衡等功能。下面重點說下Mysql Proxy:
Mysql Proxy的原理圖
順便貼下Mysql Proxy的工作拓撲圖
部署MySQL Proxy實作讀寫分離并提高并發負載的操作記錄
0）機器環境
1）Mysql主從複制部署（在三台mysql節點機上部署，本案例是一主兩從架構）
2）在proxy機器上安裝mysql-proxy
3）讀寫分離測試
讀寫分離，延遲是個大問題，要確定主從同步這一環節不要有延遲。
---------------mysql主從同步延遲原理----------------
－> mysql主從同步原理
主庫針對讀寫操作，順序寫 binlog，從庫單線程去主庫讀"寫操作的binlog",從庫取到 binlog在本地原樣執行(随機寫),來保證主從資料邏輯上一緻.
mysql的主從複制都是單線程的操作，主庫對所有DDL和DML産生 binlog，binlog是順序寫，是以效率很高，slave的Slave_IO_Running線程到主庫取日志，效率比較高，下一步問題來了，slave的 slave_sql_running線程将主庫的 DDL和DML操作在 slave實施。DML，DDL的IO操作是随即的，不能順序的，成本高很多，還有可能slave上的其他查詢産生 lock，由于 slave_sql_running也是單線程的，是以 一個 DDL卡住了，需求需求執行一段時間，那麼所有之後的DDL會等待這個 DDL執行完才會繼續執行，這就導緻了延遲.由于master可以并發，Slave_sql_running線程卻不可以，是以主庫執行 DDL需求一段時間，在slave執行相同的DDL時，就産生了延遲.
-> 主從同步延遲産生原因
當主庫的TPS并發較高時，産生的DDL數量超過Slave一個 sql線程所能承受的範圍，那麼延遲就産生了，當然還有就是可能與 slave的大型 query語句産生了鎖等待
首要原因：資料庫在業務上讀寫壓力太大，CPU計算負荷大，網卡負荷大，硬碟随機IO太高
次要原因：讀寫 binlog帶來的性能影響，網絡傳輸延遲
-> mysql主從同步加速
1）sync_binlog在slave端設定為0
2）–logs-slave-updates 從伺服器從主伺服器接收到的更新不記入它的二進制日志。
3）直接禁用slave端的binlog
4）slave端，如果使用的存儲引擎是innodb，innodb_flush_log_at_trx_commit =2
再有就是進行分庫分表處理，這樣減少資料量的複制同步操作
本文轉自散盡浮華部落格園部落格，原文連結：http://www.cnblogs.com/kevingrace/p/6931303.html，如需轉載請自行聯系原作者