JAVA八股文

2025年 Java 面试八股文（20w字）_java面试八股文-CSDN博客

五、Redis

1.介绍下Redis Redis有哪些数据类型 

redis是基于内存的key-value结构数据库，以键值对存储

局域内存存储，读写性能高

适合存储热点数据（热点商品、资讯、新闻）

redis不是来取代mysql的，是对mysql的补充，在项目中redis和mysql往往是共存的，互相补充的关系。

key-value：

key是字符串类型，value有5中常用的数据类型

string字符串、hash哈希、list列表、set集合、sorted set/zset有序集合

string：普通字符串

hash：也叫散列，类似于java中的hashmap结构，适合存储对象

list：按照插入顺序排序，可以有重复元素，类似java的linkedlist

set：无序集合，没有重复元素，类似java中的hashset

sorted set：集合中每一个元素关联一个分数，根据分数升序排序，没有重复元素

redis常用命令：

string：

SET key value：设置指定key的值

GET key：获取指定key的值

SETEX key seconds value：设置指定key的值，并将key的过期时间设为seconds秒

SETEX key value:只有key不存在时设置key的值

hash：

是一个string类型的field和value的映射表

HSET key field value：将哈希表key中的字段filed的值设为value

HGET key field：获取存储在哈希表中指定字段的值

HDEL key field:删除村村在哈希表中指定字段

HKEYS key：获取哈希表中所有字段

HVALS key：获取哈希表中所有值

list：

是简单的字符串列表，按照插入顺序排序

LPUSH key value1[value2]:将一个或多个值插入到列表头部

LRANGE key start stop:获取列表指定范围内的元素

RPOP key:移除并获取列表最后一个元素

LLEN key:获取列表长度

set：

string类型的无序集合。集合成员是唯一的，集合中不能出现重复的数据

SADD key member1[member2]:向集合添加一个或多个成员

SMEMBERS key:返回集合中的所有成员

SCARD key:获取集合的成员数

SINTER key1[key2]:返回给定所有集合的交集

SUNION key1:返回所有给定集合的并集

SREM key member1[member2]:删除集合中一个或多个成员

有序集合：

string类型元素的集合，且不允许有重复成员。每个元素都关联一个bouble类型的分数

ZADD key score1 member1[score2 member2]:向有序集合添加一个或多个成员

ZRANGE key start stop[WITHSCORES]:通过索引取件返回有序集合中指定区间内的成员

ZINCRBY key increment member:有序集合中对指定成员的分数加上一个增量increment

ZREM key member[member...]:移除有序集合中的一个或多个成员

通用命令：

不分数据类型，都可以使用

KEYS pattern：查找所有符合给定模式(pattern)的key

EXISTS key：检查给定key是否存在

TYPE key：返回key所存储的值的类型

DEL key：该命令用于在key存在时删除key

2.Redis提供了哪几种持久化方式

Redis 提供了 两种核心持久化方式：RDB（快照）和 AOF（追加日志），同时从 Redis 4.0 开始支持 混合持久化（RDB + AOF 结合）。

1. RDB（Redis Database）

核心原理：

定期生成数据的 快照（二进制文件，默认保存为 dump.rdb），记录某一时刻的完整数据状态。

通过 SAVE（阻塞主线程）或 BGSAVE（子进程后台异步执行）命令手动触发，也可在配置文件中设置自动触发条件（如 save 60 10000 表示 60 秒内有 10000 次修改则触发）。

优点：

恢复速度快：二进制文件紧凑，加载速度快。

适合备份与容灾：单个文件便于迁移和恢复。

对性能影响小：后台异步生成快照，主线程基本无阻塞。

缺点：

数据丢失风险：若两次快照之间 Redis 宕机，会丢失期间的数据。

大数据量时耗时：生成快照时可能占用较多内存和 CPU。

适用场景：

允许部分数据丢失（如缓存场景）。

需要快速恢复数据的场景。

2. AOF（Append-Only File）

核心原理：

记录所有 写操作命令（以 Redis 协议格式追加到文件，默认保存为 appendonly.aof），重启时通过重放命令恢复数据。

支持三种同步策略（通过 appendfsync 配置）：

no：由操作系统决定何时同步（性能高，风险最大）。

everysec：每秒同步一次（平衡性能与安全，默认选项）。

