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

已于 2023-03-03 11:49:43 修改
阅读量549 收藏
点赞数
分类专栏： Redis 文章标签： 缓存 redis 学习
于 2023-03-01 18:59:25 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sinat_38393872/article/details/129226409
版权

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

  • 马士兵教育

目录

1、数据一致性的问题

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

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

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



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

1.2.1、操作分析

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

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

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

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



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

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

  2. 先更新数据库，后删除缓存
    特殊情况就是，在线程A更新数据库之前，线程B来查数据，并且缓存因为各种原因正好没数据，所以B就去数据库查数据。

    这里B拿到的是旧数据，之后A更新数据库完成，B就拿着旧数据回填到缓存中。但是A会删除缓存，这样别的线程再来查数据就会因为缓存没数据去数据库拿最新的数据回填到缓存中。这样就避免了数据不一致的情况。

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

第二次删除是为了防止线程B的插入操作发生在第一次删除之后，再删除旧缓存。


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也是不小的负担。


  1. 第二个是用redis命令monitor，输入这个指令后相当于订阅了redis的一个服务，当有命令执行时就会收到命令的解析。
    比如下面的示例。
127.0.0.1:6900> monitor
OK
1677459065.262425 [0 127.0.0.1:54894] "set" "aaaa" "v1"

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



  1. 在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，这同样是个不小的开销。

  1. 最后一种方法比较高级，就是抓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 bytes

0 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的生产环境需要谨慎使用。



  1. 使用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均匀地分布到各个子节点。



