Redis学习笔记：缓存运用常见问题

这是本人学习的总结，主要学习资料如下

• 马士兵教育

1、数据一致性的问题

1.1、新增数据一致性的问题

所谓新增数据一致性的问题就是，新增数据时，缓存和数据库都要存数据，有一方失败一方成功导致的数据不一致的问题。

这种情况一般不用担心，如果真的很担心那可以在存数据前加一个消息中间件，让缓存和数据库消费这个中间件。因为中间件消费失败了会多次尝试，这就可以解决不一致的问题。

1.2、修改/删除一致性问题

1.2.1、操作分析

在涉及到缓存和数据库的修改和删除时，根据操作先后也就分为四种情况。

• 先更新缓存，后更新数据库。
• 先删除缓存，后更新数据库。
• 先更新数据库，后更新缓存。
• 先更新数据库，后删除缓存。

下面就逐一分析其可行性。

1. 先更新缓存， 后更新数据库。
   线程A和线程B并发更新数据，线程A先更新，线程B后更新。按照预期，因为线程B后更新那么最后结果应该以线程B的为准。
   但如果线程A更新缓存后，还没来得及更新数据库时，线程B就把缓存和数据库更新好了，之后线程A才继续更新数据库，那这时候就出现缓存是最新数据而数据库是旧数据的情况，缓存不一致出现。
   下图是流程图，左边是正常情况，右边是不一致的情况。
   

2. 先删除缓存， 后更新数据库
   线程A删除缓存后，还没来得及更新数据库时，线程B查询数据。
   一般线程B现在缓存查数据，查不到，转而查数据库，但这时线程A还没更新好，于是线程B拿到的是旧数据。
   现成B拿到旧数据后会顺便把旧数据更新到缓存中，于是现在就出现数据库时新数据，而缓存是旧数据的不一致。
   

3. 更新数据库，后更新缓存
   线程A和线程B并发更新数据，线程A先更新，线程B后更新。按照预期，因为线程B后更新那么最后结果应该以线程B的为准。
   但如果线程A更新数据库后还没来得及更新缓存，线程B已经更新了数据库和缓存，那么现在数据库就是数据库是最新数据，而缓存是旧数据的不一致情况。
   
   
   

4. 先更新数据库，后删除缓存
   特殊情况就是，在线程A更新数据库之前，线程B来查数据，并且缓存因为各种原因正好没数据，所以B就去数据库查数据。
   这里B拿到的是旧数据，之后A更新数据库完成，B就拿着旧数据回填到缓存中。但是A会删除缓存，这样别的线程再来查数据就会因为缓存没数据去数据库拿最新的数据回填到缓存中。这样就避免了数据不一致的情况。

   并且为了防止线程B拿到数据库旧数据后，在线程A第二次删缓存后才将旧数据回填到缓存造成数据库是新数据，缓存是旧数据的不一致，线程A更新完数据库后还睡眠一段时间，然后才删除缓存。这样就能保证第二次删除缓存发生在在线程B插入缓存之后。

教程里提到需要延迟双删，即在这个基础上，在线程A更新数据库前也删除一次缓存，加上更新后的删除，总共两次删除，所以叫延迟双删。

不过我自己觉得第一次删除没必要，似乎只有后一次删除也能避免数据不一致。

1.2.1、总结和再深入

所以面对修改/删除的一致性问题，最好的方法是先更新数据库，后删除缓存，并且有需要的话可以延时删除缓存。

还有两种加强的方式，都是在延时这里做文章。

第一种是线程A更新数据库以后将删除缓存的操作放到延迟消息队列中，这样可以避免缓存删除失败的风险，同时也让线程A更新完数据库后不必再睡眠，可以抽身做其他的事。这种方式唯一的缺点是增加了系统的复杂度。

另一种方式是数据库插入后会更新一种叫binlog的东西，我们让一个线程订阅binlog的发布，然后消费发布信息删除缓存。这种方式的缺点是获取binlog会引起I/O，效率不是很高。

2、缓存穿透，缓存击穿和缓存雪崩

2.1、缓存穿透（查不到）

一般的模型当中，一次查询会优先到redis中查询，如果没有查询到才进行mysql查询。但如果mysql中也没有对应数据，那这两次查询就无功而返。

一般情况下以上查询没什么问题。但在高并发的场景下，如果有大量请求想查询同一字段，而这一字段又不存在，那就会在短时间内进行大量的mysql查询，造成数据库崩溃，这就是缓存穿透。