always：每次写操作都同步（最安全，性能最低）。

优点：

数据可靠性高：最多丢失 1 秒数据（everysec 策略下）。

可读性强：AOF 文件为文本格式，便于人工分析或修复。

灵活控制持久化粒度：支持重写（BGREWRITEAOF）压缩冗余命令。

缺点：

文件体积大：长期运行后 AOF 文件可能远大于 RDB。

恢复速度慢：重放所有命令耗时长（尤其是大文件）。

适用场景：

对数据安全性要求高（如金融交易场景）。

允许牺牲部分性能换取数据完整性。

3. 混合持久化（RDB + AOF）

核心原理（Redis 4.0+ 支持）：

开启 AOF 后，通过配置 aof-use-rdb-preamble yes，在 AOF 文件中 结合 RDB 快照和增量 AOF 日志。

触发机制：

执行 BGREWRITEAOF 时，先以 RDB 格式写入当前数据快照，后续增量操作以 AOF 格式追加。

优点：

快速恢复：重启时先加载 RDB 快照，再重放少量 AOF 命令，速度显著提升。

数据完整性：结合 RDB 的紧凑性和 AOF 的实时性。

缺点：

兼容性要求：需 Redis 4.0 及以上版本。

文件结构复杂：混合格式的 AOF 文件可读性降低。

如何选择持久化方式？

场景	推荐方式
允许少量数据丢失	RDB
要求数据高可靠	AOF（appendfsync everysec）
需快速恢复且减少数据丢失	混合持久化（RDB + AOF）
容灾备份	定期手动执行 BGSAVE 生成 RDB

总结

RDB：简单高效，适合备份和快速恢复，但可能丢失数据。

AOF：数据更安全，但文件大、恢复慢。

混合持久化：综合两者优势，是 Redis 4.0+ 的推荐方案。

3.Redis为什么快

1)完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)

2)数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的

3)采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗

4)使用I/O多路复用模型，非阻塞IO

5)使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

4.Redis为什么是单线程的

官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了Redis利用队列技术将并发访问变为串行访问

1）绝大部分请求是纯粹的内存操作

2）采用单线程,避免了不必要的上下文切换和竞争条件

5.Redis服务器的的内存是多大

配置文件中设置redis内存的参数：。

该参数如果不设置或者设置为0，则redis默认的内存大小为：

32位下默认是3G

64位下不受限制

一般推荐Redis设置内存为最大物理内存的四分之三，也就是0.75

命令行设置config set maxmemory <内存大小，单位字节>，服务器重启失效

config get maxmemory获取当前内存大小

永久则需要设置maxmemory参数，maxmemory是bytes字节类型，注意转换

6.为什么Redis的操作是原子性的，怎么保证原子性的

对于Redis而言，命令的原子性指的是：一个操作的不可以再分，操作要么执行，要么不执行。

Redis的操作之所以是原子性的，是因为Redis是单线程的。

Redis本身提供的所有API都是原子操作，Redis中的事务其实是要保证批量操作的原子性。

多个命令在并发中也是原子性的吗？

不一定， 将get和set改成单命令操作，incr 。使用Redis的事务，或者使用Redis+Lua==的方式实现.

7.Redis有事务吗

Redis是有事务的，redis中的事务是一组命令的集合，这组命令要么都执行，要不都不执行，

redis事务的实现，需要用到MULTI（事务的开始）和EXEC（事务的结束）命令 ;

当输入MULTI命令后，服务器返回OK表示事务开始成功，然后依次输入需要在本次事务中执行的所有命令，每次输入一个命令服务器并不会马上执行，而是返回”QUEUED”，这表示命令已经被服务器接受并且暂时保存起来，最后输入EXEC命令后，本次事务中的所有命令才会被依次执行，可以看到最后服务器一次性返回了两个OK，这里返回的结果与发送的命令是按顺序一一对应的，这说明这次事务中的命令全都执行成功了。

Redis的事务除了保证所有命令要不全部执行，要不全部不执行外，还能保证一个事务中的命令依次执行而不被其他命令插入。同时，redis的事务是不支持回滚操作的。

8.Redis数据和MySQL数据库的一致性如何实现

