Redis面試複習

1.認識Redis

• 工做模型：單線程架構和IO多路複用來實現高性能的內存數據庫服務
• 緣由：a)單線程簡化數據結構和算法的實現；b)避免線程切換和線程競爭的開銷
• 應用場景：緩存/排行系統/統計器應用/社交網絡/消息隊列/熱數據

2.數據類型

2-1.字符串類型

• 命令相關：使用mget能夠減小網絡次數，提升開發效率（字符串不能超過512MB）

• 內部編碼：根據當前值的類型和長度決定使用哪一種編碼

  • int：8bytes長整型
  • embstr：小於等於39bytes的字符串
  • raw：大於39bytes的字符串
• 底層數據結構：數組
• 應用場景：緩存功能/計數/共享Seesion/限速

2-2.哈希類型

• 命令相關：鍵值自己又是一個鍵值對結構; set key field

• 內部編碼：

  • ziplist壓縮列表；知足哈希類型元素個數小於hash-max-ziplist-entries和全部值小於hash-max-ziplist-value
  • hashtable哈希表：當沒法知足ziplist的條件時，會使用hashtable做爲哈希的內部實現
• 底層數據結構：數組（hashkey） + 鏈表（field）
• 應用場景：關係數據表記錄

2-3.列表類型

• 命令相關：能夠根據索引查詢修改，阻塞刪除，頭尾添加；根據不一樣的命令能夠實現隊列/棧等操做

• 內部編碼：

  • ziplist壓縮列表；知足哈希類型元素個數小於hash-max-ziplist-entries和全部值小於hash-max-ziplist-value
  • linkedlist鏈表：當沒法知足ziplist的條件時，會使用linkedlist做爲列表的內部實現
• 底層數據結構：雙向鏈表
• 應用場景：消息隊列/文章列表

2-4.集合

• 命令相關：一個集合中能夠存放多個元素

• 內部編碼：

  • intset整數集合：當集合中的元素個數小於set-max-intset-entries配置
  • hashtable哈希表；當集合類型沒法知足intset條件
• 底層數據結構：hash
• 應用場景：標籤功能

2-5.有序集合

• 命令相關：一個集合中能夠存放多個擁有分數的元素，用於排序

• 內部編碼：

  • ziplist壓縮列表：當集合中的元素個數小於set-max-ziplist-entries配置
  • skiplist跳躍表；當集合類型沒法知足ziplist條件時
• 底層數據結構：hash + 跳躍表
• 應用場景：排行系統

3.小功能

3-1.慢查詢

• 配置方式：a)配置文件；b)動態配置（rewrite持久化到本地配置文件中）
• 獲取慢查詢日誌：slowlog show get [n]；採用隊列存儲，先進先出形式
• 日誌屬性：日誌標識，發生時間，命令耗時，執行命令和參數
• 最佳實踐：max-len > 1000 & slower-than 1ms

3-2.Pipeline

• 場景：將一組命令封裝，經過一次RTT傳輸；可以減小網絡延遲和性能瓶頸

• Redis的批量命令與Pipeline區別：

  • 原子性：批量命令是原子性的
  • 命令格式：批量命令一次對應多個Key
  • 實現機制：Pipeline須要客戶端支持
• 最佳實踐：能夠將大Pipeline拆分紅多個小Pipeline來完成

3-3.事務和Lua

• 事務：原子性，保證數據一致性
• 相關命令：multi開始事務，exec事務提交，discard中止事務；watch確保事務中的key沒有被其餘客戶端修改
• 事務錯誤: a)語法錯誤：Redis事務忽略； b)運行錯誤：事務提交後執行報錯
• 不支持回滾：保持Redis的簡單快捷；關於語法錯誤而失敗應該在開發過程當中被發現

• Lua腳本：Redis腳本語言

  • Lua腳本在Redis中是原子執行的，執行過程當中不插入其餘命令
  • Lua腳本定製命令並能夠常駐內存中，實現複用的效果
  • Lua腳本能夠將多條命令一次性打包，減小網絡開銷

3-4.Bitmaps和Hyperloglog

• Bitmaps：一個以位爲單位的數組，數組中的每一個單元只能存儲0和1，數組的下標稱之爲偏移量
• 設置：setbit key offset value
• 運算：bitop [and(交集) | or(並集) | not（非) | xor（異或）] destkey [keys...]
• 應用場景：大用戶量時統計活躍數，能有效減小內存
• Hyperloglog：一種基數算法，實際數據類型爲字符串類型，利用極小的內存空間完成獨立總數的統計（不須要單條記錄）

