目前的流程：

兩個Redis：

Redis1： 儲存詞條的summary資訊

Redis2：任務佇列，用於暫存Redis中沒有summary，需要進行處理獲取summary， 佇列用的Redis的list結構

兩個程序：

1、 程序1：服務程序

接收請求，劃內鏈詞，然後從Redis1中去獲取詞的summary， 如果獲取失敗，則返回code=4的錯誤，並將詞條id寫入任務佇列Redis2等待被程序2處理

2、程序2：讀取Summary的程序

迴圈從任務佇列Redis2中讀取詞條id，並呼叫一個A介面獲取詞條的summary資訊，寫入Redis1中，並設定過期時間為3天

最近暴露出來的問題：

      一個請求重複請求很多次後，仍然返回code=4的錯誤

      但是按照上述邏輯，如果速度夠快的話，第一次請求的時候返回code=4的錯誤，第二次應該是可以拿到資料的

分析原因：

      首先查看了Redis1，的確拿不到對應詞條的summary資訊

      手動獲取了summary並存入Redis1後，請求可以獲取到資料

      看來的確是因為Redis中獲取不到資料而導致的

      看了下Redis2的長度， 居然積壓了1000多萬！

      的確， 最近 A介面（也就是程序2中獲取summary的介面掛掉了很長一段時間）， 而且可以觀察到，這個Redis2佇列的長度仍然在不斷升高，一晚上的時間上升了接近40萬

      佇列長度不斷飆升，一方面是因為大量的詞條獲取不到summary， 導致Redis1大量的miss， 而miss的都會進入到Redis2佇列中

      此外，程序1和程序2速度不匹配應該也是一個原因， 程序2只有一個程序在工作，而程序1是有4個程序在工作

解決辦法：

      提高程序2的數量， 當然在提高程序2的數量的時候，我首先得知道獲取summary的A介面的服務能力， 因為我這些程序會調這同一個介面

      於是我用ab壓測了下那個介面，服務能力大概在150 QPS, 於是我可以放心的提高我的程序數了

      我將程序數從1提高到了5， 可以看到佇列中積壓的資料正在逐漸的減少了，大概每秒減少100多個， 這樣一天左右，積壓的資料就會全部被處理掉