來源：點我達技術

redis查看數據庫命令，http://tech.dianwoda.com/

redis從2009年誕生到現在已經走過將近10年，從最開始大家在討論nosql和傳統關系數據庫孰優孰劣，到現在大家談起分布式鎖，緩存紛紛將Redis作為其第一選擇，服務端面試中Redis也作為一項必備能力，而如今Redis 5.0已經發布，越來越多的新特性被加入，我完整的觀察到并參與了一項新的開源產品從走入大家的視野到被接受，之后再流行的整個過程，也同時見證了memcache的日薄西山。
但是在工作中發現很多人只是了解一些Redis的基本使用，也并未完整的閱讀過Redis的官方文檔，對于一些命令不熟悉，不同場景下濫用不合理的數據結構，對一些新的特性似乎也不會去關注。鑒于自己對Redis的一些了解和實踐經驗，并收集了網絡上一些資料，總結了一些使用建議。

特性

1、SET key value [expiration EX seconds|PX milliseconds][NX|XX]

• Redis 2.6.12版本后的Set命令支持過期時間等參數，不必再像以前一樣分為set和expire兩個命令

2、bitmap

• 適用于大量數據的位圖信息標記，例如如果要標記大量用戶的某個狀態值，可以考慮使用bitmap
• bitmap的另外一個應用是基于redis的bloom filter

3、stream

• Redis4開始提供的新的數據結構，可以理解成輕量級的kafka steam，主要解決了pub/sub無法保證通知處理成功和blocked list無法多個client消費的問題，具體點擊此處查看topic。
• 如果想實現一個簡單的聊天室，可以嘗試下steam。

使用建議

1、合理分配過期時間

• 不管是將Redis作為緩存，還是存儲，如果不愿意看到內存被慢慢消耗殆盡，最后只能擴容或者人工介入，就給自己的key設置一個合理的過期時間。當把Redis作為緩存時，更要預估自己的數據量和數據大小，選擇一個合理的過期時間。

2、多個操作使用pinepine

• 這是Redis使用中的一項基本原則，同時需要知道，另外如果下一個命令的input基于上一個命令的output，就不可以放到一個pipeline里面執行了
• 使用時考慮pipeline中一個命令執行失敗的場景，后面的命令未執行是否因為一致性帶來問題

3、使用命名空間

• 方便key的管理，我們開發中常用的redis-desktop客戶端能夠按照命名空間對key進行展示，另外，命名空間方便需要對某一類key進行統計和管理
• 如果需要通過key進行分片，命名空間可以作為分片參數

4、選用合適的數據結構

• 理解每個數據結構的用途，和常用的命令，我曾經見過開發人員因為不知道scard命令可以獲得set的size，而將所有的元素取出然后在程序中計算，所以需要平時多查看Redis命令文檔；如果能夠理解每種數據結構背后的原理，使用時會更加得心應手。
• 不建議使用Redis緩存單個數據大小較大的對象，尤其是使用Set，Hash此類數據結構時候，考慮到Redis是單線程，過多的大對象訪問增加了網絡IO壓力，對Redis性能有一定影響，另一方面Redis的虛擬內存page較小，如果內存碎片率較高，則分配/申請內存時在性能上有些影響。如果要緩存較大的對象，可以考慮memcache

5、禁用keys

• 很基本的Redis使用常識，可以通過rename-command來將一些類似的命令重命名，實現disable的效果

6、選用lua script

• 如果要保證多個操作的原子性，可以選擇使用lua腳本

7、config set parameter value

• redis 2.0后提供了config set 命令來動態修改一些運行參數而不必重啟redis，目前已經支持動態修改maxmemory，可以通過CONFIG GET * 查看支持動態修改的參數列表

最佳實踐

1、key的命名

• 合理的命名自己的key，不能在查看數據時可讀性更強，也更便于統計和管理

2、key name的長度

• 預估key的存活數量，如果key的數量可能達到百萬級別，就需要考慮key的名字過長而導致占用太多的存儲空間，我在曾經參與過的一個消息系統中使用redis存儲消息閱讀量，但是后面由于消息量過多，導致name的占用空間達到幾百M，如果精簡name，可以節省大量的空間，減少不必要的困擾。例如，保存用戶的基本信息可以使用u:${id}

3、不濫用Lua Script

• 由于Redis是單線程，在QPS很高的情況下，過多的lua腳本執行，特別是內部包含較多業務邏輯處理的情況下，會對Redis性能產生很大的影響。曾經參與過的直播業務的生產環境中，我們在Lua腳本中對送禮物觸發的的積分和活動信息的有較多的邏輯處理(20行左右)，導致Redis負載100%，所以在排查時Lua腳本有可能是負載較高的元兇之一。

4、關注內存和slowlog等統計數據

• 通過info memory查看內存的分配和使用大小，碎片等情況
• slowlog get N 查看最近幾條執行較慢的命令
• 通過redis-cli --bigkeys 通過采樣scan元素較多的key，不會一直阻塞redis執行
• 更多好玩的redis-cli命令可以查看此處monitor命令不建議生產環境使用

面對一款優秀開源產品，我們除了要了解它的基本使用，也要擅于運用才能更好發揮其作用，否則會有不必要的麻煩，甚至適得其反。當然如果能深入了解其內部運行機制，知其然并知其所以然，并基于此創造出更加優秀的開源產品，就更符合coder的hacker精神。