十二讚的商品搜索實現

其實要說很慚愧，雖然我是搜索出身人士，可是十二讚的搜索功能其實在目前是作得很是弱雞的。不過仍是介紹一下這個弱雞的系統。

十二讚的搜索是基於elasticsearch的。由於業務量較小，因此，到目前爲止，尚未用上elasticsearch強大可怕的集羣功能。之因此以爲能夠拿出來分享一下，是由於這個文案的投入是比較小的，效果尚可接受。

對於在小程序上開店的商家來講，通常商品數很少，不多於超過200的，因此在召加回率和精度上，咱們只須要知足召回率就好了。即使搜索結果不夠精準，由於商品少，用戶一眼掃一下也能找到他想要的商品，搜索只是幫他從原有的上百個商品中把範圍縮小到十分之一，就已經頗有效了。

另外，也是由於團隊小，咱們的方案也特別注重精簡，能不本身去寫代碼實現的，就不本身去寫代碼實現。

好了，上方案。

咱們的商品數據是存在MySQL數據庫中的，就用的阿里雲的RDS。咱們運行了一個go-mysql-elasticsearch,這個程序啓動時會運行一次mysql_dump,把數據導出進入elasticsearch,而後接下來就會做爲MySQL的一個slave,不斷地讀取MySQL的binlog，同步進elastichsearch。跟咱們其餘的服務同樣，咱們把這個elasticsearch和go-mysql-elasticsearch也封裝進了一個docker 之中，只對外暴露9200端口來提供服務。

咱們以前的ppt介紹過，十二讚的各類內部業務都已經微服務化，這個elasticsearch的服務，也不例外，它工做在es-sec.z.12zan.net:3000上，後端的實例能夠有多個es的實例，經過http接口來請求elastichsearch的http接口時，網關 server會自動定向到負載最低的elasticsearch實例來提供服務。

這個方案運行不久，咱們就發現一個問題，當咱們的MySQL數據庫的商品表新增了字段時，全部的後續的數據更新都沒法同步的elasticsearch中去了。由於MySQL表的字段比elasticsearch中的字段多了（字段減小啊變動什麼的都會致使這個問題）。

謝天謝地，由於Docker化，咱們能夠垂手可得地解決這個問題。咱們的方案，當MySQL的數據表schema變化時，老的elasticsearch實例不變，繼續提供服務，可是有缺陷，由於新增的數據沒有同步進來；同時，咱們新啓一個Docker實例，這個實例啓動約1分鐘以後就同步進來了全部的商品數據，這時是兩個elasticsearch的實例都在es-sec.z.12zan.net:3000上對外提供http接口服務，其中一個的數據是老的，一個實例的數據是全的。這時候咱們關掉老的Docker上的實例就行了，就實現了索引的切換。用戶可能會感覺到新商品沒有立刻在搜索結果裏體現，感受搜索裏的商品更新有延遲，可是基本上發現這個延遲的機率很小。

其實，淘寶的搜索的索引切換也有這麼一個過程，不過要複雜的多，天天夜裏要生成一個全量的索引，切換掉前一天的索引；而後另外有一個實時的搜索引擎，數據全放在內存裏，只同步當天的數據變動，對外提供服務的接口將兩份數據合併。
【原文連接】