2.1.1、 解决方式

1. 第一种是设空值。在redis中设空值，第一次在数据库中没查到数据就设一个空值在redis。这样的相同查询就在redis中查到空值就返回结束，不用麻烦数据库。

   等到以后真正有了值，数据库会更新到缓存中。

2. 布隆过滤器。布隆过滤器可以快速判定一个元素不在集合中。如果在查询前加入布隆过滤器，布隆过滤器里的数据和数据库同步。当查询查不存在的元素布隆过滤器直接处理，不用麻烦到数据库和缓存。
   

2.2、缓存击穿（过期没找到）

redis缓存中设置的值总是有过期时间，如果有一个超热点在失效的那一刻迎来了大量的请求，这些请求发现redis里没有数据，就会转到mysql中查询。

数据从mysql中取出，重新存到redis中有个时间差，在这个时间差内的所有请求都会查询mysql，那mysql就有可能承受不住压力崩溃。这就是缓存击穿。

2.2.1、解决方法

缓存击穿的核心问题是查数据库返回值设到redis中有时间差，这段时间对同一个值有大量查询。

那我们可以给关于这个值的查询加一个锁，只要有一个线程去查询数据库就够了。伪代码如下。

public String getValue(String key) {String value = redis.get(key);//为空则需要加锁查询if(value == null) {// 如果返回1，则成功获取锁if(redis.setnx(hash(key), 60) == 1) {String value = db.getValue(key);redis.set(key, value);return value;}	else {// 不成功则休眠一段时间再获取值试试Thread.sleep(60);return getValue(key);}}	else{return value;}
}

2.3、缓存雪崩

指某一时间段内，缓存集中过期，或者redis宕机，大量请求在redis中得到不到数据就转向数据库中查询，导致数据库崩溃。

2.3.1、解决方式

第一当然是依靠集群哨兵的故障恢复，一个节点挂了，就需要故障恢复启用其他节点接替工作。

另外还有下面几种做法。

1. 避免设置统一过期时间。缓存的过期时间不要太集中。
2. 功能降级。比如双十一期间一些不重要的功能可以暂停，避免查询过多。

3、数据倾斜

3.1、热点key

3.1.1、什么是热点key

比如微博里经常出现一些热点事件，明星结婚之类的，导致微博突然崩溃。

这是因为大厂往往用redis的集群作缓存，一个话题就存在一个节点中。一个话题如果过热就引起大量查询，导致某一节点压力突然变大直接崩溃。

这就是热点key导致的数据倾斜。

3.1.2、发现热点key

一般有四个方法，每个方法都不完美，只能根据实际情况甄选。

他们分别是客户端监控，monitor，hotkeys和TCP抓包。

1. 第一个是在客户端监控每一个key，查询一次就+1，如果查询一定时间内超过一定的阈值就上报或者其他处理。

这种方式实现很简单，缺点也很明显，就是代码侵入性，客户端的代码不得不增加不应该有的内容，而且监控每一个key也是不小的负担。

2. 第二个是用redis命令monitor，输入这个指令后相当于订阅了redis的一个服务，当有命令执行时就会收到命令的解析。
   比如下面的示例。

127.0.0.1:6900> monitor
OK
1677459065.262425 [0 127.0.0.1:54894] "set" "aaaa" "v1"

使用这种方法就意味着需要额外的开销去存储这些日志并解析，数据量大的时候开销就很大。

3. 在4.0.3以后，reids推出了hotKeys命令专门用于统计热点。具体示例如下。

首先先大量读取某一个key，多执行几次set命令即可，然后执行redis-cli --hotkeys命令获取热点。

MacBook-Pro:etc user$ redis-cli --hotkeys# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).Error: ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.

上面是常见的错误，因为redis是基于LFU的内存淘汰策略，所以要先开启策略选项才能使用hotkyes的功能。

127.0.0.1:6379> config set maxmemory-policy volatile-lfu
OK

然后可以使用hotkeys命令了，可以看到，它统计出k1这个key短时间内有6次查询。

MacBook-Pro:etc user$ redis-cli --hotkeys# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).[00.00%] Hot key 'k1' found so far with counter 6-------- summary -------Sampled 3 keys in the keyspace!
hot key found with counter: 6	keyname: k1