大苏打seven
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
linux redis cpu 100,Redis监控汇总(1/2)
weixin_42502601的博客
05-12 497
Redis监控汇总一.md一、概述对于任何运行在生产环境的软件，监控都是必不可少的一个环节。我们在分析各种工具之前，先来看下redis都有哪些指标需要关注和监控。Redis监控的用途有两种，一种是类似于zabbix，监控指标并用来报警，另外一种就是出现问题时，快速定位问题使用的。各个数据库db的key数量、redis存储的key总数量redis内存使用状况redis使用CPU状况redis当前的Q...
adb shell 抓取android 性能数据及工具分享
sha_123456789的博客
10-20 342
adb shell 抓取android 性能数据及工具分享
redis 日常使用
09-17 176
每隔1秒ping3次 [redis@redis01 ~]$ redis-cli -h 192.168.20.201 -p 7003 -i 1 -r 3 ping PONG PONG PONG 　　 模拟复制进程 [redis@redis01 7001]$ redis-cli -h 192.168.20.201 -p 7002 --slave SYNC wi...
redis线程阻塞原因排插_Redis阻塞原因
weixin_36189159的博客
12-24 160
自身因素api或数据结构使用不合理:例如对一个上万元素的hash结构执行hgetall操作，数据量造成堵塞。慢查询大对象a. 数据库清零过后执行redis-cli --bigkeys命令的执行结果，系统没有查询到大的对象127.0.0.1:6379> flushallOK127.0.0.1:6379>[root@localhost etc]# redis-cli --bigkeys# ...
Redis进阶实践之十五 Redis-cli命令行工具使用详解第二部分（结束）
weixin_34133829的博客
03-08 1176
一、介绍           今天继续redis-cli使用的介绍，上一篇文章写了一部分，写到第9个小节，今天就来完成第二部分。话不多说，开始我们今天的讲解。如果要想看第一篇文章，地址如下：http://www.cnblogs.com/PatrickLiu/p/8508975.html二、使用详解          上篇文章写到第9个小节，今天直接按着以上的序号，继续来写          10、...
redis-note:Redis学习笔记
07-11
以上只是Redis学习笔记中的一些关键点，实际学习过程中，还需要结合具体使用场景进行深入研究和实践。在`redis-note-master`这个压缩包中，你可能会找到关于这些知识点的详细解释、示例代码和实战案例，帮助你更好地...
Redis学习笔记.zip
最新发布
06-06
简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以存写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来...
Redis全套学习笔记
05-25
Redis 的设计目标是为了处理高并发、高扩展性场景，以及大数据存储问题。它支持多种数据结构，包括字符串(String)、链表(List)、哈希(Hash)、集合(Set)和有序集合(Zset)，这些丰富的数据结构使得Redis在缓存、计数、...
学习笔记:300分钟吃透分布式缓存.docx
07-15
"学习笔记：300分钟吃透分布式缓存" 缓存是指用于加速数据交换的存储介质，可以是硬件也可以是软件。缓存存在的意义就是通过开辟一个新的数据交换缓冲区，来解决原始数据获取代价太大的问题，让数据得到更快的访问...
redis详细笔记，包含面试常见问题
05-12
本笔记将深入探讨Redis的基础概念、核心特性、常见面试问题及其在实际应用中的策略。 一、Redis基础 1. 数据类型：Redis提供了五种基本数据类型，包括字符串(String)、哈希(Hash)、列表(List)、集合(Set)和有序...
redis阻塞
cangqiong_xiamen的博客
07-19 1697
1.客户端最先感知阻塞等Redis超时行为，加入日志监控报警工具可快速定位阻塞问题，同时需要对Redis进程和机器做全面监控。 2.阻塞的内在原因：确认主线程是否存在阻塞，检查慢查询等信息， 发现不合理使用API或数据结构的情况，如keys、sort、hgetall等。关注CPU 使用率防止单核跑满。当硬盘IO资源紧张时，AOF追加也会阻塞主线程。 3.阻塞的外在原因：从CPU竞争、内存交换、网络...
Redis使用
liming1134的博客
03-03 241
maxTotal=5 , maxIdle=3 , 当maxTotal开满后，主动调用colse所有的连接，实际关闭tcp的只有2个，3个会保活一阵时间，时间到后也会断开tcp，也不是全部断开，断开的保持minIdle连接。当我同时设置了14511条数据到redisson延时队列时，取出来的时间在本身的延时时间上还延时了198636多毫秒(3分钟)，而且时间随着数据增加而增加。有一个 zset集合， 里面按时间搓来排序，然后 客户端 有个1s执行的定时器，来轮询 redis ， 分页取出zset。
Redis 性能优化
weixin_42491646的博客
10-12 261
Redis 性能优化
【JavaGuide面试总结】Redis篇·下
大河之犬的博客
02-17 536
Redis 事务在运行错误的情况下，除了执行过程中出现错误的命令外，其他命令都能正常执行。因此，严格来说，通过 Lua 脚本来批量执行 Redis 命令也是不满足原子性的。把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。这就可能会导致瞬时大量的请求直接打到了数据库上，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
Redis BigKey介绍
热门推荐
weixin_47531845的博客
09-27 1万+
一、什么是bigkey 在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素，但实际上中如果下面两种情况，我就会认为它是bigkey。 字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey。 非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多。 二、危害 bigkey可以说就是Redis的老鼠屎，具体表现在： 1.内存空间不均匀 这样会不利于集群对内
redis学习三-redisShell介绍
qq_35930102的博客
09-01 233
目录 1 redis-cli介绍 1.1 执行频率和间隔 1.2 集群环境连接 1.3 认证连接 1.4 大key查询 1.5 查看网络延迟 1.6 查看redis信息(内存、连接等) 2 redis-benchmark介绍 2.1 并发数和请求量 2.2 统计每秒并发量 2.3 随机键插入测试 2.4 对指定命令测试 2.5 CSV格式输出 1 redis-cli介绍 1.1 执行频率和间隔 -r：repeat表示多次执行 -i：表示每隔几秒执行1次，需要和-r配合使用，可
故障分析 | Redis Cluster 分片内存异常使用不均问题诊断
ActionTech的博客
08-29 958
作者：任仲禹爱可生 DBA 团队成员，擅长故障分析和性能优化，文章相关技术问题，欢迎大家一起讨论。本文来源：原创投稿*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。...
rediscli shell_Redis Shell
weixin_35607383的博客
01-17 305
Redis提供了redis-cli、redis-server、redis-benchmark等Shell工具。它们虽然比较简单，但是麻雀虽小五脏俱全，有时可以很巧妙地解决一些问题。redis-cli详解用法：redis-cli [OPTIONS][cmd [arg [arg ...]]]可选项：可选项说明-h 服务端 hostname (默认 127.0.0.1)-p 服务端 端口 (默认 637...
redis-cli使用说明
ppjsyw的博客
05-20 6053
介绍 redis-cli是Redis命令行界面,一个简单的程序，允许向 Redis 发送命令，然后从服务端读取发送的回复。 Redis对命令的大小写不区分,比如ping、Ping是同一个命令。 Redis对key名的大小写区分。 两种模式 交互模式:在redis-cli里面使用 另一种模式:在命令前面带上redis-cli的方式 基本使用 1、连接到Redis -h 用于指定 ip -p 用于指定端口 -a 用于指定认证密码 D:\work\redis>redis-cli -p 6379
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值