MySQL讀寫分離有哪些坑？

讀寫分離有哪些坑？

讀寫分離的主要目標就是分攤主庫的壓力。

一種架構是客戶端（client）主動做負載均衡，這種模式下一般會把資料庫的連線資訊放在客戶端的連線層。也就是說，由客戶端來選擇後端資料庫進行查詢。

一種架構是，在 mysql 和客戶端之間有乙個中間**層 proxy，客戶端只連線 proxy，由 proxy 根據請求型別和上下文決定請求的分發路由。

客戶端直連和帶 proxy 的讀寫分離架構，各有哪些特點：

客戶端直連方案，因為少了一層 proxy **，所以查詢效能稍微好一點兒，並且整體架構簡單，排查問題更方便。但是這種方案，由於要了解後端部署細節，所以在出現主備切換、庫遷移等操作的時候，客戶端都會感知到，並且需要調整資料庫連線資訊。

你可能會覺得這樣客戶端也太麻煩了，資訊大量冗餘，架構很醜。其實也未必，一般採用這樣的架構，一定會伴隨乙個負責管理後端的元件，比如 zookeeper，盡量讓業務端只專注於業務邏輯開發。

帶 proxy 的架構，對客戶端比較友好。客戶端不需要關注後端細節，連線維護、後端資訊維護等工作，都是由 proxy 完成的。但這樣的話，對後端維護團隊的要求會更高。而且，proxy 也需要有高可用架構。因此，帶 proxy 架構的整體就相對比較複雜。

由於主從可能存在延遲，客戶端執行完乙個更新事務後馬上發起查詢，如果查詢選擇的是從庫的話，就有可能讀到剛剛的事務更新之前的狀態。

處理過期讀的方案：

強制走主庫方案；

sleep 方案；

判斷主備無延遲方案；

配合 semi-sync 方案；

等主庫位點方案；

等 gtid 方案。