一、 延时双删策略

        在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。具体步骤是：

        1）先删除缓存

        2）再写数据库

        3）休眠500毫秒（根据具体的业务时间来定）

        4）再次删除缓存。

        那么，这个500毫秒怎么确定的，具体该休眠多久呢？

        需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

        当然，这种策略还要考虑 redis 和数据库主从同步的耗时。最后的写数据的休眠时间：则在读数据业务逻辑的耗时的基础上，加上几百ms即可。比如：休眠1秒。

二、设置缓存的过期时间

        从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存

        结合双删策略+缓存超时设置，这样最差的情况就是在超时时间内数据存在不一致，而且又增加了写请求的耗时。

三、如何写完数据库后，再次删除缓存成功？

        上述的方案有一个缺点，那就是操作完数据库后，由于种种原因删除缓存失败，这时，可能就会出现数据不一致的情况。这里，我们需要提供一个保障重试的方案。

1、方案一具体流程

        （1）更新数据库数据； 

        （2）缓存因为种种问题删除失败；

        （3）将需要删除的key发送至消息队列；

        （4）自己消费消息，获得需要删除的key；

        （5）继续重试删除操作，直到成功。

        然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。 

2、方案二具体流程

        （1）更新数据库数据；

        （2）数据库会将操作信息写入binlog日志当中；

        （3）订阅程序提取出所需要的数据以及key； 

        （4）另起一段非业务代码，获得该信息；

        （5）尝试删除缓存操作，发现删除失败； 

        （6）将这些信息发送至消息队列；

        （7）重新从消息队列中获得该数据，重试操作。

9.缓存击穿，缓存穿透，缓存雪崩的原因和解决方案(或者说使用缓存的过程中有没有遇到什么问题，怎么解决的）

1. 缓存穿透：

是指查询一个不存在的数据，由于缓存无法命中，将去查询数据库，但是数据库也无此记录，并且出于容错考虑，我们没有将这次查询的null写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案：空结果也进行缓存，可以设置一个空对象，但它的过期时间会很短，最长不超过五分钟。 或者用布隆过滤器也可以解决，Redisson框架中有布隆过滤器。

2. 缓存雪崩：

是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案：原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

3. 缓存击穿

是指对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：如果这个key在大量请求同时进来之前正好失效，那么所有对这个key的数据查询都落到DB，我们称为缓存击穿。

解决方案：在分布式的环境下，应使用分布式锁来解决，分布式锁的实现方案有多种，比如使用Redis的setnx、使用Zookeeper的临时顺序节点等来实现

10.哨兵模式是什么样的

如果Master异常，则会进行Master-Slave切换，将其中一Slae作为Master，将之前的Master作为Slave

下线：

①主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

②客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.

工作原理：

（1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 ；

（2）如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线；

（3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态；

（4）当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 ；

（5）在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

（6）当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 ；

（7）若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除；

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除；

11.Redis常见性能问题和解决方案

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...

这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

12.MySQL里有大量数据，如何保证Redis中的数据都是热点数据

Redis内存淘汰策略

redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

数据淘汰策略：

noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）

allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。

volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。

allkeys-random: 回收随机的键使得新添加的数据有空间存放。

volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。

volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。

13.Redis集群方案应该怎么做 都有哪些方案

（1）twemproxy，大概概念是，它类似于一个代理方式，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。使用方式简便(相对redis只需修改连接端口)，对旧项目扩展的首选。 问题：twemproxy自身单端口实例的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。

（2）codis，目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新hash节点。

（3）redis cluster3.0自带的集群，特点在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。

（4）在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key 进行hash计算，然后去对应的redis实例操作数据。 这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。

14.说说Redis哈希槽的概念

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

15.Redis有哪些适合的场景

（1）会话缓存（Session Cache）

最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

（2）全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。

此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

（3）队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。

如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。

（4）排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。

（5）发布/订阅

最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。

16.Redis在项目中的应用

Redis一般来说在项目中有几方面的应用

1. 作为缓存，将热点数据进行缓存，减少和数据库的交互，提高系统的效率

2. 作为分布式锁的解决方案，解决缓存击穿等问题

3. 作为消息队列，使用Redis的发布订阅功能进行消息的发布和订阅

具体的使用场景要结合项目去说，比如说项目中有哪些场景用到Redis来作为缓存，以及分布式锁等等。