在很多MYSQL環境中，對於MYSQL的分布式事物處理一直是個難題，在當前互聯網環境中，大多數應用系統是基於SOA的很多復雜接口之間的調用，並且事物之間的處理優先級也是有先后的，所以對於實際入庫的數據而言，不同的系統，對於當前入庫的處理方式是不一樣的，這樣就衍生出了對於訂閱MYSQL消息的需求。
在公司內部，這套分布式消息系統負責了各個子接口之間數據的銜接，同時肩負后端DW數據倉庫的實時消息計算，多數的RDBMS數據，被分解成各種子消息隊列，通過不同的topic被各種消費者訂閱。
一、如何分解消息
后端訂閱程序（基於阿里巴巴的canal）通過解析不同應用的binlog (mysql線上產生的二進制日志) 通過模擬slave的行為，將binlog順序的訂閱到本地，通過內部解析程序，將binlog events解析成對應的消息，通過MetaQ 固化解析完成的消息，自定義存放時間，從而讓consumer 自行訂閱到對應的系統，進行相關處理。
具體roma文檔可以參考我的blog:
http://www.vmcd.org/docs/roma_system.pdf
二、何時訂閱
通常當支付系統需要做異步分布式事務調用的時候，可以采用roma消息。采用水平拆分DB而需要一些統計類的需求的時候（合表） 可以訂閱合並的topics。當需要一個匯總的數據倉庫，執行跨庫join查詢的時候 可以訂閱roma消息。
上圖中，各類系統通過RPC框架進行異步調用，同時將訂閱到的消息（roma異步消息）進行相處理，將操作類型，操作細節發送給對應子系統，從而實現了操作的異步化（而roma對於前端數據庫日志的實時解析保證了事物消息的實時性）。
三、對於數據倉庫
在我們的系統中，很多核心表被水平拆分成了N份，對於后端實時數據倉庫來說，希望通過合並所有的拆分表，進行多維度的查詢工作 （對job來說，可以通過定期任務抽取水平拆分的表，但是實時性是滯后的）。
在中轉服務器上，使用java程序直接訂閱roma的消息，拼接成相應的SQL在后端DW上直接執行。
通過訂閱同步消息，將前端更新實時同步到后端的數據倉庫，從而達到實時分析的需求。后期結合binlog server的改進還可以進行所有系統的binlog 集中化分層訂閱。
具體可以參考：
https://www.mariadb.com/blog/binlog-server
四、對於實時分析平台
同樣可以訂閱前端RDBMS操作到后端大數據平台，通過流式計算實現秒級的分析。
后期需要改進的：
-
roma的訂閱能力，對於前端log並發解析的粒度
-
智能的存儲策略 動態調整沒有被訂閱消息的保存時間