redis 思维导图模板_ProcessOn思维导图、流程图

面试

Redis为啥这么快

测试命令：

redis-benchmark -t set,lpush -n 100000 -q

SET: 111482.72 requests per second LPUSH: 118906.06 requests per second

本地测试:每秒11万次的set 和get

redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"

script load redis.call('set','foo','bar'): 111731.84 requests per second

每秒执行11万的Lua脚本

这么快的原因：

纯内存结构 key -value结构

单线程

没有创建线程、销毁线程带来的消耗

避免了上下文切换导致的 CPU 消耗

避免了线程之间带来的竞争问题，例如加锁释放锁死锁等等

多路复用

延伸一下什么叫多路复用selector、poll、epoll

异步非阻塞IO

redis如何防止key冲突

1、业务隔离

不同的业务使用不同的redis集群

协议使用redis的不同db。

2、良好的Redis Key的设计

格式：业务标识：系统名称：模块名称：关键词简写

比如：保险：用户管理：用户申请：手机号

Redis Key：bx:um:reg:mobile

redis如何保证高可用

主从复制

哨兵模式集群（解决主节点挂掉不可写的问题，没有主节点）

选举出一个 Sentinel 节点来完成自动故障转移

sentinel节点为奇数个（2n+1）

集群模式

3主3从

Hash 槽(slot)

Redis 集群中有 16384 个散列槽，为了计算给定密钥的散列槽，Redis 对 key 采用 CRC16 算法

slot = crc16(key) mod NUMER_SLOTS

数据持久化

aof

rdb

redis分布式锁存在宕机导致锁丢失，怎么解决

Redis分布式锁实现

锁实现

获取锁(unique_value可以是UUID等)

SET resource_name unique_value NX PX 30000

释放锁(lua脚本中，一定要比较value，防止误解锁)

要点

set命令要用set key value px milliseconds nx;

value要具有唯一性;

释放锁时要验证value值，不能误解锁;

问题：锁丢失场景

在Redis的master节点上拿到了锁;

但是这个加锁的key还没有同步到slave节点;

master故障，发生故障转移，slave节点升级为master节点;

导致锁丢失。

解决

Redlock实现

使用N个完全独立、没有主从关系的Redis master节点以保证他们大多数情况下都不会同时宕机，N一般为奇数。一个客户端需要做如下操作来获取锁：

核心原理

获取当前时间（单位是毫秒）。

轮流用相同的key和随机值在N个节点上请求锁，在这一步里，客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，这个可以防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，我们应该尽快尝试下一个master节点。

客户端计算第二步中获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（(N/2) +1），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。

如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。

如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。

总结

就是利用多个的主节点，在超过半数以上的主节点获取锁成功，才算成功；否则算失败，回滚–删除之前在所有节点上获取的锁。

redis 大key，热key怎么解决

大key

问题

所谓的bigkey就是存储本身的key值空间太大，或者hash，list，set等存储中value值过多。

场景

1、单个简单的key存储的value很大

2、hash， set，zset，list 中存储过多的元素

3、一个集群存储了上亿的key

1、单个简单的key存储的value很大

2、hash， set，zset，list 中存储过多的元素

3、一个集群存储了上亿的key

产生问题

1.读写bigkey会导致超时严重，甚至阻塞服务。

2.大key相关的删除或者自动过期时，会出现qps突降或者突升的情况，极端情况下，会造成主从复制异常，Redis服务阻塞无法响应请求

解决方法

单个简单的key存储的value很大

对象需要每次都整存整取

可以尝试将对象分拆成几个key-value，使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；

该对象每次只需要存取部分数据

可以像第一种做法一样，分拆成几个key-value，也可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget,hmget来获取部分的value，使用hset，hmset来更新部分属性

