- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
Redis连环40问,绝对够全! 。
Redis( Remote Dictionary Server )是一个使用 C 语言编写的,高性能非关系型的键值对数据库。与传统数据库不同的是,Redis 的数据是存在内存中的,所以读写速度非常快,被广泛应用于缓存方向。Redis可以将数据写入磁盘中,保证了数据的安全不丢失,而且Redis的操作是原子性的.
优点 :
缺点 :
本文已经收录到Github仓库,该仓库包含 计算机基础、Java基础、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等核心知识点,欢迎star~ 。
Github地址 。
如果访问不了Github,可以访问gitee地址.
gitee地址 。
虽然Redis非常快,但它也有一些局限性,不能完全替代主数据库。有以下原因:
事务处理: Redis只支持简单的事务处理,对于复杂的事务无能为力,比如跨多个键的事务处理.
数据持久化: Redis是内存数据库,数据存储在内存中,如果服务器崩溃或断电,数据可能丢失。虽然Redis提供了数据持久化机制,但有一些限制.
数据处理: Redis只支持一些简单的数据结构,比如字符串、列表、哈希表等。如果需要处理复杂的数据结构,比如关系型数据库中的表,那么Redis可能不是一个好的选择.
数据安全: Redis没有提供像主数据库那样的安全机制,比如用户认证、访问控制等等.
因此,虽然Redis非常快,但它还有一些限制,不能完全替代主数据库。所以,使用Redis作为缓存是一种很好的方式,可以提高应用程序的性能,并减少数据库的负载.
Redis基于Reactor模式开发了网络事件处理器,这个处理器被称为文件事件处理器。它的组成结构为4部分:多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的,所以Redis才叫单线程模型.
虽然文件事件处理器以单线程方式运行, 但通过使用 I/O 多路复用程序来监听多个套接字, 文件事件处理器既实现了高性能的网络通信模型, 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接, 这保持了 Redis 内部单线程设计的简单性.
给大家分享一个Github仓库,上面有大彬整理的 300多本经典的计算机书籍PDF ,包括 C语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等,可以star一下,下次找书直接在上面搜索,仓库持续更新中~ 。
Github地址 。
使用自带的 map 或者 guava 实现的是 本地缓存 ,最主要的特点是轻量以及快速,生命周期随着 jvm 的销毁而结束,并且在多实例的情况下,每个实例都需要各自保存一份缓存,缓存不具有一致性.
使用 redis 或 memcached 之类的称为 分布式缓存 ,在多实例的情况下,各实例共用一份缓存数据,缓存具有一致性.
基本数据类型 :
1、 String :最常用的一种数据类型,String类型的值可以是字符串、数字或者二进制,但值最大不能超过512MB.
2、 Hash :Hash 是一个键值对集合.
3、 Set :无序去重的集合。Set 提供了交集、并集等方法,对于实现共同好友、共同关注等功能特别方便.
4、 List :有序可重复的集合,底层是依赖双向链表实现的.
5、 SortedSet :有序Set。内部维护了一个 score 的参数来实现。适用于排行榜和带权重的消息队列等场景.
特殊的数据类型 :
1、 Bitmap :位图,可以认为是一个以位为单位数组,数组中的每个单元只能存0或者1,数组的下标在 Bitmap 中叫做偏移量。Bitmap的长度与集合中元素个数无关,而是与基数的上限有关.
2、 Hyperloglog 。HyperLogLog 是用来做基数统计的算法,其优点是,在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定的、并且是很小的。典型的使用场景是统计独立访客.
3、 Geospatial :主要用于存储地理位置信息,并对存储的信息进行操作,适用场景如定位、附近的人等.
相同点 :
不同点:
如果达到设置的上限,Redis的写命令会返回错误信息(但是读命令还可以正常返回).
也可以配置内存淘汰机制,当Redis达到内存上限时会冲刷掉旧的内容.
可以好好利用Hash,list,sorted set,set等集合类型数据,因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表(hashes),散列表(是说散列表里面存储的数少)使用的内存非常小,所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象,不要为这个用户的名称,姓氏,邮箱,密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.
redis的单线程的。keys指令会导致线程阻塞一段时间,直到执行完毕,服务才能恢复。scan采用渐进式遍历的方式来解决keys命令可能带来的阻塞问题,每次scan命令的时间复杂度是 O(1) ,但是要真正实现keys的功能,需要执行多次scan.
scan的缺点:在scan的过程中如果有键的变化(增加、删除、修改),遍历过程可能会有以下问题:新增的键可能没有遍历到,遍历出了重复的键等情况,也就是说scan并不能保证完整的遍历出来所有的键.
事务的原理是将一个事务范围内的若干命令发送给Redis,然后再让Redis依次执行这些命令.
事务的生命周期:
使用MULTI开启一个事务 。
在开启事务的时候,每次操作的命令将会被插入到一个队列中,同时这个命令并不会被真的执行 。
EXEC命令进行提交事务 。
一个事务范围内某个命令出错不会影响其他命令的执行,不保证原子性:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b 1 2
QUEUED
127.0.0.1:6379> set c 3
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR syntax error
3) OK
WATCH命令 。
WATCH 命令可以监控一个或多个键,一旦其中有一个键被修改,之后的事务就不会执行(类似于乐观锁)。执行 EXEC 命令之后,就会自动取消监控.
127.0.0.1:6379> watch name
OK
127.0.0.1:6379> set name 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name 2
QUEUED
127.0.0.1:6379> set gender 1
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get gender
(nil)
比如上面的代码中:
watch name
开启了对 name
这个 key
的监控 name
的值 name
和 gender
的值 EXEC
命令进提交事务 get gender
发现不存在,即事务a没有执行 使用 UNWATCH 可以取消 WATCH 命令对 key 的监控,所有监控锁将会被取消.
Redis 是单进程程序,并且它保证在执行事务时,不会对事务进行中断,事务可以运行直到执行完所有事务队列中的命令为止。因此,Redis 的事务是总是带有隔离性的.
Redis单条命令是原子性执行的,但事务不保证原子性,且没有回滚。事务中任意命令执行失败,其余的命令仍会被执行.
持久化就是把 内存的数据写到磁盘中 ,防止服务宕机导致内存数据丢失.
Redis支持两种方式的持久化,一种是 RDB 的方式,一种是 AOF 的方式。 前者会根据指定的规则定时将内存中的数据存储在硬盘上 ,而 后者在每次执行完命令后将命令记录下来 。一般将两者结合使用.
RDB方式 。
RDB 是 Redis 默认的持久化方案。RDB持久化时会将内存中的数据写入到磁盘中,在指定目录下生成一个 dump.rdb 文件。Redis 重启会加载 dump.rdb 文件恢复数据.
bgsave 是主流的触发 RDB 持久化的方式,执行过程如下:
BGSAVE
命令 BGSAVE
命令直接返回。 fork
操作 创建子进程 ,fork操作过程中父进程会阻塞。 fork
完成后, 父进程继续接收并处理客户端的请求 ,而 子进程开始将内存中的数据写进硬盘的临时文件 ; Redis启动时会读取RDB快照文件,将数据从硬盘载入内存。通过 RDB 方式的持久化,一旦Redis异常退出,就会丢失最近一次持久化以后更改的数据.
触发 RDB 持久化的方式:
手动触发 :用户执行 SAVE 或 BGSAVE 命令。 SAVE 命令执行快照的过程会阻塞所有客户端的请求,应避免在生产环境使用此命令。 BGSAVE 命令可以在后台异步进行快照操作,快照的同时服务器还可以继续响应客户端的请求,因此需要手动执行快照时推荐使用 BGSAVE 命令.
被动触发 :
SAVE 100 10
,100秒内至少有10个键被修改则进行快照。 BGSAVE
生成 RDB 文件并发送给从节点。 shutdown
命令时,如果没有开启 AOF 持久化功能则自动执行·BGSAVE·。 优点 :
缺点 :
BGSAVE
每次运行都要执行 fork
操作创建子进程,属于重量级操作,频繁执行成本比较高。 AOF方式 。
AOF(append only file)持久化:以独立日志的方式记录每次写命令,Redis重启时会重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是 解决了数据持久化的实时性 ,AOF 是Redis持久化的主流方式.
默认情况下Redis没有开启AOF方式的持久化,可以通过 appendonly 参数启用: appendonly yes 。开启AOF方式持久化后每执行一条写命令,Redis就会将该命令写进 aof_buf 缓冲区,AOF缓冲区根据对应的策略向硬盘做同步操作.
默认情况下系统 每30秒 会执行一次同步操作。为了防止缓冲区数据丢失,可以在Redis写入AOF文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过 appendfsync 参数设置同步的时机.
appendfsync always //每次写入aof文件都会执行同步,最安全最慢,不建议配置
appendfsync everysec //既保证性能也保证安全,建议配置
appendfsync no //由操作系统决定何时进行同步操作
接下来看一下 AOF 持久化执行流程:
优点 :
fsync
操作,如果Redis进程挂掉,最多丢失1秒的数据。 append-only
的模式写入,所以没有磁盘寻址的开销,写入性能非常高。 缺点 :
通常来说,应该同时使用两种持久化方案,以保证数据安全.
当RDB与AOF两种方式都开启时,Redis会优先使用AOF恢复数据,因为AOF保存的文件比RDB文件更完整.
单机版 :单机部署,单机redis能够承载的 QPS 大概就在上万到几万不等。这种部署方式很少使用。存在的问题:1、内存容量有限 2、处理能力有限 3、无法高可用.
主从模式 :一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容,支撑读高并发。master 节点挂掉后,需要手动指定新的 master,可用性不高,基本不用.
哨兵模式 :主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。master 节点挂掉后,哨兵进程会主动选举新的 master,可用性高,但是每个节点存储的数据是一样的,浪费内存空间。数据量不是很多,集群规模不是很大,需要自动容错容灾的时候使用.
Redis cluster :服务端分片技术,3.0版本开始正式提供。Redis Cluster并没有使用一致性hash,而是采用slot(槽)的概念,一共分成16384个槽。将请求发送到任意节点,接收到请求的节点会将查询请求发送到正确的节点上执行。主要是针对海量数据+高并发+高可用的场景,如果是海量数据,如果你的数据量很大,那么建议就用Redis cluster,所有主节点的容量总和就是Redis cluster可缓存的数据容量.
单机的 redis,能够承载的 QPS 大概就在上万到几万不等。对于缓存来说,一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容,支撑读高并发.
Redis的复制功能是支持多个数据库之间的数据同步。主数据库可以进行读写操作,当主数据库的数据发生变化时会自动将数据同步到从数据库。从数据库一般是只读的,它会接收主数据库同步过来的数据。一个主数据库可以有多个从数据库,而一个从数据库只能有一个主数据库.
主从复制的原理?
PSYNC
命令给主节点; RDB
快照文件; RDB
文件生成完毕后, 主节点会将 RDB
文件发送给从节点,从节点会先将 RDB
文件 写入本地磁盘,然后再从本地磁盘加载到内存中 ; 主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点.
客户端连接Redis的时候,先连接哨兵,哨兵会告诉客户端Redis主节点的地址,然后客户端连接上Redis并进行后续的操作。当主节点宕机的时候,哨兵监测到主节点宕机,会重新推选出某个表现良好的从节点成为新的主节点,然后通过发布订阅模式通知其他的从服务器,让它们切换主机.
工作原理 。
Sentinel
以每秒钟一次的频率向它所知道的 Master
, Slave
以及其他 Sentinel
实例发送一个 PING
命令。 PING
命令的时间超过指定值, 则这个实例会被 Sentine
标记为主观下线。 Master
被标记为主观下线,则正在监视这个 Master
的所有 Sentinel
要以每秒一次的频率确认 Master
是否真正进入主观下线状态。 Sentinel
(大于等于配置文件指定值)在指定的时间范围内确认 Master
的确进入了主观下线状态, 则 Master
会被标记为客观下线 。若没有足够数量的 Sentinel
同意 Master
已经下线, Master
的客观下线状态就会被解除。 若 Master
重新向 Sentinel
的 PING
命令返回有效回复, Master
的主观下线状态就会被移除。 哨兵模式解决了主从复制不能自动故障转移、达不到高可用的问题,但还是存在主节点的写能力、容量受限于单机配置的问题。而cluster模式实现了Redis的分布式存储,每个节点存储不同的内容,解决主节点的写能力、容量受限于单机配置的问题.
Redis cluster集群节点最小配置6个节点以上(3主3从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用.
Redis cluster采用 虚拟槽分区 ,所有的键根据哈希函数映射到0~16383个整数槽内,每个节点负责维护一部分槽以及槽所映射的键值数据.
工作原理:
在 redis cluster 架构下,每个 redis 要放开两个端口号,比如一个是 6379,另外一个就是 加1w 的端口号,比如 16379.
16379 端口号是用来进行节点间通信的,也就是 cluster bus 的东西,cluster bus 的通信,用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议, gossip 协议,用于节点间进行高效的数据交换,占用更少的网络带宽和处理时间.
优点:
slot
存储分布在多个节点,节点间数据共享, 可动态调整数据分布 ; gossip
协议交换状态信息,用投票机制完成 Slave
到 Master
的角色转换。 缺点:
key
在同一节点上的事务操作,当多个 key
分布于不同的节点上时无法使用事务功能。 key
作为数据分区的最小粒度,不能将一个很大的键值对象如 hash
、 list
等映射到不同的节点。 哈希分区算法有哪些?
节点取余分区。使用特定的数据,如Redis的键或用户ID,对节点数量N取余:hash(key)%N计算出哈希值,用来决定数据映射到哪一个节点上。 优点是简单性。扩容时通常采用翻倍扩容,避免数据映射全部被打乱导致全量迁移的情况.
一致性哈希分区。为系统中每个节点分配一个token,范围一般在0~232,这些token构成一个哈希环。数据读写执行节点查找操作时,先根据key计算hash值,然后顺时针找到第一个大于等于该哈希值的token节点。 这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点,对其他节点无影响.
虚拟槽分区,所有的键根据哈希函数映射到0~16383整数槽内,计算公式:slot=CRC16(key)&16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。 Redis Cluser采用虚拟槽分区算法.
1、 被动删除 。在访问key时,如果发现key已经过期,那么会将key删除.
2、 主动删除 。定时清理key,每次清理会依次遍历所有DB,从db随机取出20个key,如果过期就删除,如果其中有5个key过期,那么就继续对这个db进行清理,否则开始清理下一个db.
3、 内存不够时清理 。Redis有最大内存的限制,通过maxmemory参数可以设置最大内存,当使用的内存超过了设置的最大内存,就要进行内存释放, 在进行内存释放的时候,会按照配置的淘汰策略清理内存.
当Redis的内存超过最大允许的内存之后,Redis 会触发内存淘汰策略,删除一些不常用的数据,以保证Redis服务器正常运行.
Redisv4.0前提供 6 种数据淘汰策略 :
Least Recently Used
),最近使用。利用LRU算法移除设置了过期时间的key Redisv4.0后增加以下两种 :
内存淘汰策略可以通过配置文件来修改 ,相应的配置项是 maxmemory-policy ,默认配置是 noeviction .
1、先删除缓存再更新数据库 。
进行更新操作时,先删除缓存,然后更新数据库,后续的请求再次读取时,会从数据库读取后再将新数据更新到缓存.
存在的问题:删除缓存数据之后,更新数据库完成之前,这个时间段内如果有新的读请求过来,就会从数据库读取旧数据重新写到缓存中,再次造成不一致,并且后续读的都是旧数据.
2、先更新数据库再删除缓存 。
进行更新操作时,先更新MySQL,成功之后,删除缓存,后续读取请求时再将新数据回写缓存.
存在的问题:更新MySQL和删除缓存这段时间内,请求读取的还是缓存的旧数据,不过等数据库更新完成,就会恢复一致,影响相对比较小.
3、异步更新缓存 。
数据库的更新操作完成后不直接操作缓存,而是把这个操作命令封装成消息扔到消息队列中,然后由Redis自己去消费更新数据,消息队列可以保证数据操作顺序一致性,确保缓存系统的数据正常.
以上几个方案都不完美,需要根据业务需求,评估哪种方案影响较小,然后选择相应的方案.
缓存穿透是指查询一个 不存在的数据 ,由于缓存是不命中时被动写的,如果从DB查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到DB去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了.
怎么解决?
bitmap
中,查询不存在的数据会被这个 bitmap
拦截掉,从而避免了对 DB
的查询压力。 布隆过滤器的原理:当一个元素被加入集合时,通过K个哈希函数将这个元素映射成一个位数组中的K个点,把它们置为1。查询时,将元素通过哈希函数映射之后会得到k个点,如果这些点有任何一个0,则被检元素一定不在,直接返回;如果都是1,则查询元素很可能存在,就会去查询Redis和数据库.
布隆过滤器一般用于在大数据量的集合中判定某元素是否存在.
缓存雪崩是指在我们设置缓存时采用了相同的过期时间, 导致缓存在某一时刻同时失效 ,请求全部转发到DB,DB瞬时压力过重挂掉.
解决方法:
缓存击穿:大量的请求同时查询一个 key 时,此时这个 key 正好失效了,就会导致大量的请求都落到数据库。 缓存击穿是查询缓存中失效的 key,而缓存穿透是查询不存在的 key.
解决方法:
1、 加互斥锁 。在并发的多个请求中,只有第一个请求线程能拿到锁并执行数据库查询操作,其他的线程拿不到锁就阻塞等着,等到第一个线程将数据写入缓存后,直接走缓存。可以使用Redis分布式锁实现,代码如下:
public String get(String key) {
String value = redis.get(key);
if (value == null) { //缓存值过期
String unique_key = systemId + ":" + key;
//设置30s的超时
if (redis.set(unique_key, 1, 'NX', 'PX', 30000) == 1) { //设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(unique_key);
} else { //其他线程已经到数据库取值并回写到缓存了,可以重试获取缓存值
sleep(50);
get(key); //重试
}
} else {
return value;
}
}
2、 热点数据不过期 。直接将缓存设置为不过期,然后由定时任务去异步加载数据,更新缓存。这种方式适用于比较极端的场景,例如流量特别特别大的场景,使用时需要考虑业务能接受数据不一致的时间,还有就是异常情况的处理,保证缓存可以定时刷新.
缓存预热就是系统上线后,将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据! 。
解决方案:
当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级.
缓存降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算).
在进行降级之前要对系统进行梳理,看看系统是不是可以丢卒保帅;从而梳理出哪些必须誓死保护,哪些可降级;比如可以参考日志级别设置预案:
服务降级的目的,是为了防止Redis服务故障,导致数据库跟着一起发生雪崩问题。因此,对于不重要的缓存数据,可以采取服务降级策略,例如一个比较常见的做法就是,Redis出现问题,不去数据库查询,而是直接返回默认值给用户.
使用list类型保存数据信息,rpush生产消息,lpop消费消息,当lpop没有消息时,可以sleep一段时间,然后再检查有没有信息,如果不想sleep的话,可以使用blpop, 在没有信息的时候,会一直阻塞,直到信息的到来.
BLPOP queue 0 //0表示不限制等待时间
BLPOP和LPOP命令相似,唯一的区别就是当列表没有元素时BLPOP命令会一直阻塞连接,直到有新元素加入.
redis可以通过pub/sub 主题订阅模式 实现一个生产者,多个消费者,当然也存在一定的缺点,当消费者下线时,生产的消息会丢失.
PUBLISH channel1 hi
SUBSCRIBE channel1
UNSUBSCRIBE channel1 //退订通过SUBSCRIBE命令订阅的频道。
PSUBSCRIBE channel?* 按照规则订阅。 PUNSUBSCRIBE channel?* 退订通过PSUBSCRIBE命令按照某种规则订阅的频道。其中订阅规则要进行严格的字符串匹配, PUNSUBSCRIBE * 无法退订 channel?* 规则.
使用sortedset,拿时间戳作为score,消息内容作为key,调用zadd来生产消息,消费者用 zrangebyscore 指令获取N秒之前的数据轮询进行处理.
redis客户端执行一条命令分4个过程: 发送命令、命令排队、命令执行、返回结果。使用 pipeline 可以批量请求,批量返回结果,执行速度比逐条执行要快.
使用 pipeline 组装的命令个数不能太多,不然数据量过大,增加客户端的等待时间,还可能造成网络阻塞,可以将大量命令的拆分多个小的 pipeline 命令完成.
原生批命令(mset和mget)与 pipeline 对比:
原生批命令是原子性, pipeline 是 非原子性 。pipeline命令中途异常退出,之前执行成功的命令 不会回滚 .
原生批命令只有一个命令,但 pipeline 支持多命令 .
Redis 通过 LUA 脚本创建具有原子性的命令: 当lua脚本命令正在运行的时候,不会有其他脚本或 Redis 命令被执行,实现组合命令的原子操作.
在Redis中执行Lua脚本有两种方法: eval 和 evalsha 。 eval 命令使用内置的 Lua 解释器,对 Lua 脚本进行求值.
//第一个参数是lua脚本,第二个参数是键名参数个数,剩下的是键名参数和附加参数
> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"
lua脚本作用 。
1、Lua脚本在Redis中是原子执行的,执行过程中间不会插入其他命令.
2、Lua脚本可以将多条命令一次性打包,有效地减少网络开销.
应用场景 。
举例:限制接口访问频率.
在Redis维护一个接口访问次数的键值对, key 是接口名称, value 是访问次数。每次访问接口时,会执行以下操作:
aop
拦截接口的请求,对接口请求进行计数,每次进来一个请求,相应的接口访问次数 count
加1,存入redis。 count=1
,并设置过期时间。因为这里 set()
和 expire()
组合操作不是原子操作,所以引入 lua
脚本,实现原子操作,避免并发访问问题。
private String buildLuaScript() {
return "local c" +
"\nc = redis.call('get',KEYS[1])" +
"\nif c and tonumber(c) > tonumber(ARGV[1]) then" +
"\nreturn c;" +
"\nend" +
"\nc = redis.call('incr',KEYS[1])" +
"\nif tonumber(c) == 1 then" +
"\nredis.call('expire',KEYS[1],ARGV[2])" +
"\nend" +
"\nreturn c;";
}
String luaScript = buildLuaScript();
RedisScript<Number> redisScript = new DefaultRedisScript<>(luaScript, Number.class);
Number count = redisTemplate.execute(redisScript, keys, limit.count(), limit.period());
PS:这种接口限流的实现方式比较简单,问题也比较多,一般不会使用,接口限流用的比较多的是令牌桶算法和漏桶算法.
Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock ,此种方式比原先的单节点的方法更安全。它可以保证以下特性:
通常我们会将含有较大数据或含有大量成员、列表数的Key称之为大Key.
以下是对各个数据类型大key的描述:
上述的定义并不绝对,主要是根据value的成员数量和大小来确定,根据业务场景确定标准.
怎么处理:
第一种情况,可能是覆盖之前的key,导致key过期时间发生了改变.
当一个key在Redis中已经存在了,但是由于一些误操作使得key过期时间发生了改变,从而导致这个key在应该过期的时间内并没有过期,从而造成内存的占用.
第二种情况是,Redis过期key的处理策略导致内存没释放.
一般Redis对过期key的处理策略有两种:惰性删除和定时删除.
先说惰性删除的情况 。
当一个key已经确定设置了xx秒过期同时中间也没有修改它,xx秒之后它确实已经过期了,但是惰性删除的策略它并不会马上删除这个key,而是当再次读写这个key时它才会去检查是否过期,如果过期了就会删除这个key。也就是说,惰性删除策略下,就算key过期了,也不会立刻释放内容,要等到下一次读写这个key才会删除key.
而定时删除会在一定时间内主动淘汰一部分已经过期的数据,默认的时间是每100ms过期一次。因为定时删除策略每次只会淘汰一部分过期key,而不是所有的过期key,如果redis中数据比较多的话要是一次性全量删除对服务器的压力比较大,每一次只挑一批进行删除,所以很可能出现部分已经过期的key并没有及时的被清理掉,从而导致内存没有即时被释放.
存在bigkey 。如果Redis实例中存储了 bigkey,那么在淘汰删除 bigkey 释放内存时,也会耗时比较久。应该避免存储 bigkey,降低释放内存的耗时.
如果Redis 实例 设置了内存上限 maxmemory ,有可能导致 Redis 变慢。当 Redis 内存达到 maxmemory 后,每次写入新的数据之前,Redis 必须先从实例中踢出一部分数据,让整个实例的内存维持在 maxmemory 之下,然后才能把新数据写进来.
开启了内存大页 。当 Redis 在执行后台 RDB 和 AOF rewrite 时,采用 fork 子进程的方式来处理。但主进程 fork 子进程后,此时的主进程依旧是可以接收写请求的,而进来的写请求,会采用 Copy On Write(写时复制)的方式操作内存数据.
什么是写时复制?
这样做的好处是,父进程有任何写操作,并不会影响子进程的数据持久化.
不过,主进程在拷贝内存数据时,会涉及到新内存的申请,如果此时操作系统开启了内存大页,那么在此期间,客户端即便只修改 10B 的数据,Redis 在申请内存时也会以 2MB 为单位向操作系统申请,申请内存的耗时变长,进而导致每个写请求的延迟增加,影响到 Redis 性能.
解决方案就是关闭内存大页机制.
使用了Swap 。操作系统为了缓解内存不足对应用程序的影响,允许把一部分内存中的数据换到磁盘上,以达到应用程序对内存使用的缓冲,这些内存数据被换到磁盘上的区域,就是 Swap。当内存中的数据被换到磁盘上后,Redis 再访问这些数据时,就需要从磁盘上读取,访问磁盘的速度要比访问内存慢几百倍。尤其是针对 Redis 这种对性能要求极高、性能极其敏感的数据库来说,这个操作延时是无法接受的。解决方案就是增加机器的内存,让 Redis 有足够的内存可以使用。或者整理内存空间,释放出足够的内存供 Redis 使用 。
网络带宽过载 。网络带宽过载的情况下,服务器在 TCP 层和网络层就会出现数据包发送延迟、丢包等情况。Redis 的高性能,除了操作内存之外,就在于网络 IO 了,如果网络 IO 存在瓶颈,那么也会严重影响 Redis 的性能。解决方案:1、及时确认占满网络带宽 Redis 实例,如果属于正常的业务访问,那就需要及时扩容或迁移实例了,避免因为这个实例流量过大,影响这个机器的其他实例。2、运维层面,需要对 Redis 机器的各项指标增加监控,包括网络流量,在网络流量达到一定阈值时提前报警,及时确认和扩容.
频繁短连接 。频繁的短连接会导致 Redis 大量时间耗费在连接的建立和释放上,TCP 的三次握手和四次挥手同样也会增加访问延迟。应用应该使用长连接操作 Redis,避免频繁的短连接.
Redis Cluster 采用数据分片机制,定义了 16384个 Slot槽位,集群中的每个Redis 实例负责维护一部分槽以及槽所映射的键值数据.
Redis每个节点之间会定期发送ping/pong消息(心跳包包含了其他节点的数据),用于交换数据信息.
Redis集群的节点会按照以下规则发ping消息:
心跳包的消息头里面有个myslots的char数组,是一个bitmap,每一个位代表一个槽,如果该位为1,表示这个槽是属于这个节点的.
接下来,解答为什么 Redis 集群的最大槽数是 16384 个,而不是65536 个.
1、如果采用 16384 个插槽,那么心跳包的消息头占用空间 2KB (16384/8);如果采用 65536 个插槽,那么心跳包的消息头占用空间 8KB (65536/8)。可见采用 65536 个插槽, 发送心跳信息的消息头达8k,比较浪费带宽 .
2、一般情况下一个Redis集群 不会有超过1000个master节点 ,太多可能导致网络拥堵.
3、哈希槽是通过一张bitmap的形式来保存的,在传输过程中,会对bitmap进行压缩。bitmap的填充率越低, 压缩率 越高。其中bitmap 填充率 = slots / N (N表示节点数)。所以,插槽数越低, 填充率会降低,压缩率会提高.
最后此篇关于一天吃透Redis面试八股文的文章就讲到这里了,如果你想了解更多关于一天吃透Redis面试八股文的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我有一个关于 Redis Pubsub 的练习,如下所示: 如果发布者发布消息但订阅者没有收到服务器崩溃。订阅者如何在重启服务器时收到该消息? 请帮帮我,谢谢! 最佳答案 在这种情况下,消息将永远消失
我们正在使用 Service Stack 的 RedisClient 的 BlockingDequeue 来保存一些数据,直到它可以被处理。调用代码看起来像 using (var client =
我有一个 Redis 服务器和多个 Redis 客户端。每个 Redis 客户端都是一个 WebSocket+HTTP 服务器,其中包括管理 WebSocket 连接。这些 WebSocket+HTT
我有多个 Redis 实例。我使用不同的端口创建了一个集群。现在我想将数据从预先存在的 redis 实例传输到集群。我知道如何将数据从一个实例传输到集群,但是当实例多于一个时,我无法做到这一点。 最佳
配置:三个redis集群分区,跨三组一主一从。当 Master 宕机时,Lettuce 会立即检测到中断并开始重试。但是,Lettuce 没有检测到关联的 slave 已经将自己提升为 master
我想根据从指定集合中检索这些键来删除 Redis 键(及其数据集),例如: HMSET id:1 password 123 category milk HMSET id:2 password 456
我正在编写一个机器人(其中包含要禁用的命令列表),用于监视 Redis。它通过执行禁用命令,例如 (rename-command ZADD "")当我重新启动我的机器人时,如果要禁用的命令列表发生变化
我的任务是为大量听众使用发布/订阅。这是来自 docs 的订阅的简化示例: r = redis.StrictRedis(...) p = r.pubsub() p.subscribe('my-firs
我一直在阅读有关使用 Redis 哨兵进行故障转移的内容。我打算有1个master+1个slave,如果master宕机超过1分钟,就把slave变成master。我知道这在 Sentinel 中是
与仅使用常规 Redis 和创建分片相比,使用 Redis 集群有哪些优势? 在我看来,Redis Cluster 更注重数据安全(让主从架构解决故障)。 最佳答案 我认为当您需要在不丢失任何数据的情
由于 Redis 以被动和主动方式使 key 过期, 有没有办法得到一个 key ,即使它的过期时间已过 (但 在 Redis 中仍然存在 )? 最佳答案 DEBUG OBJECT myKey 将返回
我想用redis lua来实现monitor命令,而不是redis-cli monitor。但我不知道怎么办。 redis.call('monitor') 不起作用。 最佳答案 您不能从 Redis
我读过 https://github.com/redisson/redisson 我发现有几个 Redis 复制设置(包括对 AWS ElastiCache 和 Azure Redis 缓存的支持)
Microsoft.AspNet.SignalR.Redis 和 StackExchange.Redis.Extensions.Core 在同一个项目中使用。前者需要StackExchange.Red
1. 认识 Redis Redis(Remote Dictionary Server)远程词典服务器,是一个基于内存的键值对型 NoSQL 数据库。 特征: 键值(key-value)型,value
1. Redis 数据结构介绍 Redis 是一个 key-value 的数据库,key 一般是 String 类型,但 value 类型多种多样,下面就举了几个例子: value 类型 示例 Str
1. 什么是缓存 缓存(Cache) 就是数据交换的缓冲区,是存贮数据的临时地方,一般读写性能较高。 缓存的作用: 降低后端负载 提高读写效率,降低响应时间 缓存的成本: 数据一致性成本 代码维护成本
我有一份记录 list 。对于我的每条记录,我都需要进行一些繁重的计算,因为我要在Redis中创建反向索引。为了达到到达记录,需要在管道中执行多个redis命令(sadd为100 s + set为1
我有一个三节点Redis和3节点哨兵,一切正常,所有主服务器和从属服务器都经过验证,并且哨兵配置文件已与所有Redis和哨兵节点一起更新,但是问题是当Redis主服务器关闭并且哨兵希望选举失败者时再次
我正在尝试计算Redis中存储的消息之间的响应时间。但是我不知道该怎么做。 首先,我必须像这样存储chat_messages的时间流 ZADD conversation:CONVERSATION_ID
我是一名优秀的程序员,十分优秀!