redis查詢優化

背景

搜索推薦中須要結合用戶的偏好特徵對商品進行重排序，一個商品須要召回8個特徵。理論上商品越多，rt越長。現有200個商品須要批量計算。

優化過程：

第一階段：

剛開始按正向邏輯編寫完代碼，整個rt在800ms左右，平均到每一個商品是4ms左右。對於通常的業務場景，這個rt算比較正常的，但還有優化空間

---

第二階段：

使用arthas查看  每次查詢特徵都是redis，1ms不到。那就用多線程併發請求看看。理論上  4核的cpu，開4個線程，能夠提高到150ms。然而在實測過程當中，發現rt變長了達到了7000ms，進程直接卡死。
總結一下有兩個緣由：
1.forkJoin確實是並行在走，但對於每一個商品的特徵總長度有123個，200個就是246800個。join的過程反而會成爲瓶頸
2.redis的server是單線程的nio，多線程查詢不會帶來實質上的性能優化

---

第三階段：

特徵時間比較亂，有的是k-v結構，有的是hash結構。k-v結構的可使用mget一次獲取多個key，能夠減小很大一部分消耗

通過優化，rt在300ms左右

---

第四階段：

接下來優化hash結構的redis數據，這部分沒法批量獲取，但屢次的redis的通訊耗時表如今網絡層。若是能減小這部分的時間，性能會有較大提高。因而用管道查詢的方式，一次提交請求redis處理完之後，一次返回，
此次優化後，rt在40ms左右。

結果：

最終，rt從一開始的800ms，提高到40ms。優化了20倍。