## 1 原本以為自己對redis命令還蠻熟悉的，各種資料模型各種基於redis的騷操作。但是最近在使用redis的scan的命令式卻踩了一個坑，頓時發覺自己原來對redis的遊標理解的很有限。所以記錄下這個踩坑的過程，背景如下： 公司因為redis伺服器記憶體吃緊，需要刪除一些無用的沒有設定過期時間的key。大概有500多w的key。雖然key的數目聽起來挺嚇人。但是自己玩redis也有年頭了，這種事還不是手到擒來？ 當時想了下，具體方案是通過lua指令碼來過濾出500w的key。然後進行刪除動作。lua指令碼在redis server上執行，執行速度快，執行一批只需要和redis server建立一次連線。篩選出來key，然後一次刪1w。然後通過shell指令碼迴圈個500次就能刪完所有的。以前通過lua指令碼做過類似批量更新的操作，3w一次也是秒級的。基本不會造成redis的阻塞。這樣算起來，10分鐘就能搞定500w的key。 然後，我就開始直接寫lua指令碼。首先是篩選。 用過redis的人，肯定知道redis是單執行緒作業的，肯定不能用`keys`命令來篩選，因為keys命令會一次性進行全盤搜尋，會造成redis的阻塞，從而會影響正常業務的命令執行。 500w資料量的key，只能增量迭代來進行。redis提供了`scan`命令，就是用於增量迭代的。這個命令可以每次返回少量的元素，所以這個命令十分適合用來處理大的資料集的迭代，可以用於生產環境。  scan命令會返回一個數組，第一項為遊標的位置，第二項是key的列表。如果遊標到達了末尾，第一項會返回0。 ## 2 所以我寫的第一版的lua指令碼如下： ```lua local c = 0 local resp = redis.call('SCAN',c,'MATCH','authToken*','COUNT',10000) c = tonumber(resp[1]) local dataList = resp[2] for i=1,#dataList do local d = dataList[i] local ttl = redis.call('TTL',d) if ttl == -1 then redis.call('DEL',d) end end if c==0 then return 'all finished' else return 'end' end ``` 在本地的測試redis環境中，通過執行以下命令mock了20w的測試資料： ```lua eval "for i = 1, 200000 do redis.call('SET','authToken_' .. i,i) end" 0 ``` 然後執行`script load`命令上傳lua指令碼得到SHA值，然後執行`evalsha`去執行得到的SHA值來執行。具體過程如下：  我每刪1w資料，執行下dbsize（因為這是我本地的redis，裡面只有mock的資料，dbsize也就等同於這個字首key的數量了）。 奇怪的是，前面幾行都是正常的。但是到了第三次的時候，dbsize變成了16999，多刪了1個，我也沒太在意，但是最後在dbsize還剩下124204個的時候，數量就不動了。之後無論再執行多少遍，數量還依舊是124204個。 隨即我直接執行scan命令:  發現遊標雖然沒有到達末尾，但是key的列表卻是空的。 這個結果讓我懵逼了一段時間。我仔細檢查了lua指令碼，沒有問題啊。難道是redis的scan命令有bug？難道我理解的有問題？ 我再去翻看redis的命令文件對`count`選項的解釋：  經過詳細研讀，發現count選項所指定的返回數量還不是一定的，雖然知道可能是count的問題，但無奈文件的解釋實在難以很通俗的理解，依舊不知道具體問題在哪 ## 3 後來經過某個小夥伴的提示，看到了另外一篇對於scan命令count選項通俗的解釋：  看完之後恍然大悟。原來count選項後面跟的數字**並不是意味著每次返回的元素數量，而是scan命令每次遍歷字典槽的數量** 我scan執行的時候每一次都是從遊標0的位置開始遍歷，而並不是每一個字典槽裡都存放著我所需要篩選的資料，這就造成了我最後的一個現象：雖然我count後面跟的是10000，但是實際redis從開頭往下遍歷了10000個字典槽後，發現沒有資料槽存放著我所需要的資料。所以我最後的dbsize數量永遠停留在了124204個。 所以在使用`scan`命令的時候，如果需要迭代的遍歷，需要每次呼叫都需要使用上一次這個呼叫返回的遊標作為該次呼叫的遊標引數，以此來延續之前的迭代過程。 至此，心中的疑惑就此解開，改了一版lua： ```lua local c = tonumber(ARGV[1]) local resp = redis.call('SCAN',c,'MATCH','authToken*','COUNT',10000) c = tonumber(resp[1]) local dataList = resp[2] for i=1,#dataList do local d = dataList[i] local ttl = redis.call('TTL',d) if ttl == -1 then redis.call('DEL',d) end end return c ``` 在本地上傳後執行：   可以看到，`scan`命令沒法完全保證每次篩選的數量完全等同於給定的count，但是整個迭代卻很好的延續下去了。最後也得到了遊標返回0，也就是到了末尾。至此，測試資料20w被全部刪完。 這段lua只要在套上shell進行迴圈就可以直接在生產上跑了。經過估算大概在12分鐘左右能刪除掉500w的資料。 知其然，知其所以然。雖然scan命令以前也曾玩過。但是的確不知道其中的細節。況且文件的翻譯也不是那麼的準確，以至於自己在面對錯誤的結果時整整浪費了近1個多小時的時間。記錄下來，加深理解。 ## 4.聯絡作者 微信關注 「**jishuyuanren**」或者掃描以下二維碼獲取更多幹貨 ![file](https://img2020.cnblogs.com/other/268224/202007/268224-20200719105139775-2146926