企業開發實踐中通常需要提供資料搜尋的功能，例如，電商系統中的商品搜尋、訂單搜尋等。通常，搜尋任務通常由搜尋引擎擔當。如Elasticsearch。而我們的原始資料為了安全性等問題通常儲存在關係型資料庫中。在搜尋資料前，我們需要先將資料從關係型資料庫中同步至搜尋引擎中。因此，整個業務搜尋過程包含兩個階段，第一階段，將資料從關係型資料庫同步至搜尋引擎；第二階段，從搜尋引擎搜尋資料，並返回至使用者。下面，我將結合不同業務場景給出相應的資料同步解決方案。

第一，資料量小，業務查詢簡單。此類場景中，關係資料庫中待同步的表資料中無表連線操作或者存在少量的表連線操作。使用者在將資料同步到ES前對資料進行連線處理，或者資料同步時不做任何處理，待業務查詢時再在ES中進行關聯查詢。通常我們可以採取Logstash或者Canal讀取相應的表資料，然後寫入到搜尋引擎的索引中。具體架構設計如下圖1.1所示。

圖1.1 基於Logstash的資料同步方案

圖1.2 基於Canal的資料同步方案

       第二，資料量大，業務查詢複雜。此種場景通常發生在大型綜合類電商的商品查詢中，由於資料量大，業務查詢複雜，使用者對查詢的響應時延要求高。所以，我們需要考慮資料的分庫分表問題，以及提前將資料組織好以便後期查詢的問題。這種情況下，我們可以將資料分為主資料和從資料。例如，在商品查詢中，it_item_spu為商品表，it_item_cate為商品分類表，it_item_sku為商品SKU表。我們可以認為，it_item_spu為主表，it_item_cate和it_item_sku為從表。我們可以將這三張表構建在一個大的索引中，該索引中包含這三張表中的所有資訊。那麼，我們如何來構建這個大而全的索引呢？這個時候，我們可以監聽主表的變更記錄，然後再通過JDBC反查資料連線其他從表來豐富資料。至於如何監聽主表變更資料通常由兩種處理方式，一種是基於Mysql的binlog日誌來監聽變更，另一種是基於業務操作傳送事件來處理。其架構設計具體如圖1.3和圖1.4所示。

圖1.3 基於Canal同步資料並反查資料庫方案

圖1.4 基於Kafka訊息事件並反查資料庫方案

      總結，資料同步為資料搜尋提供了資料保證，而複雜業務邏輯場景下，如果能夠在資料同步階段微資料搜尋重新組織好資料，那麼就能夠簡化業務查詢的邏輯，同時提供使用者響應時延。