最近在做乙個模糊匹配查詢的需求，剖析需求本質無非就是根據入參來模糊匹配相關資料進行返回展示。
由於資料是儲存在資料庫的，簡單實現的話可以考慮使用db的sql來進行模糊匹配查詢，比較考量的就是如何控制你的sql以及如果能夠高效命中索引來優化sql來實現快速查詢了。
由於是全查詢的業務，而且業務場景對服務響應是有一定要求的，如果簡單的使用資料庫恐怕後續峰值難以抗住且也會影響其他同庫的讀寫操作，所以這次打算還是使用快取來解決這種全查詢場景。
redis的效能非常棒，而且支援多種資料結構供開發者儲存和呼叫，而且提供了大量api對開發非常友好，而且這些api的內部演算法也是非常考究的，真的是開發利器。
按照漢字以最左匹配原則進行模糊匹配，每次返回不超過固定數量的匹配詞即可。
首先要分析設計要解決哪些問題：
q：高併發場景下，如何保證服務可靠且快速響應
a：使用redis做全查詢快取，db做資料持久化，所有請求打到快取，保護db；若快取失效，把請求攔截直接返回，傳送mq非同步請求db資料更新快取；若快取異常，**做兜底控制，如果可以置入動態配置來控制是否兜底查db，極端情況下直接服務降級處理不走db。
q：使用redis哪種資料結構進行儲存資料？
a：首先要考慮需要返回哪些資料，且這些資料的查詢可以支援模糊查詢；由於需求只需要返回名稱和對應id，決定採用hash表進行儲存；且hash表支援模糊查詢命令。
關於redis的命令可以參考
在應用啟動時，使用hmset進行批量全量快取資料更新，這裡有個細節點，由於是分布式部署，如果不加限制預設每台機器啟動都會更新一遍，其實是沒有必要的，可以做乙個全域性分布式鎖進行判斷和控制，這個不難實現不再細說。
hmset key field value [field value ...]
要模糊查什麼就把模糊查的作為field就可以了，由於我這裡只需要兩個字段，我就借用雜湊表的資料結構進行儲存了，如果需要更多字段可以研究使用有序集合或者其他資料結構。
使用hscan進行模糊查詢，可以使用，優缺點分析參考
由於hscan使用了游標，是乙個增量式命令，每次查詢都是返回一部分資料，所以不會像keys類命令hang住redis導致服務短暫停滯，所以它是安全無公害的，只要運用得當，在生產環境是可以放心使用的，關於缺點要參考：
在使用過程中仔細研究這個命令的底層實現，根據實際業務場景去使用。
業務底層還是需要封裝下hscan命令，由於是游標查詢，最開始cursor我們都設定為0就好，每次從0開始查詢，count來控制每次遍歷的數量，由於這個命令執行的時間複雜度是o(n)，所以count越大，每次執行時間理論上會越長，可以根據實際場景進行調整，在遍歷時候判斷返回的游標cursor是否為0，如果為0代表整個遍歷結束。
目前只使用到最左匹配模糊查詢，如上圖，我試了下最右匹配、中間模糊也是可以查詢到的，可以支援後續其他業務訴求。
由於一般我們檢索的名稱是漢字，儲存到redis可能會有環境問題導致亂碼，我目前的處理是把漢字轉ascii碼進行儲存，同樣查詢的時候也是轉ascii碼進行查詢，這樣可以解決漢字或者編碼帶來的亂碼問題。
springboot使用redis做快取
org.springframework.bootgroupid spring boot starter data redisartifactid dependency redis host 121.89.192.157 port 6379 jedis pool max active 25 max i...
Redis使用總結
1 常用記憶體優化手段與引數 通過我們上面的一些實現上的分析可以看出redis實際上的記憶體管理成本非常高，即占用了過多的記憶體，作者對這點也非常清楚，所以提供了一系列的引數和手段來控制和節省記憶體，我們分別來討論下。首先最重要的一點是不要開啟redis的vm選項，即虛擬記憶體功能，這個本來是作為r...
Redis使用總結
在專案開發過程中，筆主使用redis也有一段時間了。在一些特性的場景，redis能幫助我們解決一些問題。因此，總結一下分享給大家。1.使用redis實現分布式鎖 redis訪問工具類 component public class redisdao component public class red...