3-5.發佈和訂閱

發佈者客戶端向指定的頻道（channel）發佈消 息，訂閱該頻道的每一個客戶端均可以收到該消息

• 相關命令：publish發佈，subscrible訂閱
• 注意點：a)客戶端在執行訂閱命令以後進入訂閱狀態；b)新開啓的訂閱客戶端，沒法接受到該頻道以前的消息，由於Redis不會對發佈的消息進行持久化
• 使用場景：聊天室/公告牌/消息解耦/視頻管理系統

3-6.GEO

地理信息定位功能：支持存儲地理位置信息來實現諸如附近位置、搖一搖這類依賴於地理位置信息的功能；底層實現是：zset

4.客戶端

客戶端通訊協議：基於TCP協議定製RESP實現交互的
RESP協議優勢：a)實現容易；b)解析快；c)人類可讀

4-1.客戶端管理

4-2.客戶端常見異常

1.沒法從鏈接池中獲取到鏈接

對象個數默認是8個：blockWhenExhausted=false表明鏈接池沒有資源可能的緣由：

1. 鏈接池設置太小
2. 沒有釋放鏈接
3. 存在慢查詢操做
4. 服務端命令執行過程被堵塞

2.客戶端讀寫超時

1.讀寫超時時間設置太短
2.命令自己比較慢
3.客戶端與服務端網絡不正常
4.Redis自身發生堵塞

3.客戶端鏈接超時

1.鏈接超時設置太短
2.Redis發生堵塞，形成tcp-backlog已滿
3.客戶端緩衝區異常
4.輸出緩衝區滿
5.長時間閒置鏈接被服務端主動斷開
6.不正常併發讀寫

4.Lua腳本正在執行，並超過lua-time-limit
5.Redis正在加載持久化文件
6.Redis使用的內存超過maxmemory配置
7.客戶端鏈接數過大

5.持久化

5-1.RDB方式

RDB持久化：把當前進程數據生成快照保存到硬盤的過程，觸發RDB持久化分爲手動觸發和自動觸發

• 手動觸發：經過bgsave命令Redis進程執行fork操做建立子進程，由子進程負責完成

• 自動觸發：

  • save相關配置: sava m n (表示m秒內數據集存在n次修改即自動觸發bgsave)
  • 從節點執行全量複製操做，主節點自動執行bgsave生成RDB文件併發送給從節點
  • 執行debug reload命令從新加載Redis時，也會自動觸發save操做
  • 默認狀況下執行shutdown命令時，若是沒有開啓AOF持久化功能則自動執行bgsave
• 執行流程：

• RDB文件處理：保存和壓縮並校驗

• RDB優勢：

  • 表明某個時間點的數據快照，適用備份和全量複製等場景
  • 壓縮的二進制文件，恢復「大數據集」效率較高

• RDB缺點：

  • 數據的實時持久化較差而且fork()操做會帶來堵塞
  • 特定的二進制文件會帶來兼容性問題

5-2.AOF方式

AOF持久化：以獨立日誌的方式記錄每次寫命令，重啓時再從新執行AOF文件中的命令達到恢復數據的目的，解決數據持久化的實時性

• AOF工做流程：

1.命令寫入以追加方式到AOF_buf
2.AOF緩衝區根據策略同步到AOF文件
3.隨着AOF文件變大，須要按期對AOF文件進行重寫，達到壓縮目的
4.當Redis重啓時，能夠加載AOF文件進行數據恢復

• 命令寫入追加到緩衝區的目的：

  • 寫入的內容是文件協議格式（1.兼容性；2.可讀性；3.避免二次處理開銷）
  • 在性能和安全性方面作出平衡

• 同步策略：Redis提供多種AOF緩衝區同步文件策略，由appendfsync控制

  • always：調用write操做後並調用fsync保證AOF文件寫入到磁盤中
  • no：調用write操做後，AOF文件同步到磁盤交由操做系統去實現
  • everysec：調用write操做後，由專門線程去每秒調用一次fsync

1. write操做：會觸發延遲寫機制，由於Linux在內核提供頁緩衝區來提供磁盤IO性能；write操做在寫入系統緩衝區後直接返回，同步硬盤依賴於系統調度機制
2. fsync操做：針對單個文件操做作強制硬盤同步，fsync將阻塞直到寫入硬盤完成後返回，保證了數據持久化

重寫機制：把Redis進程內的數據轉化爲命令同步到新AOF文件的過程，這個過程會讓AOF文件體積變小，從而提升恢復時的效率

