由于 Redis 只使用单核，而 Memcached 可以使用多核，所以平均每一个核上 Redis 在存储小数据时比Memcached 性能更高。而在 100k 以上的数据中，Memcached 性能要高于 Redis。虽然Redis 最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色

8、说说redis常用应用场景

缓存
排行榜
计数器
分布式会话
分布式锁
社交网络
消息队列
位操作

二、数据类型

1、redis有哪些数据类型，分别适用于什么场景？

String

这是最简单的类型，就是普通的 set 和 get，做简单的 KV 缓存。场景：缓存、计数、限流等

Lua 复制代码

set college szu

Hash

这个是类似 map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在 Redis 里，然后每次读写缓存的时候，可以就操作 hash里的某个字段。场景：用户信息、商品信息等

hset person name bingo

hset person age 20

hset person id 1

hget person name

person = {

"name": "bingo",

"age": 20,

"id": 1

}

List

Lists 是有序列表，这个可以玩儿出很多花样。

比如可以通过 list 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的东西。

比如可以通过 lrange 命令，读取某个闭区间内的元素，可以基于 list 实现分页查询，这个是很

棒的一个功能，基于 Redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东

西，性能高，就一页一页走

0开始位置，-1结束位置，结束位置为-1时，表示列表的最后一个位置，即查看所有。

lrange mylist 0 -1

比如可以搞个简单的消息队列，从 list 头怼进去，从 list 尾巴那里弄出来。

lpush mylist 1

lpush mylist 2

lpush mylist 3 4 5

1

rpop mylist

Set

Sets 是无序集合，自动去重，可以基于 set 玩儿交集、并集、差集的操作。常用于进行标签管理等

#-------操作一个set-------

添加元素

sadd mySet 1

查看全部元素

smembers mySet

判断是否包含某个值

sismember mySet 3

删除某个/些元素

srem mySet 1

srem mySet 2 4

查看元素个数

scard mySet# 随机删除一个元素

spop mySet

#-------操作多个set-------

将一个set的元素移动到另外一个set

smove yourSet mySet 2

求两set的交集

sinter yourSet mySet

求两set的并集

sunion yourSet mySet

求在yourSet中而不在mySet中的元素

sdiff yourSet mySet

Sorted Set

Sorted Sets 是排序的 set，去重但可以排序，写进去的时候给一个分数，自动根据分数排序。排行榜。

zadd board 85 zhangsan

zadd board 72 lisi

zadd board 96 wangwu

zadd board 63 zhaoliu

2、说说Redis底层数据结构？

Redis有动态字符串( sds ) 、链表 (list) 、字典( ht ) 、跳跃表 (skiplist) 、整数集合(intset) 、**压缩列表(ziplist)**等底层数据结构。 Redis并没有使用这些数据结构来直接实现键值对数据库，而是基于这些数据结构创建了一个对象系统，来表示所有的key-value

我们常用的数据类型和编码对应的映射关系：

三、架构

1、redis 持久化机制

（1）Redis 的持久化机制

Redis 的持久化机制有：RDB、AOF、混合持久化（RDB+AOF，Redis 4.0引入）。RDB 和 AOF 都是 Redis 里面提供的持久化机制，RDB 是通过快照方式实现持久化、AOF 是通过命令追加的方式实现持久化

RDB

RDB 持久化机制会根据快照触发条件，把内存里面的数据快照写入到磁盘，以二进制的压缩文件进行存储

RDB 快照的触发方式有很多，比如

执行 bgsave 命令触发异步快照，执行 save 命令触发同步快照，同步快照会阻塞客户端的执行指令。
根据 redis.conf 文件里面的配置，自动触发 bgsave
主从复制的时候触发
AOF

AOF持久化机制是近乎实时的方式来完成持久化的，就是客户端执行一个数据变更的操作，Redis Server 就会把这个命令追加到 aof 缓冲区的末尾，然后再把缓冲区的数据写入到磁盘的 AOF 文件里面，至于最终什么时候真正持久化到磁盘，是根据刷盘的策略来决定的

