1 問題域

業務發展的初期，我們的數據庫架構往往是單庫單表，外加讀寫分離來快速的支撐業務，隨著用戶量和訂單量的增加，數據庫的計算和存儲往往會成為我們系統的瓶頸，業界的實踐多數采用分而治之的思想：分庫分表，通過分庫分表應對存系統讀寫性能瓶頸和存儲瓶頸；分庫分表幫我們解決問題的同時，也帶來了復雜性；比如多條件的分頁查詢，多條件的聯表查詢變得復雜起來，通過調研我們發現針對這些分頁，聯表的復雜查詢，業界常用的解決方案有以下兩種：1 構建ES寬表，2 構建查詢條件到表主鍵Mapping映射表；本表文章介紹我們的實踐：基于公司的中間件DTS構建實時性的ES寬表。所謂的寬表是通過主鍵將多張表關聯成一張表，比如訂單維度的寬表字段包含：訂單主表，訂單明細表，商品表，用戶表等表字段。

2 ES寬表構建解決方案域

2.1 同步雙寫

應用在接收到寫請求后，同步寫DB成功，然后再同步寫ES。

2.2 異步雙寫

應用在接收到寫請求后，同步寫DB成功，異步發送MQ，消費MQ異步寫ES。

2.3 基于Binlog的實時同步

2.3.1 Binlog作為消息

將Binlog作為消息，或者驅動的Event，接收到消息后，RPC調取下游的業務系統，獲取業務數據進行數組的組裝，寫入ES。

2.3.2 Binlog作為數據

解析Binlog中的數據，獲取庫表，字段變更前后的內容，INSERT, UPDATE, DELETE事件，基于Binlog中的數據去構建寬表，寫入ES。

3 解決方案優缺點對比

4 我們的實踐

4.1 Binlog作為數據構建ES寬表

4.1.1 順序性的保證

上游DTS監聽的binlog是有序的；發送消息時，業務方可以配置業務主鍵例如uep_order_no，DTS可以根據業務主鍵進行hash，將該條消息發送到對應的隊列保證局部有序性；消費者消費時，同一個訂單號uep_order_no映射到同一個分區，保證順序消費；

4.1.2 冪等性的保證

DTS可以保證消息不丟失，但不保證消息不重復，可能發送重復的消息需要業務方保證冪等性，

UPDATE/DELETE操作天然具有冪等性

INSERT操作在進行操作前需要先判斷下數據是否存在，不存在則插入，存在則更新

4.1.3 數據一致性的保證

由于數據存儲在Mysql和ES兩種存儲媒介，可以采用定時任務對賬機制保證數據的一致性，如果數據不一致采用補償任務進行補償操作

4.1.4 存量數據遷移

采用定時任務分頁將數據從Mysql遷移到ES

4.2 ES復雜檢索

4.2.1 檢索的分類

多條件的復雜查詢，采用Bool查詢；

4.2.2 查詢條件構建