一、鍵值設計
1. key名設計
(1)【建議】: 可讀性和可管理性
以業務名(或數據庫名)為前綴(防止key沖突)，用冒號分隔，比如業務名:表名:id
(2)【建議】：簡潔性
保證語義的前提下，控制key的長度，當key較多時，內存占用也不容忽視，例如：
(3)【強制】：不要包含特殊字符
反例：包含空格、換行、單雙引號以及其他轉義字符
2. value設計
(1)【強制】：拒絕bigkey(防止網卡流量、慢查詢)
string類型控制在10KB以內，hash、list、set、zset元素個數不要超過5000。
反例：一個包含200萬個元素的list。
非字符串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除，同時要注意防止bigkey過期時間自動刪除問題(例如一個200萬的zset設置1小時過期，會觸發del操作，造成阻塞，而且該操作不會不出現在慢查詢中(latency可查))，查找方法和刪除方法
(2)【推薦】：選擇適合的數據類型。
例如：實體類型(要合理控制和使用數據結構內存編碼優化配置,例如ziplist，但也要注意節省內存和性能之間的平衡)
反例：
正例:
(3)【推薦】：控制key的生命周期，redis不是垃圾桶。
建議使用expire設置過期時間(條件允許可以打散過期時間，防止集中過期)，不過期的數據重點關注idletime。
二、命令使用
1.【推薦】 O(N)命令關注N的數量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明確N的值。有遍歷的需求可以使用hscan、sscan、zscan代替。
2.【推薦】：禁用命令
禁止線上使用keys、flushall、flushdb等，通過redis的rename機制禁掉命令，或者使用scan的方式漸進式處理。
3.【推薦】合理使用select
redis的多數據庫較弱，使用數字進行區分，很多客戶端支持較差，同時多業務用多數據庫實際還是單線程處理，會有干擾。
4.【推薦】使用批量操作提高效率
原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。
但要注意控制一次批量操作的元素個數(例如500以內，實際也和元素字節數有關)。
注意兩者不同：
- 原生是原子操作，pipeline是非原子操作。
- pipeline可以打包不同的命令，原生做不到
- pipeline需要客戶端和服務端同時支持。
5.【建議】Redis事務功能較弱，不建議過多使用
Redis的事務功能較弱(不支持回滾)，而且集群版本(自研和官方)要求一次事務操作的key必須在一個slot上(可以使用hashtag功能解決)
6.【建議】Redis集群版本在使用Lua上有特殊要求：
1.所有key都應該由 KEYS 數組來傳遞，redis.call/pcall 里面調用的redis命令，key的位置，必須是KEYS array, 否則直接返回
error，"-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array"
2.所有key，必須在1個slot上，否則直接返回
error, "-ERR eval/evalsha command keys must in same slot"
7.【建議】必要情況下使用monitor命令時，要注意不要長時間使用。
三、客戶端使用
1.【推薦】
避免多個應用使用一個Redis實例
正例：不相干的業務拆分，公共數據做服務化。
2.【推薦】
使用帶有連接池的數據庫，可以有效控制連接，同時提高效率：
3.【建議】
高并發下建議客戶端添加熔斷功能(例如netflix hystrix)
4.【推薦】
設置合理的密碼，如有必要可以使用SSL加密訪問（阿里云Redis支持）
5.【建議】
根據自身業務類型，選好maxmemory-policy(最大內存淘汰策略)，設置好過期時間。
默認策略是volatile-lru，即超過最大內存后，在過期鍵中使用lru算法進行key的剔除，保證不過期數據不被刪除，但是可能會出現OOM問題。
其他策略如下：
allkeys-lru：根據LRU算法刪除鍵，不管數據有沒有設置超時屬性，直到騰出足夠空間為止。
allkeys-random：隨機刪除所有鍵，直到騰出足夠空間為止。
volatile-random:隨機刪除過期鍵，直到騰出足夠空間為止。
volatile-ttl：根據鍵值對象的ttl屬性，刪除最近將要過期數據。如果沒有，回退到noeviction策略。
noeviction：不會剔除任何數據，拒絕所有寫入操作并返回客戶端錯誤信息"(error) OOM command not allowed when used memory"，此時Redis只響應讀操作。
bigkey
【強制】：拒絕bigkey(防止網卡流量、慢查詢)
string類型控制在10KB以內，hash、list、set、zset元素個數不要超過5000。
反例：一個包含200萬個元素的list。
非字符串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除，同時要注意防止bigkey過期時間自動刪除問題(例如一個200萬的zset設置1小時過期，會觸發del操作，造成阻塞，而且該操作不會出現在慢查詢中(latency可查))
一、什么是bigkey
在Redis中，一個字符串最大512MB，一個二級數據結構（例如hash、list、set、zset）可以存儲大約40億個(2^32-1)個元素，但實際上中如果下面兩種情況，我就會認為它是bigkey。
- 字符串類型：它的big體現在單個value值很大，一般認為超過10KB就是bigkey。
- 非字符串類型：哈希、列表、集合、有序集合，它們的big體現在元素個數太多。
二、危害
bigkey可以說就是Redis的老鼠屎，具體表現在：
1.內存空間不均勻：這樣會不利于集群對內存的統一管理，存在丟失數據的隱患。
2.超時阻塞：由于Redis單線程的特性，操作bigkey的通常比較耗時，也就意味著阻塞Redis可能性越大，這樣會造成客戶端阻塞或者引起故障切換，它們通常出現在慢查詢中。
例如，在Redis發現了這樣的key，你就等著DBA找你吧。。
127.0.0.1:6379> hlen big:hash(integer) 2000000 127.0.0.1:6379> hgetall big:hash 1) "a" 2) "1" 此處省略400萬行
3.網絡擁塞：
bigkey也就意味著每次獲取要產生的網絡流量較大，假設一個bigkey為1MB，客戶端每秒訪問量為1000，那么每秒產生1000MB的流量，對于普通的千兆網卡(按照字節算是128MB/s)的服務器來說簡直是滅頂之災，而且一般服務器會采用單機多實例的方式來部署，也就是說一個bigkey可能會對其他實例造成影響，其后果不堪設想。
4.過期刪除：
有個bigkey，它安分守己（只執行簡單的命令，例如hget、lpop、zscore等），但它設置了過期時間，當它過期后，會被刪除，如果沒有使用Redis 4.0的過期異步刪除(lazyfree-lazy-expire yes)，就會存在阻塞Redis的可能性，而且這個過期刪除不會從主節點的慢查詢發現（因為這個刪除不是客戶端產生的，是內部循環事件，可以從latency命令中獲取或者從slave節點慢查詢發現）。
5.遷移困難：
當需要對bigkey進行遷移（例如Redis cluster的遷移slot），實際上是通過migrate命令來完成的，migrate實際上是通過dump + restore + del三個命令組合成原子命令完成，如果是bigkey，可能會使遷移失敗，而且較慢的migrate會阻塞Redis。
三、怎么產生的？
一般來說，bigkey的產生都是由于程序設計不當，或者對于數據規模預料不清楚造成的，來看幾個：
(1) 社交類：粉絲列表，如果某些明星或者大v不精心設計下，必是bigkey。
(2) 統計類：例如按天存儲某項功能或者網站的用戶集合，除非沒幾個人用，否則必是bigkey。
(3) 緩存類：將數據從數據庫load出來序列化放到Redis里，這個方式非常常用，但有兩個地方需要注意，第一，是不是有必要把所有字段都緩存，第二，有沒有相關關聯的數據。
例如我之前遇到過一個例子，該同學將某明星一個專輯下所有視頻信息都緩存一個巨大的json中，造成這個json達到6MB，后來這個明星發了一個官宣。。。這個我就不多說了，領盒飯去吧。
四、如何發現
1.redis-cli --bigkeys
redis-cli提供了--bigkeys來查找bigkey，例如下面就是一次執行結果：
-------- summary ------- Biggest string found 'user:1' has 5 bytes Biggest list found 'taskflow:175448' has 97478 items Biggest set found 'redisServerSelect:set:11597' has 49 members Biggest hash found 'loginUser:t:20180905' has 863 fields Biggest zset found 'hotkey:scan:instance:zset' has 3431 members 40 strings with 200 bytes (00.00% of keys, avg size 5.00) 2747619 lists with 14680289 items (99.86% of keys, avg size 5.34) 2855 sets with 10305 members (00.10% of keys, avg size 3.61) 13 hashs with 2433 fields (00.00% of keys, avg size 187.15) 830 zsets with 14098 members (00.03% of keys, avg size 16.99)
可以看到--bigkeys給出了每種數據結構的top 1 bigkey，同時給出了每種數據類型的鍵值個數以及平均大小。
--bigkeys對問題的排查非常方便，但是在使用它時候也有幾點需要注意。
- 建議在從節點執行，因為--bigkeys也是通過scan完成的。
- 建議在節點本機執行，這樣可以減少網絡開銷。
- 如果沒有從節點，可以使用--i參數，例如(--i 0.1 代表100毫秒執行一次)
- --bigkeys只能計算每種數據結構的top1，如果有些數據結構非常多的bigkey，也搞不定，畢竟不是自己寫的東西嘛
- debug object
再來看一個場景：
你好，麻煩幫我查一下Redis里大于10KB的所有key
您好，幫忙查一下Redis中長度大于5000的hash key
是不是發現用--bigkeys不行了（當然如果改源碼也不是太難），但有沒有更快捷的方法，Redis提供了debug object ${key}命令獲取鍵值的相關信息：
127.0.0.1:6379> hlen big:hash (integer) 5000000 127.0.0.1:6379> debug object big:hash Value at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625559 lru_seconds_idle:2 (1.08s)
其中serializedlength表示key對應的value序列化之后的字節數，當然如果是字符串類型，完全看可以執行strlen，例如：
127.0.0.1:6379> strlen key (integer) 947394
這樣你就可以用scan + debug object的方式遍歷Redis所有的鍵值，找到你需要閾值的數據了。
但是在使用debug object時候一定要注意以下幾點：
(1) debug object bigkey本身可能就會比較慢，它本身就會存在阻塞Redis的可能
(2) 建議在從節點執行
(3) 建議在節點本地執行
(4) 如果不關系具體字節數，完全可以使用scan + strlen|hlen|llen|scard|zcard替代，他們都是o(1)
3 memory usage
上面的debug object可能會比較危險、而且不太準確（序列化后的長度），有沒有更準確的呢？Redis 4.0開始提供memory usage命令可以計算每個鍵值的字節數（自身、以及相關指針開銷，具體的細節后面有文章會分析），例如下面是一次執行結果：
127.0.0.1:6379> memory usage big:hash (integer) 318663444
下面我們來對比就可以看出來，當前系統就一個key，總內存消耗是400MB左右，memory usage相比debug object還是要精確一些的。
127.0.0.1:6379> dbsize (integer) 1 127.0.0.1:6379> hlen big:hash (integer) 5000000 #約300MB 127.0.0.1:6379> memory usage big:hash (integer) 318663444 #約85MB 127.0.0.1:6379> debug object big:hash Value at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625814 lru_seconds_idle:9 (1.06s) 127.0.0.1:6379> info memory # Memory used_memory_human:402.16M
如果你使用Redis 4.0+，你就可以用scan + memory usage(pipeline)了，而且很好的一點是,memory不會執行很慢，當然依然是建議從節點 + 本地 。
4.客戶端
上面三種方式都有一個問題，就是馬后炮，如果想很實時的找到bigkey，一方面你可以試試修改Redis源碼，還有一種方式就是可以修改客戶端，以jedis為例，可以在關鍵的出入口加上對應的檢測機制，例如以Jedis的獲取結果為例子：
protected Object readProtocolWithCheckingBroken() {
Object o = null;
try {
o = Protocol.read(inputStream);
return o;
}catch(JedisConnectionException exc) {
UsefulDataCollector.collectException(exc, getHostPort(), System.currentTimeMillis());
broken = true;
throw exc;
}finally {
if(o != null) {
if(o instanceof byte[]) {
byte[] bytes = (byte[]) o;
if (bytes.length > threshold) {
// 做很多事情，例如用ELK完成收集和展示
}
}
}
}
}
5.監控報警
bigkey的大操作，通常會引起客戶端輸入或者輸出緩沖區的異常，Redis提供了info clients里面包含的客戶端輸入緩沖區的字節數以及輸出緩沖區的隊列長度，可以重點關注下：
127.0.0.1:6379> info clients client_longest_output_list:xxxxxc lient_biggest_input_buf:xxxxx
如果想知道具體的客戶端，可以使用client list命令來查找
redis-cli client list id=3 addr=127.0.0.1:58500 fd=8 name= age=3978 idle=25 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=26263554 events=r cmd=hgetall
6.改源碼
這個其實也是能做的，但是各方面成本比較高，對于一般公司來說不適用。
我個人的最佳實踐就是：
(1) Redis端與客戶端相結合：--bigkeys臨時用、scan長期做排除隱患（盡可能本地化）、客戶端實時監控。
(2) 監控報警要跟上
(3) debug object盡量少用
(4) 所有數據平臺化
(5) 要和開發同學強調bigkey的危害
五、如何刪除
如果發現了bigkey，而且確認是垃圾是不是直接del就可以了，來看一組數據：
可以看到對于string類型，刪除速度還是可以接受的。但對于二級數據結構，隨著元素個數的增長以及每個元素字節數的增大，刪除速度會越來越慢，存在阻塞Redis的隱患。所以在刪除它們時候建議采用漸進式的方式來完成：hscan、ltrim、sscan、zscan。
如果你使用Redis 4.0+，一條異步刪除unlink就解決，就可以忽略下面內容。
1.字符串：
一般來說，對于string類型使用del命令不會產生阻塞。
del bigkey
2.hash
使用hscan命令，每次獲取部分(例如100個)field-value，在利用hdel刪除每個field(為了快速可以使用pipeline)。public void delBigHash(String bigKey) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
// 游標
String cursor = "0";
while(true) {
ScanResult<Map.Entry<String, String>> scanResult = jedis.hscan(bigKey, cursor, new ScanParams().count(100));
// 每次掃描后獲取新的游標
cursor = scanResult.getStringCursor();
// 獲取掃描結果
List<Entry<String, String>> list = scanResult.getResult();
if(list == null || list.size() == 0) {
continue;
}
String[] fields = getFieldsFrom(list);
// 刪除多個field
jedis.hdel(bigKey, fields);
// 游標為0時停止
if(cursor.equals("0")) {
break;
}
}
// 最終刪除key
jedis.del(bigKey);
}
/**
* 獲取field數組
*/
private String[] getFieldsFrom(List<Entry<String, String>> list) {
List<String> fields = new ArrayList<String>();
for (Entry<String, String> entry : list) {
fields.add(entry.getKey());
}
return fields.toArray(new String[fields.size()]);
}
3.list
Redis并沒有提供lscan這樣的API來遍歷列表類型，但是提供了ltrim這樣的命令可以漸進式的刪除列表元素，直到把列表刪除。
public void delBigList(String bigKey) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
long llen = jedis.llen(bigKey);
int counter = 0;
int left = 100;
while(counter < llen) {
// 每次從左側截掉100個
jedis.ltrim(bigKey, left, llen);
counter += left;
}
// 最終刪除key
jedis.del(bigKey);
}
4.set
使用sscan命令，每次獲取部分(例如100個)元素，在利用srem刪除每個元素。
ublic void delBigSet(String bigKey) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
// 游標
String cursor = "0";
while(true) {
ScanResult<String> scanResult = jedis.sscan(bigKey, cursor, new ScanParams().count(100));
// 每次掃描后獲取新的游標
cursor = scanResult.getStringCursor();
// 獲取掃描結果
List<String> list = scanResult.getResult();
if(list == null || list.size() == 0) {
continue;
}
jedis.srem(bigKey, list.toArray(new String[list.size()]));
// 游標為0時停止
if(cursor.equals("0")) {
break;
}
}
// 最終刪除key
jedis.del(bigKey);
}
5.sorted set
使用zscan命令，每次獲取部分(例如100個)元素，在利用zremrangebyrank刪除元素。public void delBigSortedSet(String bigKey) {
long startTime = System.currentTimeMillis();
Jedis jedis = new Jedis(HOST, PORT);
// 游標
String cursor = "0";
while(true) {
ScanResult<Tuple> scanResult = jedis.zscan(bigKey, cursor, new ScanParams().count(100));
// 每次掃描后獲取新的游標
cursor = scanResult.getStringCursor();
// 獲取掃描結果
List<Tuple> list = scanResult.getResult();
if(list == null || list.size() == 0) {
continue;
}
String[] members = getMembers(list);
jedis.zrem(bigKey, members);
// 游標為0時停止
if(cursor.equals("0")) {
break;
}
}
// 最終刪除key
jedis.del(bigKey);
}
public void delBigSortedSet2(String bigKey) {
Jedis jedis = new Jedis(HOST, PORT);
long zcard = jedis.zcard(bigKey);
int counter = 0;
int incr = 100;
while(counter < zcard) {
jedis.zremrangeByRank(bigKey, 0, 100);
// 每次從左側截掉100個
counter += incr;
}
// 最終刪除key
jedis.del(bigKey);
}
六、如何優化
1.拆
big list： list1、list2、...listN
big hash：可以做二次的hash，例如hash%100
日期類：key20190320、key20190321、key_20190322。
2.本地緩存
減少訪問redis次數，降低危害，但是要注意這里有可能因此本地的一些開銷（例如使用堆外內存會涉及序列化，bigkey對序列化的開銷也不小）
7、總結：
由于開發人員對Redis的理解程度不同，在實際開發中出現bigkey在所難免，重要的能通過合理的檢測機制及時找到它們，進行處理。作為開發人員應該在業務開發時不能將Redis簡單暴力的使用，應該在數據結構的選擇和設計上更加合理，例如出現了bigkey，要思考一下可不可以做一些優化(例如二級索引)盡量的讓這些bigkey消失在業務中，如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出來(例如有時候僅僅需要hmget，而不是hgetall)，刪除也是一樣，盡量使用優雅的方式來處理。
