前 言

訂單緩存方案上線之后，我們以為又開啟了歲月安好的日子，但是，在一周后的某一天，DBA直接跑來了，DBA直接說：“leader讓我直接找你，是這樣的，上次加了緩存優化后，效果確實不錯，但是我發現訂單查詢sql在今天的12:00至12:05之間有大量的慢sql，查詢時間超過了2.5s。”

這個時候，我們立馬開啟了排查問題模式，首先，check了一下上次加的緩存，發現緩存正常，然后接著根據DBA提供的信息搜索日志，此時，發現在這個時間段訂單請求量突增，大概是平常訂單請求量的2到3倍，然后經過了解，發現在這個時間段內，營銷系統那邊做了一些活動，導致訂單請求量突增。

說白了就是做了促銷活動后，大量下單的用戶會不斷刷新訂單來查詢訂單的信息，比如看一下訂單是否開始配送，此時大量的請求會打到了MySQL上去，此時單庫又抗不了這么讀請求，就導致了數據庫負載很高，從而嚴重降低了MySQL的查詢效率。

現在我們緩存也加過了，但是數據庫負載還是很高，此時該怎么辦呢？

其實也很簡單，既然單個庫扛不住，那就搞2個庫一起來抗唄，因為對于外賣訂單來說是典型的讀多寫少的場景，所以，在這個場景下，我們可以搞個一主兩從的架構來進行優化，就像這樣：

也就是寫數據走主庫，而讀數據走從庫，可以看到，此時由于我們搞了2個從庫，這2個從庫可以一起來抗大量的讀請求。

非常關鍵的一點就是，從庫會通過主從復制，從主庫中不斷的同步數據，以此來保證從庫的數據和主庫是一模一樣的，所以想要實現讀寫分離，那么，就先要了解主從復制是怎么玩兒的。

主從復制的原理是什么？

我們以mysql一主兩從架構為例，也就是一個master節點下有兩個slave節點，在這套架構下，寫請求統一交給master節點處理，而讀請求交給slave節點處理。

為了保證slave節點和master節點的數據一致性，master節點在寫入數據之后，同時會把數據復制一份到自己的各個slave節點上。

在復制的過程中一共會使用到三個線程，一個是binlog dump線程，位于master節點上，另外兩個線程分別是I/O線程和SQL線程，它們都分別位于slave節點上，如下圖：

結合圖片，我們一起來看下主從復制的核心流程：

（1）當master節點接收到一個寫請求時，這個寫請求可能是增刪改操作，此時會把寫請求的操作都記錄到binlog日志中。

（2）master節點會把數據復制給slave節點，如圖中的slave01節點和slave02節點，這個過程，首先得要每個slave節點連接到master節點上，當slave節點連接到master節點上時，master節點會為每一個slave節點分別創建一個binlog dump線程，用于向各個slave節點發送binlog日志。

（3）binlog dump線程會讀取master節點上的binlog日志，然后將binlog日志發送給slave節點上的I/O線程。

（4）slave節點上的I/O線程接收到binlog日志后，會將binlog日志先寫入到本地的relaylog中，relaylog中就保存了binlog日志。

（5）slave節點上的SQL線程，會來讀取relaylog中的binlog日志，將其解析成具體的增刪改操作，把這些在master節點上進行過的操作，重新在slave節點上也重做一遍，達到數據還原的效果，這樣就可以保證master節點和slave節點的數據一致性了。

主從復制的有幾種模式？

mysql的主從復制，分為全同步復制、異步復制、半同步復制和增強半同步復制 這四種。

全同步復制

首先，全同步復制，就是當主庫執行完一個事務之后，要求所有的從庫也都必須執行完該事務，才可以返回處理結果給客戶端；因此，雖然全同步復制數據一致性得到保證了，但是主庫完成一個事物需要等待所有從庫也完成，性能就比較低了。

異步復制

而異步復制，當主庫提交事物后，會通知binlog dump線程發送binlog日志給從庫，一旦binlog dump線程將binlog日志發送給從庫之后，不需要等到從庫也同步完成事務，主庫就會將處理結果返回給客戶端。

因為主庫只管自己執行完事務，就可以將處理結果返回給客戶端，而不用關心從庫是否執行完事務，這就可能導致短暫的主從數據不一致的問題了，比如剛在主庫插入的新數據，如果馬上在從庫查詢，就可能查詢不到。

而且，當主庫提交事物后，如果宕機掛掉了，此時可能binlog還沒來得及同步給從庫，這時候如果為了恢復故障切換主從節點的話，就會出現數據丟失的問題，所以異步復制雖然性能高，但數據一致性上是較弱的。