为了避免追加的方式导致 AOF 文件过大的问题，Redis 提供了 AOF 重写机制(如图），也就是说当 AOF 文件的大小达到某个阈值的时候，就会把这个文件里面相同的指令进行压缩

AOF 三种策略

为了控制Redis服务器在遇到意外停机时丢失的数据量，Redis为AOF持久化提供了appendfsync选项，这个选项的值可以是always,everysec或者noappendfsync

always：总是写入aof文件，并通过事件循环磁盘同步，即使Redis遭遇意外停机时，最多只丢失一事件循环内的执行的数据
appendfsync everysec：每一秒写入aof文件，并完成磁盘同步，即使Redis遭遇意外停机时，最多只丢失一秒钟内的执行的数据
appendfsync no：服务器不主动调用fdatasync,由操作系统决定任何将缓冲区里面的命令写入到硬盘里，这种模式下，服务器遭遇意外停机时，丢失的命令的数量是不确定的

（2）RDB和AOF 比较

RDB 是每隔一段时间触发持久化，因此数据安全性低，AOF 可以做到实时持久化，数据安全性较高
RDB 文件默认采用压缩的方式持久化，AOF 存储的是执行指令，所以 RDB 在数据恢复的时候性能比 AOF 要好

（3）混合持久化

只发生于 AOF 重写过程。使用了混合持久化，重写后的新 AOF 文件前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。

2、redis集群高可用

Redis高可用常见的有三种方式：

（1）Replication-Sentinel哨兵模式

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。

Redis sentinel 其中三个特性：

监控（Monitoring）：

Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）：

当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）：

当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

哨兵本身也有单点故障的问题，可以使用多个哨兵进行监控，哨兵不仅会监控redis集群，哨兵之间也会相互监控。

每一个哨兵都是一个独立的进程，作为进程，它会独立运行。

特点：

保证高可用
监控各个节点
自动故障迁移

缺点：

主从模式，切换需要时间丢数据
没有解决 master 写的压力

Redis哨兵系统是怎么实现自动故障转移的？

1.认定主节点主观下线

因为每隔2s，哨兵节点会给主节点发送PING命令，如果在一定时间间隔内，都没有收到回复，那么哨兵节点就认为主节点主观下线。

2.认定主节点客观下线

哨兵节点认定主节点主观下线后，会向其他哨兵节点发送sentinel is-master-down-by-addr命令，获取其他哨兵节点对该主节点的状态，当认定主节点下线的哨兵数量达到一定数值时(这个阀值是Sentinel配置中quorum参数的值，通常我们设置为哨兵总节点数的1/2)，就认定主节点客观下线。

3.进行领导者哨兵选举

认定主节点客观下线后,各个哨兵之间相互通信，选举出一个领导者哨兵，由它来对主节点进行故障转移操作。

选举使用的是Raft算法，基本思路是所有哨兵节点A会向其他哨兵节点发送命令，申请成为该哨兵节点B的领导者，如果B还没有同意过其他哨兵节点，那么就同意A成为领导者，最终得票超过半数以上的哨兵节点会赢得选举，如果本次投票，没有选举出领导者哨兵，那么就开始新一轮的选举，直到选举出哨兵节点（实际开发中，最先判定主节点客观下线的哨兵节点，一般就能成为领导者。）

领导者哨兵进行故障转移

领导者哨兵节点首先会从从节点中选出一个节点作为新的主节点。选择的规则是：

1.首先排除一些不健康的节点。（下线的，断线的，最近5s没有回复哨兵节点的INFO命令的，与旧的主服务器断开连接时间较长的）
2.然后根据优先级，复制偏移量，runid最小，来选出一个从节点作为主节点。

向这个从节点发送slaveof no one命令，让其成为主节点，通过slaveof 命令让其他从节点成为它的从节点，将已下线的主节点更新为新的主节点的从节点，将其他从节点的复制目标改为新的主节点，将旧的主服务器改为从服务器。

（2）Redis-Cluster集群模式

redis在3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的数据。

cluster模式为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

RedisCluster 是 Redis 的亲儿子，它是 Redis 作者自己提供的 Redis 集群化方案。

相对于 Codis 的不同，它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。这三个节点相互连接组成一个对等的集群，它们之间通过一种特殊的二进制协议相互交互集群信息。

如上图，官方推荐，集群部署至少要 3 台以上的master节点，最好使用 3 主 3 从六个节点的模式。

Redis Cluster 将所有数据划分为 16384 的 slots，它比 Codis 的 1024 个槽划分得更为精细，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中，它不像 Codis，它不需要另外的分布式存储来存储节点槽位信息。 Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现)，采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。

Redis Cluster集群采用了P2P的模式，完全去中心化。

3 主 3 从六个节点的Redis集群（Redis-Cluster） Redis 集群是一个提供在多个Redis节点间共享数据的程序集。下图以三个master节点和三个slave节点作为示例。

Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽，如图中slots所示。

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有1-n个从节点。例如master-A节点不可用了，集群便会选举slave-A节点作为新的主节点继续服务。

3、redis事务怎么理解？

multi 开启事务

exec 提交事务

discard 回滚事务

4、redis的过期策略及内存淘汰机制？

1.过期策略

定期删除：每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除
惰性删除 ：获取 key 的时候，如果此时 key已经过期，就删除，不会返回任何东西

2.内存淘汰机制：

noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错
**allkeys-lru：**移除最近最少使用的 key
**allkeys-random：**随机移除某个 key
**volatile-lru：**在设置了过期时间的键空间中，移除最近最少使用的 key
**volatile-random：**在设置了过期时间的键空间中，随机移除某个 key
**volatile-ttl：**设置了过期时间的键空间中，有更早过期时间的 key 优先移除

5、布隆过滤器是什么？

布隆过滤器可以理解为一个有误差的set结构，使用布隆过滤器来判断元素是否存在其中时，如果返回结果是存在，实际可能存在也可能不存在，返回结果不存在时，实际结果肯定是不存在。

布隆过滤器实际上是一个大型的位数组，添加key时，通过几个hash函数对key计算得到多个hash值，将每个hash值与布隆过滤器的位数组的size取模得到下标，然后将数组中这些下标位置的值都设置为1。

创建key为userid的布隆过滤器，0.01是误判率，10000是初始大小

127.0.0.1:6379> bf.reserve userid 0.01 100000

调用exist指令判断181920是否存在于布隆过滤器，如果返回0，不存在，那么说明一定不存在，如果返回1，代表可能存在，也可能不存在。

127.0.0.1:6379> bf.add userid '181920' (integer) 1

布隆过滤器也有一些缺点：

它在判断元素是否在集合中时是有一定错误几率，因为哈希算法有一定的碰撞的概率。
不支持删除元素。

6、如何保证数据库和缓存数据的一致性

1.延时双删

先删除缓存
更新数据库
线程等待 N秒（等待时间根据具体业务来判断）
再删除缓存

2.采用canal组件监控MySQL的binlog日志，把更新后的数据同步到redis里面

更新数据库
更新redis的数据
canal组件从binlog加载数据，然后同步到redis

3.基于 RocketMQ 的可靠性消息通信，来实现最终一致性。

7、redis 分布式锁如何实现

1、加锁时要设置过期时间SET lock_key unique_value EX expire_time NX

2、操作共享资源

3、释放锁：Lua脚本，先GET判断锁是否归属自己，再DEL释放锁

集群模式+Redlock实现高可靠的分布式锁

让客户端和多个独立的Redis实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败。

https://blog.csdn.net/fuzhongmin05/article/details/119251590

四、场景

1、缓存穿透、缓存击穿、缓存雪崩

（1）缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和持久层都不会命中。

解决方案：参数校验、缓存空对象及布隆过滤器

（2）缓存击穿

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

解决方案：永不过期或分布式互斥锁

（3）缓存雪崩

缓存层宕机或者大量缓存同时失效，请求直接到达存储层，存储层压力过大导致系统雪崩。

解决方案：缓存高可用、避免缓存同时失效及采用多级缓存

2、怎么使用redis实现消息队列

基于List的LPUSH+BRPOP实现
基于Zset
PUB/SUB
基于Stream类型

3、什么是bigkey，有什么影响？

字符串类型：单个value值很大，一般超过10KB就是bigkey
非字符串类型：体现在元素过多

危害：

内存空间不均匀，redis cluster中，bigkey造成节点内存空间使用不均与
超时阻塞，redis单线程，操作bigkey比较好使，阻塞redis的可能性增大
网络拥塞，每次获取bigkey产生的网络流量较大

4、怎么处理热key?

**什么是热Key？**所谓的热key，就是访问频率比较的key。
怎么处理热key？

对热key的处理，最关键的是对热点key的监控，可以从这些端来监控热点key:

客户端客户端其实是距离key"最近"的地方，因为Redis命令就是从客户端发出的，例如在客户端设置全局字典（key和调用次数），每次调用Redis命令时，使用这个字典进行记录。
代理端像Twemproxy、Codis这些基于代理的Redis分布式架构，所有客户端的请求都是通过代理端完成的，可以在代理端进行收集统计。
Redis服务端使用monitor命令统计热点key是很多开发和运维人员首先想到，monitor命令可以监控到Redis执行的所有命令。

只要监控到了热key，对热key的处理就简单了：

把热key打散到不同的服务器，降低压⼒
加⼊⼆级缓存，提前加载热key数据到内存中，如果redis宕机，⾛内存查询

5、缓存预热怎么做呢？

所谓缓存预热，就是提前把数据库里的数据刷到缓存里，通常有这些方法：

直接写个缓存刷新页面或者接口，上线时手动操作
数据量不大，可以在项目启动的时候自动进行加载
定时任务刷新缓存

6、Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

对方接着追问：

如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：

redis的单线程的。

keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。

这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

JAVA工程师面试专题-《Redis》篇

一、基础

1、Redis 是什么

2、说一下你对redis的理解

3、Redis 为什么这么快？

4、项目中如何使用缓存？

5、为什么使用缓存？

6、Redis key 和value 可以存储最大值分别多是多少？

7、Redis和memcache有什么区别？