1.什么是binlog
binlog是mysql的一種二進制日志文件，用來記錄數據的變化。mysql使用binlog進行主從復制，如圖：
- 客戶端向master的mysql sever寫入數據
- 當數據發生變化時，master將變更的數據記錄寫入到二進制文件中，即binlog。
- slave訂閱了master的binlog，所以會通過一個I/O THREAD與master的DUMP THREAD進行通信，同步binlog
- I/O THREAD讀取到binlog后會吸入到relay log中，准備重放。
- slave會通過SQL THREAD讀取relay log，重放數據的改動並執行相應的改動。
這里有幾點需要注意：
- 主從復制不是強一致性，只能保證最終一致
- 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。