後端邏輯：  接收請求、分詞匹配、讀redis做一些過濾策略

在不斷提高併發數的壓測過程中，發現一個問題，後臺服務對一個請求的處理時間也在增高， 而且增高的主要時間是消耗在讀redis過濾那塊

過濾那塊的主要邏輯是：從redis中讀資料，並基於這些資料做一些過濾的策略

為什麼這塊的耗時會增長呢？難道是redis的執行緒池不夠用？導致有些redis的io請求要等待一會？

應該不會，因為redis預設的最大連線數是1w個，而我們的併發不會到這麼多， 所以redis的連線數肯定是足夠的

那應該是IO雖然執行完了，但是沒有被喚醒：  因為redis是io請求，系統排程的話，當一個A程序在執行io的時候，會被掛起，CPU會去執行另外一個程序，應該是A程序中redis的io請求雖然返回了，但是暫時還沒有空閒的CPU來繼續執行A程序剩餘的程式碼，也就是A程序還無法被喚醒，導致處於等待狀態，所以拉長了整個過濾的時間，核心原因仍然是， 服務處理不過來。