对于value中存储过多元素的key,同样可以将这部分元素拆分，以hash为例，正常的流程是：hget(hashKey, field)；hset(hashKey, field, value)。现在可以固定一个桶数量，比如1w，每次存取的时候，先在本地计算field的hash值，对1w取模，确定field落在哪个key上,newHashKey = hashKey + ( hash(field) % 10000）; hset (newHashKey, field, value) ; hget(newHashKey, field),set，zset，list做法类似

hash， set，zset，list 中存储过多的元素

可以对存储元素按一定规则进行分类，分散存储到多个redis实例中。

一个集群存储了上亿的key

转Hash结构存储，即原先是直接使用Redis String 的结构存储，现在将多个key存储在一个Hash结构中

不使用redis，使用其他存储，比如mongodb

如何找到大key

jimdb管理端，拓扑Tab页，点击实例可以使用大key扫描功能，该功能底层使用scan扫描所有key，会影响实例性能,选择业务低峰进行

redis 可使用redis-cli的“--bigkeys”选项查找大Key

redis-cli --bigkeys

热key

介绍

热key问题就是突然有几十万的请求去访问redis上的某个特定key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis服务器直接宕机。

场景

用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）

请求分片集中，超过单 Server 的性能极限。

产生问题

• 流量集中，达到物理网卡上限。

• 请求过多，缓存分片服务被打垮。

• DB 击穿，引起业务雪崩。

解决方法

服务端缓存：即将热点数据缓存至服务端的内存中

增加二级缓存

发现热key以后，可以把热key数据加载到系统JVM并设置合适的缓存过期时间，针对热key的请求就会直接分散到各业务服务器上，防止所有请求同时访问同一台redis。

备份热点key

可以把热点key的数据备份到所有redis的集群节点中，可以通过在热点key后面拼接集群节点编号，然后将这些备份key分散到所有集群节点中，客户端访问热点key的时候也在热点key后面随机拼接集群节点编号，将热点key的请求分散到不同集群节点上。

如何找到热key

redis-cli –hotkeys

必须配合maxmemory-policy的属性

config set maxmemory-policy volatile-lfu

config set maxmemory-policy allkeys-lfu

使用

./redis-cli --hotkeys

凭借业务经验，进行预估哪些是热key

在客户端进行收集。比如在redis客户端执行redis命令之前，加入一行代码进行命令数据收集，，然后通过网络将收集的命令发送出去，确定是对客户端代码有入侵。

redis二进制安全怎么实现

概念

在传输数据时，保证二进制数据的信息安全，也就是不被篡改、破译等，如果被攻击，能够及时检测出来

c字符串

C字符串中的字符必须符合某种编码（比如ASCII），并且除了字符串的末尾之外，字符串里面不能包含空字符，否则最先被程序读入的空字符将被误认为是字符串结尾，这些限制使得C字符串只能保存文本数据，而不能保存像图片、音频、视频、压缩文件这样的二进制数据。

解决

sds

SDS(simple dynamid string )的 API都是二进制安全的（binary-safe），所有SDS API都会以处理二进制的方式来处理SDS存放在buf数组里的数据，程序不会对其中的数据做任何限制、过滤、或者假设，数据在写入时是什么样的，它被读取时就是什么样。

通过使用二进制安全的SDS，而不是C字符串，使得Redis不仅可以保存文本数据，还可以保存任意格式的二进制数据。

SDS使用len属性的值而不是空字符来判断字符串是否结束

redis批量命令

批量get/set(multi get/set)

命令

string

mget

mset

hash

hmset

hmget

代码

redis.clients.jedis.Jedis#mget

管道(pipelining)

使用

客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。服务端处理命令，并将结果返回给客户端。

Redis 管道技术可以在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应。

pipeline就是把一组命令进行打包，然后一次性通过网络发送到Redis。同时将执行的结果批量的返回回来. 使用管道发送命令时，服务器将被迫回复一个队列答复，占用很多内存。所以，如果你需要发送大量的命令，最好是把他们按照合理数量分批次的处理，例如10K的命令，读回复，然后再发送另一个10k的命令，等等。

代码

redis.clients.jedis.Pipeline

父类

redis.clients.jedis.MultiKeyPipelineBase

命令

安装nc命令

yum install nc

nc打包多个命令

(printf "PING\r\nPING\r\nPING\r\n") | nc localhost 6379

事务(transaction)

命令

代码

基于事务的管道(transaction in pipelining)

在Redis中，管道是通过RESP，即redis协议来实现的，它允许在一个消息包中按照指定格式传递多个命令。而事务是通过命令实现的，因此管道和事务之间并不冲突，事务可以承载与管道之上。在某些场景，需要在一次请求处理中发起多次事务的场景下，通过引入管道，可以获得略高于单独执行多次事务的性能，但是两者的差距非常小，小到可以忽略。

代码

redis在项目中是怎么用的

分布式锁

主要利用redis的setnx命令进行，setnx："set if not exists"就是如果不存在则成功设置缓存同时返回1，否则返回0。

key

warehouseCode+itemCode

入库

出库

占用

释放

缓存

库存

基础数据

仓库/货主/覆盖区域

字典

地区

限时业务的运用

redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景

缓存与数据库的一致性（20210511）

写时更新

介绍

当我们往数据库写数据的时候我们去更新缓存，包括先更新缓存再更新数据库和先更新数据库再更新缓存。

缺点

效率问题

如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。

线程安全性问题

同时有请求A和请求B进行更新操作，那么会出现（1）线程A更新了数据库（2）线程B更新了数据库（3）线程B更新了缓存（4）线程A更新了缓存。这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。

写时删除，读时更新

介绍

当我们往数据库写数据的时候我们直接删除缓存，然后其他请求读数据的时候更新缓存。包括先删除缓存再更新数据和先更新数据库再删除缓存。

分类

先更新数据库在删除缓存

问题

问题一、如果在高并发的场景下，会出现数据库与缓存数据不一致

场景

1、缓存刚好失效线程 A 查询数据库，得一个旧值

2、线程 B 将新值写入数据库

3、线程 B 删除缓存

4、线程 A 将查到的旧值写入缓存

出现概率极低

需要线程A读操作必需在B线程写操作前进入数据库操作，而又要晚于B写操作更新缓存，所有的这些条件都具备的概率基本并不大

解决

设置缓存的过期时间，这样可以达到最终一致性

问题二、如果删除缓存失败或更新数据库失败了会怎样？

第一步操作数据库成功，第二步删除缓存失败，会导致数据库里是新数据，而缓存里是旧数据

解决

将需要删除的 key 发送到消息队列中自己消费消息，获得需要删除的 key 不断重试删除操作，直到成功

第一步操作数据库就失败了，第二步更新缓存不会执行，不会出现数据不一致。

总结

在高并发下相对出现数据不一致问题概率很低，但在原子性被破坏时（删除缓存失败或更新数据库失败）会出现数据一致性问题

解决方案就是要给KEY设置过期时间

先删除缓存再更新数据

问题

问题一、如果在高并发的场景下，会出现数据库与缓存数据不一致

场景

1、线程 A 删除了缓存线程 B 查询，发现缓存已不存在

2、线程 B 去数据库查询得到旧值

3、线程 B 将旧值写入缓存

4、线程 A 将新值写入数据库

解决

设置缓存的过期时间，这样可以达到最终一致性

问题二、如果删除缓存失败或更新数据库失败了会怎样？

第一步删除缓存成功，第二步更新数据库失败，数据库和缓存的数据还是一致的。

第一步删除缓存就失败了，第二步更新数据库不会去执行，数据库和缓存的数据还是一致的。

总结

并不会导致数据不一致问题

总结

在高并发下相对更容易出现数据不一致问题，但在原子性被破坏时（删除缓存失败或更新数据库失败）并不会出现数据一致性问题

解决方案就是要给KEY设置过期时间

其他解决方案

延时双删策略

1、先淘汰缓存

2、再写数据库

3、休眠1秒/写数据成功之后

要造成脏缓存，就需要在缓存被删除后，数据库被更新前有请求读取到了旧数据并更新了缓存，那么这边睡眠一秒后再次删除缓存就可以把这个短暂的时间间隔内产生的脏缓存再次删除掉。

4、再次淘汰缓存.

阿里canal方案

启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。

原理图

LinkedIn的DataBus

其原理和阿里的Canal一致

内存回收

淘汰策略

Redis 的内存淘汰策略，是指当内存使用达到最大内存极限时，需要使用淘汰算法来决定清理掉哪些数据，以保证新数据的存入

redis.conf 参数配置：# maxmemory <bytes>

64 位系统不限制内存，32 位系统最多使用 3GB 内存

动态修改：config set maxmemory 2GB

LRU

Least Recently Used：最近最少使用

volatile-lru

在带有过期时间的键，中删除最近最少使用的

allkeys-lru

在所有带有过期时间的Key中，删除最近最少使用的

Redis优化过：

如果淘汰策略是 LRU，则根据配置的采样值 maxmemory_samples（默认是 5 个）, 随机从数据库中选择 m 个 key, 淘汰其中热度最低的 key 对应的缓存数据

LFU

Least Frequently Used，最不常用（最近使用频次最少的），4.0 版本新增

volatile-lfu

在带有过期时间的键中删除最不常用的。

allkeys-lfu

在所有的键中选择最不常用的，不管数据有没有设置超时属性。

Rondom

随机删除

volatile-random

在带有过期时间的键中随机删除

allkeys-random

随机删除所有键，直到腾出足够内存为止。

noeviction

默认策略，不会删除任何数据，达到内存最大后，返回错OOM，只响应读操作

volatile-ttl

根据键值对象的 ttl 属性，删除最近将要过期数据。如果没有，回退到 noeviction 策略

动态修改淘汰策略

config set maxmemory-policy volatile-lru

默认推荐使用：建议使用 volatile-lru，在保证正常服务的情况下，优先删除最近最少使用的 key。

思考如何基于一个数据结构实现LRU算法：

LinkedHashMap是有序的，且默认为插入顺序，先进入在前，后进去的在后面，

继承LinkedHashMap并重写removeEldestEntry方法

过期策略

定时过期

每个设置过期时间的 key 都需要创建一个定时器，到过期时间就会立即清除

效率很高，但是key很多的时候也创建了大量的定时器，对内存很友好，占用大量的 CPU 资源去处理过期的数据

惰性过期（被动淘汰）

只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除

该策略可以最大化地节省 CPU 资源，却对内存非常不友好，极端情况可能出现大量的过期 key 没有再次被访问，从而不会被清除，占用大量内存

定期过期

每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的 key。该策略是前两者的一个折中方案

缓存三大问题

缓存穿透（缓存和数据库都不存在）

概念

指查询一个根本不存在的数据，缓存层和存储层都不会命中

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端的意义

原因

自身业务代码或者数据出现问题；

一些恶意攻击、爬虫等造成大量空命中

解决方法

缓存空对象

解决

缺点

1、空值做了缓存，意味着缓存层中存了更多的键，需要更多内存空间。
比较有效的方法是针对这类数据设置一个较短的过期时间。

2、缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。

布隆过滤器

概念

是一种空间利用率较高的概率型数据结构，用来测试一个元素是否在集合中。但是存在一定可能，导致结果误判。即元素不在集合中，查询结果却返回元素在集合中。

原理

当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不存在；如果都是1，则被检元素很可能存在

Bloom Filter跟单哈希函数Bit-Map不同之处在于：Bloom Filter使用了k个哈希函数，每个字符串跟k个bit对应。从而降低了冲突的概率。

原理图

优点

二进制组成的数组，占用内存极少，并且插入和查询速度都足够快

缺点

随着数据的增加，误判率会增加

无法判断数据一定存在

无法删除数据

缓存击穿（某个热点key失效）

概念

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，
又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

解决方案

设置热点数据永远不过期。

加互斥锁

在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降

缓存雪崩（大量key同时过期）

概念

Redis中大量的key几乎同时过期，然后大量并发查询穿过redis击打到底层数据库上，此时数据库层的负载压力会骤增

解决方案

在可接受的时间范围内随机设置key的过期时间，分散key的过期时间，以防止大量的key在同一时刻过期；

对于一定要在固定时间让key失效的场景(例如每日12点准时更新所有最新排名)，可以在固定的失效时间时在接口服务端设置随机延时，将请求的时间打散，让一部分查询先将数据缓存起来；

延长热点key的过期时间或者设置永不过期

常见问题

ERR SELECT is not allowed in cluster mode

在集群模式下这个配置是不起作用的，集群客户端是不支持多数据库db的，只有一个数据库默认是SELECT 0;

redis在单机模式下redis.conf配置文件中默认的数据库数量是16个

集群slave从节点默认是不支持读写操作的，但是在执行过readonly命令后可以执行读操作

发生异常错误信息（redis缓存处理序列化时）

问题

详细

原因

实体entity未被序列化

解决

配置序列化

无法读取json Could not read JSON: Invalid UTF-32 character 0x5b21636f

问题

详细

原因

使用set方法错误，使用4个参数的set方法，带过期时间

解决

把 redisTemplate.opsForValue().set(REDIS_USER_KEY + id, new NullEntity(), 60);
修改为 redisTemplate.opsForValue().set(REDIS_USER_KEY + id, new NullEntity(), 60, TimeUnit.SECONDS);

redisssion加锁失败 Operation against a key holding the wrong kind of value

问题

详细

原因

WRONGTYPE Operation against a key holding the wrong kind of value tells that another object by the same key is stored but with different type.

有重复的key

解决

换个key即可

redis客户端

客户端连接工具

redis desktop manager

1、安装