MySQL讀寫分離

讀寫分離指的是，通過增加一些節點，擴展讀的能力。這些節點可以是主節點的全部內容的副本或者部分內容的副本，也可以是緩存產品。讀寫分離一般配合負載均衡產品使用。

對於讀多寫少（非更新查詢為主）的負載，特別適合做讀寫分離。你需要留意的是，保證用戶感知到自己所做的變更生效即可，用戶很多情況下並不需要知道其他用戶的改變。如果用戶對於數據的一致性要求在某個時刻高，那麼這部分數據，建議不要使用讀寫分離，MySQL的複製可能出現延時，無法滿足業務需要。你可以採取變通的方式，比如，在用戶修改了內容後，臨時強制用戶訪問主節點，以獲取一致性的數據，在過一段時間後，再讓用戶訪問副本的數據，一般在此時，副本的數據已經同步到最新狀態了。

讀寫分離往往和負載均衡技術配合使用。負載均衡軟硬體產品有F5、Haproxy以及一些自己設計的MySQL Proxy代理等，負載均衡可以更高效的利用硬體，你可以設置權重，分配更多的流量給性能更好的機器，負載均衡產品一般還有故障檢測、自動冗餘切換功能，這可以大大提高你的可用性。

讀寫分離技術的一個難點在於延時的影響，你需要有一個手段確保你沒有讀取到太舊的數據，寫操作和一些不能容忍延時的查詢，需要指向主庫。對於數據延時敏感度不高的數據，你需要定義延時的閾值，通過自動或者手工的方式處理延時數據對於用戶體體驗的影響。n

你可以通過監控SHOW SLAVE STATUS里的輸出Seconds_behind_master的方式判斷是否有延時，但這種方式不太可靠。監控複製滯後（replication lag）的更穩健的方式是通過心跳錶的方式。

我們很難確保MySQL的延時，因為網路波動、複製異常、性能問題都可能導致複製中斷，而往往需要人工來進行干預，畢竟有能力開發專用的Proxy代理的公司很少，所以，不建議使用讀寫分離，採用讀寫分離是基於一個前提，主庫已經出現讀瓶頸，如果出現讀瓶頸，使用緩存一般是更有效、更成熟的解決方案。

讀寫分離，又往往和拆分數據有關聯。部分數據更適合讀寫分離，部分數據更適合拆分。對於一致性要求很高的數據，往往很難以去拆分，使用讀寫分離保證適當的用戶體驗更可取。 如果一定要拆分，很可能導致架構、運維異常複雜。 在做數據架構的時候，要清楚數據的用戶，細分各種數據，針對各種數據，進行各種處理，確保異常情況下的可用、可恢復，而不是簡單的考慮 讀寫分離、水平擴展、垂直擴展這些更簡單的分解。

推薦閱讀：