1.進程已經超時的數據再也不寫入新文件
2.經過進程內數據直接生成，避免舊文件中的無效命令
3.多條命令能夠合併爲一個

AOF重寫觸發方式：
手動觸發：執行bgrewriteaof命令
自動觸發：同時知足如下2個條件

1. auto-aof-rewrite-min-size：表示運行AOF重寫時文件最小體積，默認爲64MB
2. auto-aof-rewrite-percentage：表示當前AOF文件空間和上一次重寫後AOF文件空間的比值

• AOF重寫工做流程

• Redis持久化加載流程

  1. AOF持久化開啓時且存在AOF文件時，優先加載AOF文件
  2. AOF關閉或者AOF文件不存在時，加載RDB文件
  3. 加載AOF/RDB文件成功後，Redis啓動成功
  4. AOF/RDB文件存在錯誤時，Redis啓動失敗

• 關於AOF文件異常

  • 損壞的文件Redis服務會拒絕啓動（能夠經過redis-check-aof-fix命令修復後，進行對比並進行手工修改補全）
  • 結尾不挖完整的文件Redis服務忽略並繼續啓動，同時打印報警信息

AOF追加阻塞：當開啓AOF持久化時，經常使用的同步磁盤策略是everysec，對於這種方式，Redis會使用同步條線程每秒執行fsync同步硬盤，當系統硬盤資源繁忙時，會形成Redis主線程阻塞
everysec刷盤策略過程：

1.同步線程負責每秒調用fsync操做進行同步磁盤
2.主進程會去對比上次fsync同步時間，若是在2s內則經過，不然會堵塞(磁盤資源緊張)
3.everysec策略最多可能丟失2s數據；若是系統fsync緩慢，會致使主進程堵塞

• AOF優勢：

  • 實時備份：可以到秒級
  • 以appen-only的模式寫入：沒有磁盤尋址開銷，寫入性能較高
  • 可讀性強：具備更靈活的處理方式

• AOF缺點：

  • 相同的數據集：AOF文件會比RDB文件大
  • Redis高負載狀況下：RDB會擁有更好的性能保證
  • 數據恢復：比較慢並不適合全量備份

6.複製

6-1.配置

• 創建複製的3種方式：

  • 配置文件：slaveof [masterHost] [masterPort]
  • 啓動命令：redis-server --slaveof [masterHost] [masterPort]
  • 直接命令：slaveof [masterHost] [masterPort]

• 斷開復制：命令1操做後從節點晉升爲主節點；命令2操做後能夠完成切主操做

  • 命令1：slaveof no none
  • 命令2：slaveof [newmasterHost] [newmasterPort]

• 安全性：主節點經過requirepass參數進行密碼驗證來保證數據安全性

  • 客戶端校驗：經過auth命令
  • 從節點校驗：經過masterauth參數
• 只讀：默認狀況下，從節點使用slave-read-only=yes配置爲只讀模式；由於從節點的數據沒法同步給主節點

• 傳輸延遲：主從節點通常部署在不一樣機器上，複製時的網絡延遲成爲須要考慮的問題

  • 當repl-disable-tcp-nodelay=yes時：表明關閉，主節點產生的命令不管大小都會及時發送給從節點，這樣作延遲會變小，可是增長了網絡帶寬消耗
  • 當repl-disable-tcp-nodelay=no時：表明開啓，主節點會合並比較小的TCP數據包從而節省網絡帶寬消耗，可是這樣增長了主從之間的延遲

6-2.複製原理

複製過程：

1.保存主節點信息：IP+Port
2.創建socket鏈接
3.發送ping命令：a）檢測socket是否可用；b）判斷主節點是否能處理命令
4.權限驗證
5.同步數據集：首次創建複製，主節點會把數據集所有發往從節點
6.命令持續複製：主節點把持續寫命令複製給從節點，保持數據一致性

全量複製過程

部門複製過程

• 心跳判斷：主從節點創建鏈接後保持長鏈接

  • 主節點默認每隔10s對從節點發送ping命令，判斷從節點的存活性和鏈接狀態（repl-ping-slave-period控制發送頻率）
  • 從節點在主線程每隔1s發送replconf ack {offset}命令，給主節點上報自身當前的複製偏移量
  • 若是超過repl-timeout配置的值（默認60秒），則斷定從節點下線並斷開復制客戶端鏈接

