Binlog的三個業務應用場景

1.什麼是binlog

  binlog是mysql的一種二進制日誌文件，用來記錄數據的變化。mysql使用binlog進行主從複製，如圖：

1. 客戶端向master的mysql sever寫入數據
2. 當數據發生變化時，master將變動的數據記錄寫入到二進制文件中，即binlog。
3. slave訂閱了master的binlog，因此會經過一個I/O THREAD與master的DUMP THREAD進行通訊，同步binlog
4. I/O THREAD讀取到binlog後會吸入到relay log中，準備重放。
5. slave會經過SQL THREAD讀取relay log，重放數據的改動並執行相應的改動。

這裏有幾點須要注意：

1. 主從複製不是強一致性，只能保證最終一致
2. master配合binlog複製會影響性能，因此儘可能不要在master上掛太多的slave，若是對時間要求不高，能夠在slave上掛slave

2.binlog的業務應用

  上面介紹了mysql中應用binlog的場景，而咱們的業務能夠假裝成master的slave節點，感知數據的變化，這就給了咱們不少的業務運用空間。

2.1 數據異構

  常常有這樣一個場景：

  原來業務是一個很單一的系統，因此表也在一塊兒。隨着業務的發展，系統開始拆分，總有一些表是各個業務都關注的表，可是對相關的字段的運用場景不一樣，因此這樣一份元數據怎樣更好的爲各個系統服務就成了問題。固然，多寫或者讀寫分離能夠從物理節點上減小對數據服務器的壓力，可是對業務並無作到足夠的支持，由於這些表都是同樣的。所以咱們能夠經過binlog進行數據異構。

如圖所示，訂單系統生成訂單後，經過binlog能夠解析生成用戶維度的訂單信息供用戶中心查詢、商戶維度訂單表供運營管理，以及搜索系統的搜索數據，提供全文搜索功能。

這樣，咱們就經過原始的訂單數據異構到三個系統中，提供了豐富的數據訪問功能。不只從節點上下降了數據服務器的壓力，數據表現形式也更貼近本身的服務，減小沒必要要的字段冗餘。

2.2 緩存數據的補充

對於高併發的系統，數據庫每每是系統性能的瓶頸，畢竟IO響應速度是遠遠小於電子的運算速度的。所以，不少查詢類服務都會在CPU與數據庫之間加上一層緩存。即現從緩存獲取，命中後直接返回，不然從DB中獲取並存入緩存後返回。而若是原始數據變化了但緩存還沒有超時，則緩存中的數據就是過期的數據了。當數據有變動的時候主動修改緩存數據。

當客戶端更改了數據以後，中間件系統經過binlog得到數據變動，並同步到緩存中。這樣就保證了緩存中數據有效性，減小了對數據庫的調用，從而提升總體性能。

2.3 基於數據的任務分發

有這樣一個場景：

  不少系統依賴同一塊重要數據，當這些數據發生變化的時候，須要調用其餘相關係統的通知接口同步數據變化，或者mq消息告知變化並等待其主動同步。這兩種狀況都對原始系統形成了侵入，原始系統改一塊數據，並不想作這麼多其餘的事情。因此這時候能夠經過binlog進行任務分發。

當原始業務系統修改數據後，不須要進行其餘的業務關聯。由調度系統讀取binlog進行相應的任務分發、消息發送以及同步其餘業務狀態。這樣能夠將其餘業務與原始業務系統解耦，並從數據的角度將全部管理功能放在了同一個調度系統中，責任清晰。

3.總結

  binlog是mysql提供的數據同步機制，很好的解決了主從分離、讀寫庫分離等業務。而咱們能夠構建一箇中間件系統，「僞造」成master的一個slave。當讀取了binlog中的數據變化後，根據相應的業務場景作各類業務處理。而目前我接觸到的最多見的就是第一個場景——數據異構，能夠異構到其餘表中，也能夠異構到其餘數據引擎中，好比Elastic Search。