官方文件繁瑣難讀？看本文輕鬆聚焦Redis 5.0新特性
Redis從2009年誕生到現在已經走過將近10年，從最開始大家在討論NoSQL和傳統關係資料庫孰優孰劣，到現在大家談起分散式鎖、快取，紛紛將Redis作為其第一選擇，服務端面試中Redis也作為一項必備能力。
如今Redis5.0已經發布，越來越多的新特性被加入，我完整地觀察到並參與了一項新的開源產品從走入大家的視野到被接受，之後再流行的整個過程，也同時見證了Memcache的日薄西山。
但是在工作中發現，很多人只是瞭解一些Redis的基本使用，也並未完整閱讀過Redis的官方文件，對於一些命令不熟悉，不同場景下濫用不合理的資料結構，對一些新的特性似乎也不會去關注。
鑑於自己對Redis的一些瞭解和實踐經驗，並收集了網路上一些資料，總結了一些使用建議。
一、特性
SET key value [expiration EX seconds|PX milliseconds][NX|XX]
Redis 2.6.12版本後的Set命令支援過期時間等引數，不必再像以前一樣分為set和expire兩個命令。
1、bitmap
適用於大量資料的點陣圖資訊標記，例如如果要標記大量使用者的某個狀態值，可以考慮使用bitmap；bitmap的另外一個應用是基於Redis的bloom filter。
https://github.com/Baqend/Orestes-Bloomfilter
2、stream
Redis4開始提供的新的資料結構，可以理解成輕量級的kafka steam，主要解決了pub/sub無法保證通知處理成功和blocked list無法多個client消費的問題。
https://redis.io/topics/streams-intro
如果想實現一個簡單的聊天室，可以嘗試下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命令文件：
-
不建議使用Redis快取單個數據大小較大的物件，尤其是使用Set，Hash此類資料結構時候，考慮到Redis是單執行緒，過多的大物件訪問增加了網路IO壓力，對Redis效能有一定影響，另一方面Redis的虛擬記憶體page較小，如果記憶體碎片率較高，則分配/申請記憶體時在效能上有些影響。如果要快取較大的物件，可以考慮Memcache。
5、禁用keys
很基本的Redis使用常識，可以通過rename-command來將一些類似的命令重新命名，實現disable的效果。
6、選用lua script
如果要保證多個操作的原子性，可以選擇使用lua指令碼。
7、config set parameter value
Redis2.0後提供了config set命令來動態修改一些執行引數而不必重啟Redis，目前已經支援動態修改maxmemory，可以通過CONFIGGET*檢視支援動態修改的引數列表。
三、最佳實踐
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精神。