項目中有個全文檢索系統，此係統中需要知道應用中數據的實時更新情況，如增加，刪除，這些對於索引與數據庫數據的同步都很重要。針對於此處理的方式一般有兩種，一種是應用層修改，直接發送消息給檢索系統，此對系統的消耗是比較大的，一般不可取;另一種是應用系統跟檢索系統之間有一種同步機制，可以通過計算ID checksum值的方式來保證數據的同步，此方式在公司相關的系統中都有應用，也是一種可行的方法，不過相關邏輯還是比較複雜。考慮到我們新項目中使用到的是mysql 數據庫，同時通過Binlog來監測數據的更新情況在業界也有相關的應用，比如通過Binlog來更新緩存（這也是我現在手上正在做的一個項目，正在開發過程中），對新浪更新redis緩存也是基於此，相關很多公司都有應用，以上爲基於Mysql Binlog來監測數據庫數據更新情況的背景說明。
二.開源項目選擇
Tungsten是一個開源的數據庫同步工具，詳細可參考官網（https://code.google.com/p/tungsten-replicator/）
其提供的tungsten API可供下載，此API實現了mysql slave同步流程的相關功能。
三.基本流程
基於Mysql Binlog完成數據監控主要有三個流程：（對於tungsten使用的API包主要是：com.continuent.tungsten.replicator.extractor.mysql）
1.把Binlog從指定的mysql master日誌目錄同步過來，通過以上包中的RelayClient類即可，可指定mysql主機地址，相關用戶名密碼，即JDBC連接的方式參數指定，即可完成Binlog日誌的同步。
2.把同步過來的Binlog日誌解析成我們能看的懂的SQL語句。對於此解析，由於日誌格式的不同，解析也有不同，是通過MysqlExtractor類，指定Binlog的本地目錄，即可完成解析。（對於mysql binlog的日誌說明可以參考：Mysql Binlog三種格式介紹及分析）
3.在以上解析後會得到對應的Sql語句，對於如果選用row日誌格式，會知道具體的數據變化情況,MysqlExtractor類數據可轉換化RowChangeData對象，即可完成修改數據的讀取;如果是基於Statement的日誌解析，得到的對應的SQL語句，如果需要提取對應數據修改，需要引入SQL解析，我們項目中採用了MIXED的日誌格式，SQL解析採用了JSqlParser,此開源項目對SQL的解析有限，它是通過javacc來完成SQL語義的解析，我們項目中對javacc定義文件的做了修改，使其支撐更復雜的SQL解析。
通過以上三個流程，即可完成數據庫對應修改數據的提取。對應的mysql產生的binlog會有很多，在實際應用中解析時可以跟據自己監測的特定SQL，這樣很大提高解析速度。（PS:對於增加特定SQL解析所用的時間是幾百甚至幾十納表即可完成，但是對於一次解析則需要MS級別的解析。因此如何選擇供借鑑）以上是整體流程，一般是多線程異步執行（mysql slave同步流程也是如此）。一個線程執行RelayClient完成日誌的同步流程，一個線程完成MysqlExtractor的日誌解析流程。一般來說，日誌同步的速度遠遠大於日
志解析的速度，因此對於流程的控制是個需要考慮的問題。（我們是修改tungsten API源碼，通過java Semaphore信號量來控制日誌的同步與解析速度）日誌同步如果沒有新的新的日誌產生會出現等待新日誌更新，如果沒有新的日誌更新，日誌解析線程也會等待，此流程跟Mysql的slave同步線程的流程是一樣的。實際線上使用時，mysql日誌的產生速度，以及mysql的解析速度可測試，實時性是否滿足需求，我們的流程在測試階段還算比較不錯，實時性在MS級別上。
四:說明
上面是基於tungsten API完成mysql數據更新監控項目的簡單介紹。在此需要注意是不同的日誌格式，解析相關比較大，因此在考慮自己應用的基礎上，通過部分的IO開銷，來使解析變得容易是可取的。而且statement日誌格式對應的解析有時是做不了的。（個人推薦mysql 使用row日誌格式）
原先我們系統在使用redis時，是基於應用層更新的，完成的分佈式方案，現老大在讓我做二期的緩存方案，已經接近尾聲。應用層數據更新將通過binlog更新的方式，來完成緩存數據的更新。應用層對緩存的更新，只是使用。（我們的特殊業務需求，一些原始數據需要從DB中加載，考慮到不增加DB額外負載的情況，會考慮還是保留在應用層flush）通過此方式，能大大解耦應用層跟緩存模塊的耦合，系統變得更模塊化。
相關源碼，可參考其tungsten API中對應的單元測試，其單元測試還比較完整，相應的例子都有。如有不對或者交流的地方可聯繫我。(個人微博:純生活)