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。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的python的业务场景_python| Binlog务应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。