同步MySQL資料至Elasticsearch的方式有哪些

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 ，二是批量更新這種場景可能很難處理，當然如果你的資料都是簡單的根據主鍵進行修改或刪除則能比較好的適用。

以上是同步MySQL資料至Elasticsearch的方式有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！