• 補充知識點：

  • Redis爲了保證高性能複製過程是異步的，寫命令處理完後直接返回給客戶端，不等待從節點複製完成。所以從節點數據集會有延遲狀況
  • 當使用從節點用於讀寫分離時會存在數據延遲、過時數據、從節點可用性等問題，須要根據自身業務提早做出規避
  • 在運維過程當中，主節點存在多個從節點或者一臺機器上部署大量主節點的狀況下，會有複製風暴的風險

7.阻塞

Redis是單線程架構：全部讀寫操做都是串行的而會致使阻塞問題

內在緣由：不合理使用API或數據結構、CPU飽和、持久化阻塞
外在緣由：CPU競爭，內存交換，網絡問題等

7-1.發現堵塞

• 登陸Redis：執行info，查看blocked_clients
• 執行redis-cli --latency -h -p 查看延時狀況

7-2.內在緣由

• 不合理使用API或數據結構：好比執行hgetall獲取的數據量會很是大

  • 獲取慢查詢：a) 修改成低複雜度命令；b) 調整大對象
  • 獲取Bigkey：redis-cli <ip+port> bigkeys（大於10K）
• CPU飽和：把單核CPU佔用率達到100%
• 持久化阻塞：a) fork阻塞；b）AOF刷盤阻塞；c) HugePage寫操做阻塞

7-3.外在緣由

• CPU競爭：其餘進程過分消耗CPU時，會影響Redis性能
• 內存交換：使用的部份內存換出到硬盤
• 網絡問題：a）網絡閃斷；b）鏈接拒絕；c）鏈接溢出

8.內存

8-1.內存消耗

重點指標：mem_fragmentation_ratio

mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss: 系統認爲Redis使用的物理內存
used_memory: 內部存儲的全部數據佔用量
當 mem_fragmentation_ratio > 1表示存在內存碎片
當 mem_fragmentation_ratio < 1表示存在交換內存

• Redis內存消耗劃分

  • 自身內存
  • 對象內存：用戶全部數據
  • 緩衝內存：客戶端緩衝/複製積壓緩衝/AOF緩衝
  • 內存碎片：頻繁更新操做或大量過時鍵刪除致使釋放的空間沒法利用
• 子進程內存消耗：指AOF/RDB重寫時Redis建立的子進程複製內存的消耗
• THP機制：雖然能夠下降fork子進程的速度，但複製內存頁的單位會從4KB變爲2MB，若是父進程有大量寫命令，會加劇內存拷貝量

8-2.內存管理

Redis使用maxmemroy參數限制最大可用內存，限制內存的主要目的：

1.緩存場景：當超過內存上限時根據淘汰策略刪除鍵釋放內存
2.防止所用內存超過物理內存（限制的是used_memory；因此考慮內存溢出）

內存回收策略

• 刪除過時鍵帶有

  • 惰性刪除：若是存在過時鍵，當客戶單請求到的時候進行刪除並返回空
  • 定時任務刪除：默認每秒運行10次（經過配置hz控制）；刪除過時鍵邏輯採用自適應算法，根據鍵的過時比例，使用快慢兩種速率模式回收鍵

• 內存溢出控制策略：當達到maxmemory自動觸發

  • noeviction：默認策略，不刪除任何數據，拒絕全部寫入操做並返回客戶端錯誤信息
  • volatile-lru：根據LRU算法刪除設置超時屬性的鍵
  • volatile-random：隨機刪除過時鍵
  • allkeys-lru：根據LRU算法隨機刪除鍵
  • allkeys-random：隨機刪除全部鍵
  • volatile-ttl：根據鍵對象的ttl屬性刪除最近將要過時數據

1.關於volatile-lru和volatile-ttl控制策略：若是沒有，會回退到noeviction控制策略
2.在Redis的LRU算法中：能夠經過設置樣本的數量來調優算法精度(參數： maxmemory-samples 5->10)

8-3.內存優化

內存優化總結

1.精簡鍵值對大小，鍵值字面量精簡，使用高效二進制序列化工具。
2.使用對象共享池優化小整數對象。
3.數據優先使用整數，比字符串類型更節省空間。
4.優化字符串使用，避免預分配形成的內存浪費。
5.使用ziplist壓縮編碼優化hash、list等結構，注重效率和空間的平衡。
6.使用intset編碼優化整數集合。
7.使用ziplist編碼的hash結構下降小對象鏈規

9.高可用架構

主從架構問題：

1. 當主節點出現故障，須要手動晉升新的主節點
2. 主節點的寫能力受單機限制
3. 主節點的存儲能力受單機限制

