通俗易懂的講，Big Key就是某個key對應的value很大，佔用的redis空間很大，本質上是大value問題。 key往往是程式可以自行設定的，value往往不受程式控制，因此可能導致value很大。
redis中這些Big Key對應的value值很大，在序列化/反序列化過程中花費的時間很大，因此當我們操作Big Key時，通常比較耗時，這就可能導致redis發生阻塞，從而降低redis效能。
用幾個實際的例子對大Key的特徵進行描述：
● 一個String類型的Key，它的值為5MB（資料過大）；
# ●一個List類型的Key，它的列表數量為20000個（列表數量過多）；
● 一個ZSet類型的Key，它的成員數量為10000個（成員數量過多）；
● 一個Hash格式的Key，它的成員數量雖然只有1000個但這些成員的value總大小為100MB（成員體積過大）；
二、Big Key產生的場景？##在實際業務中，大Key的判定仍需要根據Redis的實際使用場景、業務場景來進行綜合判斷。通常都會以資料大小與成員數量來判定。
1、redis資料結構使用不恰當
將Redis用在不適合其能力的場景，造成Key的value過大，如使用String類型的Key存放大體積二進位檔案型資料。2、未及時清理垃圾資料
由於未定期清理無效數據，導致HASH類型鍵中的成員不斷增加。 Value將無限增大，因為它只會不斷接收資料而沒有任何刪除機制。3、對業務預估不準確
業務上線前規劃設計考慮不足沒有對Key中的成員進行合理的拆分，造成個別Key中的成員數量過多。4、明星、網紅的粉絲列表、某條熱點新聞的評論列表
假設我們使用List資料結構來保存某個明星/網紅的粉絲，或保存熱點新聞的評論列表，因為粉絲數量龐大，熱點新聞因為點擊率、評論數會很多，這樣List集合中存放的元素就會很多，可能導致value過大，進而產生Big Key問題。 三、Big Key的危害？1、阻塞請求
Big Key對應的value較大，我們對其進行讀寫的時候，需要耗費較長的時間，這樣就可能阻塞後續的請求處理。 Redis的核心執行緒是單執行緒的，這表示所有請求將會進行串列處理，如果前面的請求沒有完成，後面的請求將無法處理。2、記憶體增加
讀取Big Key耗費的記憶體比正常Key會增加大，如果不斷變大，可能會引發OOM（內存溢位），或達到redis的最大記憶體maxmemory設定值引發寫入阻塞或重要Key被逐出。3、阻塞網路
讀取單value較大時會佔用伺服器網路卡較多頻寬，自身變慢的同時可能會影響該伺服器上的其他Redis實例或應用程式。4、影響主從同步、主從切換
刪除一個大Key造成主庫較長時間的阻塞並引發同步中斷或主從切換。 四、如何辨識Big Key？1、使用redis自帶的命令識別
例如可以使用Redis官方客戶端redis-cli加上--bigkeys參數，可以找到某個實例5種資料類型(String、hash、list、set、zset)的最大key。 優點是可以在線上掃描，不阻塞服務；缺點是資訊較少，內容不夠精確。
2、使用debug object key指令
根據傳入的物件（Key的名稱）來對Key進行分析並傳回大量數據，其中serializedlength的值為此Key的序列化長度，需要注意的是，Key的序列化長度並不等同於它在記憶體空間中的真實長度，此外，debug object屬於調試命令，運行代價較大，並且在其運行時，進入Redis的其餘請求將會被阻塞直到其執行完畢。且每次只能查找單一key的信息，官方不建議使用。3、redis-rdb-tools開源工具
#這種方式是在redis實例上執行bgsave，bgsave會觸發redis的快照備份，產生rdb持久化文件，然後對dump出來的rdb文件進行分析，找到其中的大key。 優點在於取得的key資訊詳細、可選參數多、支援客製化需求，結果資訊可選擇json或csv格式，後續處理方便，其缺點是需要離線操作，取得結果時間較長。 五、如何解決Big Key問題？ 要解決Big Key問題，無非是減少key對應的value值的大小，也就是對於String資料結構的話，減少儲存的字串的長度；對於List、Hash、Set、ZSet資料結構則是減少集合中元素的個數。1、對大Key進行分割#
Split a Big Key into multiple small Keys such as key-value, and ensure that the number or size of each key is within a reasonable range, and then store it, by getting different keys or using mget to obtain them in batches .
2. Clean up the big keys
Clean up the big keys in Redis and delete such data from Redis. Redis has provided the UNLINK command since 4.0, which can slowly and gradually clean up incoming keys in a non-blocking manner. Through UNLINK, you can safely delete large keys or even extra-large keys.
3. Monitor Redis’s memory, network bandwidth, timeout and other indicators
By monitoring the system and setting reasonable Redis memory alarm thresholds to remind us that there may be large events at this time Key is being generated, such as: Redis memory usage exceeds 70%, Redis memory growth rate exceeds 20% within 1 hour, etc.
4. Regularly clean up invalid data
Accumulation of a large amount of invalid data will occur. If a certain Key has been writing a large amount of data incrementally, but ignored it Data timeliness. Invalid data can be cleaned up through scheduled tasks.
5. Compress value
Use serialization and compression algorithms to control the size of the key, but it should be noted that both serialization and deserialization will cause certain performance consumption. If the value is still very large after compression, you can consider further splitting the key.
(1)[Recommendation]: Readability and manageability
Prefix with the business name (or database name) (to prevent key conflicts), separated by colons, such as business name: table name: id
o2o:order:1
(2) [Suggestion]: Simplicity
Under the premise of ensuring semantics, control the length of the key. When there are many keys, the memory usage cannot be ignored. For example:
user:{uid}:friends:messages:{mid} is simplified to u:{uid} m:{mid}
(3)[Mandatory]: Do not include special characters
Counter example: include spaces, newlines, single and double quotes, and other escape characters
以上是Redis中怎麼解決Big Key問題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
