本套技術專欄是作者（秦凱新）平時工作的總結和昇華，並深度整理大量網上資源和專業書籍。通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。QQ郵箱地址：1120746959@qq.com，如有任何學術交流，可隨時聯絡。
1 MySQL 讀寫分離機制
-
單庫最高承受的讀寫能力一般上限為2000/s
-
mysql的讀寫分離就是根據業務場景設計一個主庫，掛多個從庫，然後我們就單單只是寫主庫，然後主庫會自動把資料給同步到從庫，這樣將一個主庫拆分為4個主庫，每個主庫的寫併發就500/s，此時主從延遲可以忽略不計。
1.1 MySQL核心主從同步原理
- 主庫將變更寫binlog日誌，然後從庫連線到主庫之後，從庫有一個IO執行緒，將主庫的binlog日誌拷貝到自己本地，寫入一箇中繼日誌（RelayLog）中。接著從庫中有一個SQL執行緒會從中繼日誌（RelayLog）讀取binlog，然後執行binlog日誌中的內容，也就是在自己本地再次執行一遍SQL，這樣就可以保證自己跟主庫的資料是一樣的。
1.2 主從複製可能存在的問題
-
用了mysql主從架構之後，可能會發現，因為延時問題剛寫入庫的資料結果沒查到。
-
從庫同步主庫資料的過程是序列化的，也就是說主庫上並行的操作，在從庫上會序列執行。所以這就是一個非常重要的點了，由於從庫從主庫拷貝日誌以及序列執行SQL的特點，在高併發場景下，從庫的資料一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的資料可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。
-
如果主庫突然當機，然後恰好資料還沒同步到從庫，那麼有些資料可能在從庫上是沒有的，有些資料可能就丟失了。
1.3 MySQL 主從同步機制
- 半同步複製(semi-sync複製) --> 用來解決主庫資料丟失問題,主庫寫入binlog日誌之後，就會將強制此時立即將資料同步到從庫，從庫將日誌寫入自己本地的relay log之後，接著會返回一個ack給主庫，主庫接收到至少一個從庫的ack之後才會認為寫操作完成了。
- 並行複製 --> 指的是從庫開啟多個執行緒，並行讀取relay log中不同庫的日誌，然後並行重放不同庫的日誌，這是庫級別的並行。
1.4 使用場景
- 一般在讀遠遠多於寫，而且讀的時候一般對資料時效性要求沒那麼高的時候，用mysql主從同步。
2 主從延遲嚴重時處理思路
- 分庫，將一個主庫拆分為成多個主庫，此時主從延遲可以忽略不計
- 開啟mysql支援的並行複製，多個庫並行複製，如果說某個庫的寫入併發就是特別高，單庫寫併發達到了2000/s，並行複製沒意義。
- 重寫程式碼，寫程式碼要慎重，，插入資料之後，直接就更新，不要查詢
- 如果確實是存在必須先插入，立馬要求就查詢到，然後立馬就要反過來執行一些操作，對這個查詢設定直連主庫。不推薦這種方法，你這麼搞導致讀寫分離的意義就喪失了。
3 總結
在此感謝石杉的講義，結合大資料在我們工業大資料平臺的實踐，總結成一篇實踐指南，方便以後查閱反思，後續我會根據本篇部落格進行程式碼技術實踐實現。
凱新雲技術社群