從2023年誕生到現在已經走過將近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
使用時考慮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:$
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 的一些新特性 使用建議和最佳實踐
redis從2009年誕生到現在已經走過將近10年，從最開始大家在討論nosql和傳統關聯式資料庫孰優孰劣，到現在大家談起分布式鎖，快取紛紛將redis作為其第一選擇，服務端面試中redis也作為一項必備能力，而如今redis 5.0已經發布，越來越多的新特性被加入，我完整的觀察到並參與了一項新的開...
關於python的一些特性
首先，我其實得說說為什麼我們會選擇python。在我加入企業快盤團隊之前，整個專案包括更早的金山快盤都是採用python進行開發的。至於為什麼這麼選擇，當時的架構師蔥頭告訴我，主要是因為python上手簡單，開發迅速。對於團隊裡面大部分完全沒服務端開發經驗的同學來說，python真的是乙個很好的選擇...
關於 ES7 ES8的一些新特性
array.prototype.includes 開發人員用來檢查陣列中是否存在值，indexof是一種尷尬的使用，因為它返回乙個元素在陣列中的位置或者 1當這樣的元素不能被找到的情況下。所以它返回乙個數字，而不是乙個布林值，includes存在為true,不存在為false 例子 陣列 1,2,3...