項目原先的搜索接口採用SQL查詢的方式實現，數據庫表採用了按城市分表的方式。但隨着業務的發展，搜索接口調用頻次越來越高，搜索接口壓力越來越大，搜索數據庫經常崩潰，從而導致搜索功能經常不能使用。
從上面的系統架構圖可以看出，當用戶修改資料時，接口會修改用戶庫信息，接着觸發器會將改變的用戶信息寫入臨時表。定時腳本每隔1分鐘掃描一次臨時表，將變更的數據寫入到搜索庫中。當用戶再次請求搜索接口時，就可以搜索到最新的數據。
從技術層面分析，原搜索系統的設計有以下缺點：
- 搜索信息不實時。當用戶修改信息時，需要等待1分鐘的時間才能將最新的用戶信息同步到搜索數據庫中。
- ID、暱稱搜索速度慢。按照地區分表的數據庫設計是爲了減輕數據庫壓力，保證大部分按照地區搜索的請求能正常響應。但是如果用戶按照ID或暱稱搜索，那麼我們就需要對成千上萬個地區表全都搜索一次，這時間複雜度可想而知。很多時候按照暱稱和ID搜索速度太慢，需要10多秒才能響應。
- 系統穩定性、拓展性以及處理能力差。這可以歸結爲技術老舊，無法滿足業務需求。隨着搜索量的提升，對數據庫的壓力將會越來越大，而MySQL數據庫天然不適合用來應對海量的請求。現在已經有更加成熟的ElasticSearch可以用來做搜索方面的業務。
- 觸發器不便於管理。觸發器這種東西不好維護，並且擴展性很差，一旦修改的請求變多，很可能導致整個數據庫崩潰（用戶庫崩潰是很嚴重的）。
我們總結一下新搜索系統需要解決的幾個問題：
- 海量請求。幾百萬的請求毫無壓力，上千萬上億也要可以扛得住。
- 實時搜索。指的是當一個用戶修改了其數據之後，另一個用戶能實時地搜索到改用戶。
海量請求。要扛得起海量的搜索請求，可以使用ElasticSearch來實現，它是在Lucene的基礎上進行封裝的一個開源項目，它將Lucene複雜的原理以及API封裝起來，對外提供了一個易用的API接口。ElasticSearch現在已經廣泛地被許多公司使用，其中包括：愛奇藝、百姓網、58到家等公司。
實時搜索。阿里有一個開源項目Canal，就是用來解決這個問題的，Canal項目利用了MySQL數據庫主從同步的原理，將Canal Server模擬成一臺需要同步的從庫，從而讓主庫將binlog日誌流發送到Canal Server接口。Canal項目對binlog日誌的解析進行了封裝，我們可以直接得到解析後的數據，而不需要理會binlog的日誌格式。而且Canal項目整合了zookeeper，整體實現了高可用，可伸縮性強，是一個不錯的解決方案。
經過一段時間的技術預研，我們設計了整個搜索技術架構：
從架構圖可以看出整個系統分爲兩大部分：
- Canal數據變更服務平臺。這部分負責解析MySQL的binlog日誌，並將其解析後的數據封裝成特定的對象放到Kafka中。
- Kafka數據消費方。這部分負責消費存放在Kafka中的消息，當消費方拿到具體的用戶表變更消息時，將最新的用戶信息存放到ES數據倉庫中。
Canal技術變更基礎平臺
因爲考慮到未來可能有其他項目需要監控數據庫某些表的變化，因此我們將Canal獲取MySQL數據變更部分做成一個公用的平臺。當有其他業務需要增加監控的表時，我們可以直接修改配置文件，重啓服務器即可完成添加，極大地提高了開發效率。
在這一部分中，主要分爲兩大部分：Canal Server 和 Canal Client。
Canal Server端。Canal Server僞裝成MySQL的一個從庫，使主庫發送binlog日誌給 Canal Server，Canal Server 收到binlog消息之後進行解析，解析完成後將消息直接發送給Canal Client。在Canal Server端可以設置配置文件進行具體scheme（數據庫）和table（數據庫表）的篩選，從而實現動態地增加對數據庫表的監視。
Canal Client端。Canal Client端接收到Canal Server的消息後直接將消息存到Kafka指定Partition中，並將最新的binlogid發送給zookeeper集羣保存。
Kafka消息消費端
Canal技術變更平臺在獲取到對應的數據庫變更消息後會將其放到指定的Kafka分片裏，具體的業務項目需要到指定的Kafka片區裏消費對應的數據變更消息，之後根據具體的業務需求進行處理。
因爲Canal變化是根據表爲最小單位進行地，因此我在實現方面定義了一個以表爲處理單位的MsgDealer接口：
public interface MsgDealer {
void deal(CanalMsgVo canalMsgVo);
}搜索庫涉及對5個表的監視，因此我實現了5個對應的處理類：
針對不同表的數據變化，自動調用不同的實現類進行處理。