（先對數據庫操作進行讀寫分離，使得具有master角色的主服務器主要用於執行寫操作，這樣就能大大減少主服務器由於讀操作而產生的負載過大的問題。讀交給slave。對於多臺讀服務器，還要把讀操作的壓力分攤到不同的slave服務器上。通常來說，讀寫分離和多臺slave服務器的讀負載均衡也是兩個不同的問題，也要分別進行解決。先讀寫分離，再將讀操作平均分攤到各slave服務器）
redis和memcache差距不大，還具有更多的數據類型，還能持久化，主從複製，集羣等功能
（比如庫存的查詢就必須在主庫上進行，如果從庫上就可能出現超賣的情況。因此，不是什麼查詢都要進行讀寫分離的。所以，由開發人員自行判斷比較靈活）
還可以通過數據庫中間層完成讀寫分離（如mysql proxy、maxscale、one proxy、proxySQL等）：
（通過中間層對sql語句的解析，如果是select操作，則發送到從服務器處理，非select操作，全發送到主服務器處理。對於存儲過程這種無法通過調用語法分析出是讀操作還是寫操作的sql就只能全部由主數據庫服務器去完成。由於存儲過程可能很大一部分只是進行查詢處理，這無疑加大了主數據庫服務器的負載。雖然使用中間層很方便，但也會付出一些代價）
（由於讀寫分離是通過中間層自動進行的，而中間層無法區分哪些是對延遲敏感的，哪些不敏感，所以無法把對延遲敏感的查詢自動分配到主庫上執行，而要實現這些功能就要在查詢語句中加入提示的關鍵字，而增加提示不得不對原來程序進行修改，這樣就失去了對程序透明的好處了）
常用的讀服務器負載均衡方式：
對於數據庫服務器來說，讀負載和寫負載是兩個完全不同的問題，所以，對於讀負載和寫負載要分開對待，因爲寫操作只能在master上進行，而讀操作可以在master上，也可以在slave上，因此，相對寫負載，解決讀負載更加容易。
（lvs是工作在網絡協議的四層上的，只進行流量分發，不會對數據包內容進行解析，性能強，對內存和cpu消耗低，當然，由於不會對數據進行解析，所以也不會知道數據包中sql的具體內容，自然不能做讀寫分離）
(lvs只分發請求，流量並不從他本身出去，所以無流量消耗，這點就保障了io性能不會受到大流量影響)
主從複製流程就不貼出來了...
在.100和.101服務器都安裝lvs管理工具：
加載ipvs模塊（所有參加lvs集羣的三臺服務器都要安裝）：
lvs腳本的編寫：
先看下slave（.101服務器）上的腳本：
（注意，這個腳本要有可執行權限）
執行腳本：
查看：
同樣在.102上也要執行：
查看：
.100上的keepalived配置：
查看check_slave腳本：
......
.100上建立lvs可操作的賬號：
未完待續......