今天來簡單聊聊Suggestion產品
什麼是Suggestion服務？ 一圖勝千言：
當你想要搜尋某個長詞語或者一句話輸入部分時，Suggestion服務預測你極大可能的候選項，並羅列出來，供你選擇。
產品的意義：
1. 降低使用者搜尋的輸入成本，使用者總是懶惰的,誰能讓使用者最懶惰還能幫他把事辦好，這就是好的產品。當然如果真有一天能用腦電波搜尋了，這個產品功能就沒意義了.
2. 為使用者提供提示，因為有部分使用者多一個長片語很有可能只能記住部分。如有部電影叫"心急吃不了熱豆腐"，朋友A推薦給朋友B，只記得"心急吃不了啥"了
3. 提高搜尋轉化率，使用者在任何過程中都有可能流失，打字打完"心急吃不了",一個朋友說別看這個了，看<冰與火之歌>吧，可能還差那最後3個字就能轉戰別的電影了
什麼樣的詞應該納入到Suggestion裡面去呢？
如果把所用所有的搜尋記錄都作為suggestion服務，那使用者輸入完一個字首後，就會出現滿屏的詞語；在這種場景下,儘量提供好用的suggestion而保持簡潔的結果的祕訣在於把控數量並提高轉化率,所以一般可以用雙重法則
1. 如果這個字首的所有搜尋詞不超過N個，按轉化概率從大到小排序
2. 如果超過N個, 放棄掉使用者轉化率小於a的搜尋詞，按轉化概率從大到小排序
整體技術上怎麼實現呢？
如果你在做一個Suggestion總詞語量較小的產品. (<千萬級)
短平快，直接用小指令碼掃每天的使用者搜尋日誌，然後根據策略得出整個搜尋詞表，放到Mysql中；
查詢直接用 select XXX from TABLE_XXX where SuggestionWords like {QUERY}% 進行查詢
訪問量大怎麼辦?
mysql 的查詢成為瓶頸，在前面加一層快取，來儲存結果List即可.
訪問量極大怎麼辦？
這裡極大的意思時，一瞬間的某個詞語的快取未命中（失效或者DB更新後delete）查詢會拖死Mysql
兩個思路
1. mysql加從庫 Master-Slave叢集
2. 更新時主動生成快取，讓前端查詢任何時刻都看不到快取未命中
如果你在做一個Suggestion總詞語量較大的產品. (>千萬級)
類似的場景我之前遇到的是百度的帳號註冊時的Suggestion, N億的註冊使用者，新使用者上來了想註冊abcd這個帳號，已經被佔用了，所以一般推薦abcd作為字首能用的帳號如abcd1,abcd11等，類似的場景如域名註冊服務商的推薦。
技術實現上可以用Tire樹，Tire樹的每個條邊就是每個詞,從非根節點到根節點經過的所有的邊組成了一個詞，如下圖的最長詞dcba
通過這種方式就能對海量基數詞進行Suggestion服務了。
另外tire樹的插入、查詢、刪除的時間複雜度都是o(N),N為待插入、查詢、刪除字串的長度。