mysql主從復制，默認采用的就是異步復制這種復制策略。

半同步復制

半同步復制，顧名思義就是在同步和異步中做了折中選擇，我們可以結合著MySQL官網來看下是半同步主從復制的過程，來看下這樣圖：

當主庫提交事務后，至少還需要一個從庫返回接受到binlog日志，并成功寫入到relaylog的消息，這個時候，主庫才會將處理結果返回給客戶端。

相比前2種復制方式，半同步復制較好地兼顧了數據一致性以及性能損耗的問題。

同時，半同步復制也存在以下幾個問題：

• 半同步復制的性能，相比異步復制而言有所下降，相比于異步復制是不需要等待任何從庫是否接收到數據的響應，而半同步復制則需要等待至少一個從庫確認接收到binlog日志的響應，性能上是損耗更大的。
• 主庫等待從庫響應的最大時長是可以配置的，如果超過了配置的時間，半同步復制就會變成異步復制，那么，異步復制的問題同樣也就會出現了。
• 在MySQL 5.7.2之前的版本中，半同步復制存在著幻讀問題的。

當主庫成功提交事物并處于等待從庫確認的過程中，這個時候，從庫都還沒來得及返回處理結果給客戶端，但因為主庫存儲引擎內部已經提交事務了，所以，其他客戶端是可以到從主庫中讀到數據的。

但是，如果下一秒主庫突然掛了，就像這樣圖一樣：

此時，下一次請求過來，因為主庫掛了，就只能把請求切換到從庫中，因為從庫還沒從主庫同步完數據，所以，從庫中當然就讀不到這條數據了，和上一秒讀取數據的結果對比，就造成了幻讀的現象了。

增強半同步復制

最后，增強半同步復制，是mysql 5.7.2后的版本對半同步復制做的一個改進，原理上幾乎是一樣的，主要是解決幻讀的問題。

主庫配置了參數rpl_semi_sync_master_wait_point = AFTER_SYNC 后，主庫在存儲引擎提交事物前，必須先收到從庫數據同步完成的確認信息后，才能提交事務，以此來解決幻讀問題。

可以參考下MySQL官網是怎么描述增強半同步主從復制過程的：

主從延遲問題和常規解決方案

主庫寫入的速度是很快的，因為主庫是多線程并發寫入的，但是，從庫是單線程從主庫拉取數據的，所以從庫從主庫復制數據的速度，就比較慢了，從而產生了主從延遲的問題。

mysql 從 5.6版本開始，就支持多線程復制，但是5.6版本是基于庫級別去操作，也就是說會給每個數據庫開啟一個線程，不同庫處理時在同一時間內是互不影響的；但是，當業務的壓力集中到一個庫時，又會回到和單線程復制一樣的狀況了。

直到mysql 5.7版本，開始引入了基于組提交（group_commit）的概念，這個時候才 真正 支持多路復制功能，官方稱為enhanced multi-threaded slave（簡稱MTS），所以，推薦大家盡可能選擇MySQL 5.7之后的版本。

而主庫掛載的從庫數量過多，也會導致主從復制延遲的問題，一般我們是建議一個主庫掛載從庫的數量，在3~5個比較合適。

另外，我們執行的SQL語句中，如果慢SQL語句過多，也會導致主從復制延遲，比如，我們工作中會遇到批量插入的場景，如果一批插入的數據量過大，就容易造成執行時間過長。

假如，從執行完一份 批量插入數據的SQL語句開始，到在從庫上能查到這些數據的這個過程中，如果耗費了10秒，就導致主從庫之間就延遲10秒了；所以，SQL優化會是一個常態化的工作，可以通過慢SQL日志或監控平臺監控慢SQL，如果單個數據寫入時間過長的話，可以將一批數據分片分批次寫入。

最后，如果出現網絡延遲或者機器的性能比較差，也會導致主從復制延遲的問題，這種情況沒什么可說的，及時優化網絡提升機器性能就行了。

讀寫分離實戰

讀寫分離配置核心組件流程圖：

讀寫分離配置步驟

（1）配置文件中配置主從庫連接信息

（2）注入數據源

（3）數據源切換上下文，其中使用了ThreadLocal保存當前線程的數據源

（4）繼承AbstractRoutingDataSource類重寫determineCurrentLookupKey方法實現數據源動態切換

（5）創建讀庫的自定義注解

（6）切面類

（7）需要走讀庫的業務方法上添加@ReadOnly注解，那么執行這些業務方法時就會被切面攔截修改數據源從而走讀庫進行查詢。

（8）寫主庫、讀從庫的效果

1）生成訂單

2）查詢訂單