同步 MySQL 數據至 Elasticsearch/Redis/MQ 等的五種方式

同步 MySQL 數據至 Elasticsearch/Redis/MQ 等的五種方式

在實際應用中，咱們常常須要把 MySQL 的數據同步至其它數據源，也就是在對 MySQL 的數據進行了新增、修改、刪除等操做後，把該數據相關的業務邏輯變動也應用到其它數據源，例如：

• MySQL -> Elasticsearch ，同步 ES 的索引
• MySQL -> Redis ，刷新緩存
• MySQL -> MQ (如 Kafka 等) ，投遞消息

本文總結了五種數據同步的方式。

1. 業務層同步

因爲對 MySQL 數據的操做也是在業務層完成的，因此在業務層同步操做另外的數據源也是很天然的，比較常見的作法就是在 ORM 的 hooks 鉤子裏編寫相關同步代碼。

這種方式的缺點是，當服務愈來愈多時，同步的部分可能會過於分散從而致使難以更新迭代，例如對 ES 索引進行不兼容遷移時就可能會牽一髮而動全身。

2. 中間件同步

當應用架構演變爲微服務時，各個服務裏可能再也不直接調用 MySQL ，而是經過一層 middleware 中間件，這時候就能夠在中間件操做 MySQL 的同時同步其它數據源。

這種方式須要中間件去適配，具備必定複雜度。

3. 定時任務根據 updated_at 字段同步

在 MySQL 的表結構裏設置特殊的字段，如 updated_at（數據的更新時間），根據此字段，由定時任務去查詢實際變動的數據，從而實現數據的增量更新。

這種方式你可使用開源的 Logstash 去完成。

固然缺點也很明顯，就是沒法同步數據的刪除操做。

4. 解析 binlog 同步

好比著名的 canal 。

經過假裝成 slave 去解析 MySQL 的 binary log 從而得知數據的變動。

這是一種業界比較成熟的方案。

這種方式要求你將 MySQL 的 binlog-format 設置爲 ROW 模式。

5. 解析 binlog -- mixed / statement 格式

MySQL 的 binlog 有三種格式：

• ROW 模式，binlog 按行的方式去記錄數據的變動；
• statement 模式，binlog 記錄的是 SQL 語句；
• mixed 模式時，混合以上兩種，記錄的多是 SQL 語句或者 ROW 模式的每行變動；

某些狀況下，可能你的 MySQL binlog 沒法被設置爲 ROW 模式，這種時候，咱們仍然能夠去統一解析 binlog ，從而完成同步，可是這裏解析出來的固然仍是原始的 SQL 語句或者 ROW 模式的每行變動，這種時候是須要咱們去根據業務解析這些 SQL 或者每行變動，好比利用正則匹配或者 AST 抽象語法樹等，而後根據解析的結果再進行數據的同步。

這種方式的限制也很明顯，一是須要本身適配業務解析 SQL ，二是批量更新這種場景可能很難處理，固然若是你的數據都是簡單的根據主鍵進行修改或者刪除則能比較好的適用。

結語

最後列舉幾個 binlog 解析的開源庫：

• canal
• go-mysql
• zongji