Sentinel架構問題：

1. 系統架構變複雜後，較難支持在線擴容
2. 主節點的存儲能力受單機限制

Cluster架構問題

1. 部分功能受限（key批量操做，key事務操做等等）

9-1.Sentinel

Sentinel節點集合會按期對全部節點進行監控，從而實現主從的故障自動轉移

• 監控任務

  • 每隔10s：每一個Sentinel節點會向master節點執行info命令獲取最新的拓撲信息
  • 每隔2s：每一個Sentinel節點會向Redis數據節點的__sentinel__頻道發送消息而發現新Sentinel節點及交換主節點狀態
  • 每隔1s：每一個Sentinel節點會向其餘數據節點和Sentinel節點發送ping命令來進行心跳檢測

• 主觀下線和客觀下線

  • 主觀下線：任意Sentinel節點進行心跳檢測時在超時時間內沒有收到響應消息即判斷該數據節點下線
  • 客觀下線：全部Sentinel節點的判斷票超過quorum個數後，即認爲該數據節點下線

• 領導Sentinel節點選舉：故障轉移工做的執行者

  • 採用Raft算法進行選舉，通常來講哪一個Sentinel節點發現客觀下線狀況就會成爲執行者

• 故障轉移過程：

  1. 執行者在從列表中選舉出一個節點做爲新節點：優先級 > 複製偏移量 > Runid小的
  2. 執行者對新節點執行slave no one命令讓其成爲主節點
  3. 執行者向其餘節點發送命令，讓其成爲新主節點的從節點
  4. Sentinel集合將原來的主節點更新爲從節點（恢復後不搶佔）
• 讀寫分離：將Slave節點集合做爲「讀」資源鏈接池，依賴Sentinel節點的消息通知，獲取Redis節點的狀態變化

9-2.Cluster

• 數據分佈：Redis Cluser採用虛擬槽分區，全部的鍵根據哈希函數映射到0~16383整數槽內，計算公式：slot=CRC16（key）&16383。每個節點負責維護一部分槽以及槽所映射的鍵值數據
• Gossip協議：節點間不斷通訊交換信息，一段時間後全部節點都會知道整個集羣的元數據信息

• Gossip消息分類：ping/pong/meet/fail

  • meet消息：用於新節點加入
  • ping消息：用於檢測節點是否在線和交換彼此狀態信息
  • pong消息：當接收到ping和meet消息時，做爲響應消息回覆
  • fail消息：當節點斷定集羣內另外一個節點下線時，會向集羣內廣播一個fail消息
• 通訊節點選擇規則：

• 集羣伸縮：槽和數據在節點之間的移動；當有新節點加入的時候，每一個節點負責的槽和數據會遷移一部分給新節點；反之亦然

• 請求路由：使用客戶端去操做集羣

  • 請求重定向：Redis首先計算鍵對應的槽，再根據槽找出對應的節點，若是是自身節點，則執行命令，不然恢復MOVED重定向發送鍵命令到目標節點（返回key所對應的槽並不負責轉發）
• Smart客戶端：內部維護slot-node映射關係，本地實現鍵到節點的查找，而MOVE重定向只負責維護客戶端的映射關係，減小每次都須要redis節點的命令執行重定向帶來的IO開銷

故障轉移

• 故障發現：經過ping/pong消息實現節點通訊

  • 主觀下線：某個節點認爲另外一個節點不可用（標記爲下線狀態）
  • 客觀下線：多個節點認爲另外一個節點不可用（標記爲不可用）

• 恢復流程：

  1. 資格檢查：檢查最後與主節點斷線時間
  2. 準備選舉時間：延遲觸發機制，經過offset判斷從節點優先級
  3. 發起選舉：更配置紀元標識本次從節點選舉的版本
  4. 選舉投票：從節點擁有N/2+1個主節點票時，能夠執行替換操做
  5. 替換主節點：負責故障主節點的槽並向集羣廣播次消息

開發和運維常見問題：：超大規模集羣帶寬消耗， pub/sub廣播問題，集羣節點傾斜問題，手動故障轉移，在線遷移數據等

10.緩存設計

緩存收益：a）加速速度；b）減小後端負載
緩存成本：a）數據不一致性；b）代碼維護；c）運維
緩存場景：a）開銷大的複雜計算；b）加速請求響應

10-1.緩存更新策略

LRU/LFU/FIFO算法剔除：緩存使用量超過設定的最大值（ maxmemory-policy配置剔除策略）
超時剔除：緩存數據設置過時時間
主動更新：數據一致性要求高，須要真實數據更新後立馬更新緩存數據