这个方法的问题是，hotkeys是一个全局命令，他需要扫描所有的key，这同样是个不小的开销。

4. 最后一种方法比较高级，就是抓reids的TCP的包然后解析。常用的插件是ELK packetbeat，这个的麻烦点是维护成本高，且有丢包的风险

3.1.3、解决热点Key

1. 使用二级缓存，比如Guava-cache，hcache，JVM对象内存等。将热点数据存到内存中，这样就不用访问redis，减轻redis的压力。
2. key分散。我们的key可以分成很多子key，当然子key不是乱命名的。这些子key需要均匀地落到集群的每一个节点，这样热点数据存储压力就分散了。

3.2、bigKey

3.2.1、什么是bigKey

bigKey是指单个key车占用的存储空间过大。String类型的一般是value过大，一般超过10kb就算bigKey了。

非String类型的就是集合，Hash，列表。他们的大体现在里面的元素过多。

他们的危害也比较明显，体积过大让存取都消耗较大 ，无论是空间复杂度还是时间复杂度都不友好。

1. 造成单节点内存空间使用不均匀。
2. Redis执行命令时，遇到该类型的key耗时较多。
3. 网络传输这种key容易造成拥堵。

3.2.2、发现热点key

1. redis自带命令：我们先设一个比较大的值

127.0.0.1:6379> set k1 dfnoqihudygouvhqihbghdsuygqfhsdgoiuqgt7687uhvit6871ygh2bdyf71tuidgbhgsft7681ghb23ysdf687iu1gb2jhodgyt67879u1bjdhuog8f6712uh3bnkhguoidt78f61723hbnkgdoyv8t7982uh3nbjhulos867tfy892u3hjbjlhoua78ft2e
OK

然后可以使用redis自带的命令redis-cli --bigkeys。

MacBook-Pro:etc $ redis-cli --bigkeys# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).[00.00%] Biggest string found so far 'k2' with 2 bytes
[00.00%] Biggest string found so far 'name' with 3 bytes
[00.00%] Biggest string found so far 'k1' with 194 bytes-------- summary -------Sampled 3 keys in the keyspace!
Total key length in bytes is 8 (avg len 2.67)Biggest string found 'k1' has 194 bytes0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
3 strings with 199 bytes (100.00% of keys, avg size 66.33)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

这种方式是全局命令，在有大量key的生产环境需要谨慎使用。

2. 使用debug命令：使用debug object k1可以得到k1这个单个key的信息。那么我们就可以一批一批地过一遍所有的key找到bigkey。

127.0.0.1:6379> debug object k1
Value at:0x600002554020 refcount:1 encoding:raw serializedlength:196 lru:10373635 lru_seconds_idle:6214367

关于遍历这个命令，遍历的操作可以使用scan命令来完成。

scan cursor [MATCH pattern] [COUNT count] ， 可以像分页一样地一页一页的遍历所有元素。这种遍历方式不一定能完全遍历所有的key，当遍历时有新数据插入就可能遍历不到。不过能遍历到绝大部分的元素，用来寻找bigKey还是很可靠的。

• scan，关键字。
• cursor，下标，可以理解成元素的下标，访问第一页的元素时cursor=0。
• [MATCH match]，可以省略，通配符匹配。
• [COUNT count]，每页返回的元素个数。这个不能保证每页都返回这个数目，只能保证尽量接近。
  下面是例子 ，总共遍历30个元素。方法的第一个返回值是下一页元素的下标，范围下一页时cursor要等于这个值。第二个返回值才是这一页的key。scan是循环遍历，遍历到最后一页下一页就是第一页。

127.0.0.1:6379> scan 0 count 10
1) "26"
2)  1) "k19"2) "k2"3) "k5"4) "k11"5) "k13"6) "k3"7) "k10"8) "k30"9) "k26"10) "k24"
127.0.0.1:6379> scan 26 count 10
1) "3"
2)  1) "k23"2) "k20"3) "k1"4) "k28"5) "k25"6) "k9"7) "k8"8) "k12"9) "k14"10) "k22"11) "k18"12) "k16"
127.0.0.1:6379> scan 3 count 10
1) "0"
2) 1) "k27"2) "k29"3) "k4"4) "k15"5) "k21"6) "k6"7) "k17"8) "k7"

3.2.3、解决bigKey

拆分，将bigkey拆分成多个子Key，使这些子Key均匀地分布到各个子节点。