Binlog 的三個業務應用場景
什麼是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，重放資料的改動並執行相應的改動。
這裡有幾點需要注意：
-
主從複製不是強一致性，只能保證最終一致
-
master 配合 binlog 複製會影響效能，所以儘量不要在 master 上掛太多的 slave，如果對時間要求不高，可以在 slave 上掛 slave
binlog 的業務應用
上面介紹了 mysql 中應用 binlog 的場景，而我們的業務可以偽裝成 master 的 slave 節點，感知資料的變化，這就給了我們很多的業務運用空間。
資料異構
經常有這樣一個場景：
原來業務是一個很單一的系統，所以表也在一起。隨著業務的發展，系統開始拆分，總有一些表是各個業務都關注的表，但是對相關的欄位的運用場景不同，所以這樣一份元資料怎樣更好的為各個系統服務就成了問題。當然，多寫或者讀寫分離可以從物理節點上減少對資料伺服器的壓力，但是對業務並沒有做到足夠的支援，因為這些表都是一樣的。因此我們可以通過 binlog 進行資料異構。
如圖所示，訂單系統生成訂單後，通過 binlog 可以解析生成使用者維度的訂單資訊供使用者中心查詢、商戶維度訂單表供運營管理，以及搜尋系統的搜尋資料，提供全文搜尋功能。
這樣，我們就通過原始的訂單資料異構到三個系統中，提供了豐富的資料訪問功能。不僅從節點上降低了資料伺服器的壓力，資料表現形式也更貼近自己的服務，減少不必要的欄位冗餘。
快取資料的補充
對於高併發的系統，資料庫往往是系統性能的瓶頸，畢竟 IO 響應速度是遠遠小於電子的運算速度的。因此，很多查詢類服務都會在 CPU 與資料庫之間加上一層快取。即先從快取獲取，命中後直接返回，否則從 DB 中獲取並存入快取後返回。而如果原始資料變化了但快取尚未超時，則快取中的資料就是過時的資料了。當資料有變更的時候主動修改快取資料。
當客戶端更改了資料之後，中介軟體系統通過 binlog 獲得資料變更，並同步到快取中。這樣就保證了快取中資料有效性，減少了對資料庫的呼叫，從而提高整體效能。
基於資料的任務分發
有這樣一個場景：
很多系統依賴同一塊重要資料，當這些資料發生變化的時候，需要呼叫其他相關係統的通知介面同步資料變化，或者 mq 訊息告知變化並等待其主動同步。這兩種情況都對原始系統造成了侵入，原始系統改一塊資料，並不想做這麼多其他的事情。所以這時候可以通過 binlog 進行任務分發。
當原始業務系統修改資料後，不需要進行其他的業務關聯。由排程系統讀取 binlog 進行相應的任務分發、訊息傳送以及同步其他業務狀態。這樣可以將其他業務與原始業務系統解耦，並從資料的角度將所有管理功能放在了同一個排程系統中，責任清晰。
總結
binlog 是 mysql 提供的資料同步機制，很好的解決了主從分離、讀寫庫分離等業務。而我們可以構建一箇中間件系統，“偽造”成 master 的一個 slave。當讀取了 binlog 中的資料變化後，根據相應的業務場景做各種業務處理。而目前我接觸到的最常見的就是第一個場景——資料異構，可以異構到其他表中，也可以異構到其他資料引擎中，比如 Elastic Search。
Reference
https://www.cnblogs.com/kingszelda/p/8362612.html