• 最佳實踐

  • 低一致性業務建議設置最大內存和淘汰策略的方式使用
  • 高一致性業務建議結合超時剔除和主動更新

10-2.緩存穿透

緩存穿透：查詢一個根本不存在的數據，致使不存在的數據每次請求都要到存儲層去查詢，會使後端存儲負載加大
基本緣由：

1.自身業務代碼或者數據出現問題
2.惡意攻擊、爬蟲等形成大量空命中

解決辦法：

1.緩存空對象
2.布隆過濾器

10-3.緩存雪崩

緩存雪崩：緩存層宕掉後，流量會忽然所有打到後端存儲
預防和解決緩存雪崩問題：

1.保證緩存層服務高可用性
2.依賴隔離組件爲後端限流並降級

10-4.無底洞問題

10-5.熱點key重建

問題緣由：當前key是一個熱點key，併發量很是大而重建緩存又不能在短期內完成
解決辦法：互斥鎖、「永遠不過時」可以在必定程度上解決熱點key問題

11.其餘

11-1.Linux配置優化

內存分配控制優化：

1.Redis設置合理的 maxmemory，保證機器有20%~30%的限制內存
2.設置 vm.overcommit_memory=1，防止極端狀況下形成fork失敗

Swap交換內存優化：當物理內存不足時，系統會使用swap致使磁盤IO會成爲性能瓶頸

權值越大，使用swap機率越高：0-100 默認60:
echo "vm.swappiness={bestvalue}" >> /etc/sysctl.conf

OMM killer： 當內存不足時選擇性殺死進程

下降redis優先級:
echo {value} > /proc/{pid}/oom_adj

Transparent Huge Pages：雖然能夠加快fork操做，可是寫時內存copy消耗從4KB-2MB

關閉大頁:
echo never > /sys/kernel/mm/transparent_hugepage/enabled

打開文件描述符：

由於 openfile優先級大於 redis maxclients
/etc/rc.local配置文件中： ulimit -Sn {max-open-files}

Tcp backlog: Tcp鏈接隊列長度

調高全鏈接隊列值：默認是511
echo 10000 > /proc/sys/net/core/somaxconn

11-2.誤操做恢復

• AOF機制恢復：文件中有追加記錄；恢復時，將AOF文件中的fulshall相關操做去掉，而後使用redis-check-aof工具校驗和修復一下AOF文件；若是發生AOF重寫，意味着以前的數據就丟掉了
• RDB機制恢復：文件中依然有追加記錄；要注意：防止bgsave命令執行，這樣舊的RDB文件會被覆蓋；若是開啓RDB自動策略，flush涉及鍵值數量較多，RDB文件會被清除，這樣恢復就無望

快速恢復數據：

1.防止AOF重寫
2.去掉AOF文件中的flush相關內容
3.重啓Redis服務器，恢復數據

11-3.Bigkey問題

危害：

1.網絡擁塞
2.超時堵塞
3.內存空間不均勻

定位：找到鍵的serializedlength信息，而後判斷指定鍵值的大小

1. debug object key
2. strlen key
3.主動檢測： scan+debug object；而後檢測每一個鍵值的長度
補充：使用 redis-cli -h[ip] -p[port] bigkeys命令（內部進行scan操做，把歷史掃描過的最大對象統計出來）

優雅刪除：直接刪除全部bigkey可能會致使堵塞

能夠結合Python的RedisAPI編寫腳本去實現：
1. hash key：經過 hscan命令，每次獲取500個字段，再用 hdel命令
2. set key：使用 sscan命令，每次掃描集合中500個元素，再用 srem命令每次刪除一個元素；
3. list key：刪除大的List鍵，經過 ltrim命令每次刪除少許元素。
4. sorted set key：刪除大的有序集合鍵，和List相似，使用sortedset自帶的 zremrangebyrank命令,每次刪除top 100個元素。
後臺刪除： lazyfree機制

11-4.分佈式鎖

11-5.安全建議

1. 根據具體網絡環境決定是否設置Redis密碼
2. rename-command能夠假裝命令，可是要注意成本
3. 合理的防火牆是防止攻擊的利器
4. bind能夠將Redis的訪問綁定到指定網卡上
5. 按期備份數據應該做爲習慣性操做
6. 能夠適當錯開Redis默認端口啓動
7. 使用非root用戶啓動Redis

參考

• 《Redis開發與運維》