- allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）.
- allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
- no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使
用吧！
###8.redis 持久化机制（怎么保证 redis 挂掉之后再重启数据可以进行恢复）
很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机
器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置。
Redis不同于Memcached的很重一点就是，Redis支持持久化，而且支持两种不同的持久化操作。Redis的一种持久 化
方式叫快照（ snapshotting ， RDB ） , 另一种方式是只追加文件（ append-only fi le,AOF ）.这两种方法各有千 秋，下
面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。
快照（snapshotting）持久化（RDB）
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备
份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性 能），
还可以将快照留在原地以便重启服务器的时候使用。
快照持久化是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：
###AOF（append-only file）持久化
与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启
AOF（append only file）方式的持久化，可以通过appendonly参数开启：
开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保
存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。
在Redis的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：
为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项 ，让Redis每秒同步一次AOF文件，Redis性能几
乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操 作
的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
Redis 4.0 对于持久化机制的优化
Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 开启）。
如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB
和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是
AOF 格式，可读性较差。
补充内容：AOF 重写
AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。
AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任伺读 入、
分析或者写入操作。
在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件
期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容
追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的
AOF文件，以此来完成AOF文件重写操作。
##9.redis 事务
Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后
一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令 请
求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性
（Atomicity)、一致性(Consistency)和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也
具有持久性（Durability）。
##10.Redis 常见异常及解决方案
缓存使用过程当中，我们经常遇到的一些问题总结有四点：
#####10.1 缓存穿透
一般访问缓存的流程，如果缓存中存在查询的商品数据，那么直接返回。 如果缓存中不存在商品
数据， 就要访问数据库。
由于不恰当的业务功能实现，或者外部恶意攻击不断地请求某些不存在的数据内存，由于缓存中没
有保存该数据，导致所有的请求都会落到数据库上，对数据库可能带来一定的压力，甚至崩溃。
解决方案：
针对缓存穿透的情况， 简单的对策就是将不存在的数据访问结果， 也存储到缓存中，避免缓存访
问的穿透。最终不存在商品数据的访问结果也缓存下来。有效的避免缓存穿透的风险。
######10.2 缓存雪崩
当缓存重启或者大量的缓存在某一时间段失效，这样就导致大批流量直接访问数据库，对 DB 造
成压力， 从而引起 DB 故障，系统崩溃。
举例来说， 我们在准备一项抢购的促销运营活动，活动期间将带来大量的商品信息、库存等相关
信息的查询。 为了避免商品数据库的压力，将商品数据放入缓存中存储。 不巧的是，抢购活动期
间，大量的热门商品缓存同时失效过期了，导致很大的查询流量落到了数据库之上。对于数据库来
说造成很大的压力。
解决方案：
- 将商品根据品类热度分类， 购买比较多的类目商品缓存周期长一些， 购买相对冷门的类目
商品，缓存周期短一些； - 在设置商品具体的缓存生效时间的时候， 加上一个随机的区间因子， 比如说 5~10 分钟
之间来随意选择失效时间； - 提前预估 DB 能力， 如果缓存挂掉，数据库仍可以在一定程度上抗住流量的压力
这三个策略能够有效的避免短时间内，大批量的缓存失效的问题。
#####10.3 缓存预热
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的
时候，先查询数据库，然后再将数据缓存的问题。用户直接查询事先被预热的缓存数据。如图所示：
如果不进行预热， 那么 Redis 初识状态数据为空，系统上线初期，对于高并发的流量，都会访
问到数据库中， 对数据库造成流量的压力。
解决方案： - 数据量不大的时候，工程启动的时候进行加载缓存动作；
- 数据量大的时候，设置一个定时任务脚本，进行缓存的刷新；
- 数据量太大的时候，优先保证热点数据进行提前加载到缓存。
#####10.4 缓存降级
降级的情况，就是缓存失效或者缓存服务挂掉的情况下，我们也不去访问数据库。我们直接访问内
存部分数据缓存或者直接返回默认数据。
举例来说：
对于应用的首页，一般是访问量非常大的地方，首页里面往往包含了部分推荐商品的展示信息。
这些推荐商品都会放到缓存中进行存储，同时我们为了避免缓存的异常情况，对热点商品数据也
存储到了内存中。同时内存中还保留了一些默认的商品信息。如下图所示：
降级一般是有损的操作，所以尽量减少降级对于业务的影响程度。
##11.分布式环境下常见的应用场景
#####11.1 分布式锁
当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的操作或者访问。 与之对应有线
程锁，进程锁。
分布式锁可以避免不同进程重复相同的工作，减少资源浪费。 同时分布式锁可以避免破坏数据正
确性的发生， 例如多个进程对同一个订单操作，可能导致订单状态错误覆盖。应用场景如下。
#####11.1.1 定时任务重复执行
随着业务的发展，业务系统势必发展为集群分布式模式。如果我们需要一个定时任务来进行订单状
态的统计。比如每 15 分钟统计一下所有未支付的订单数量。那么我们启动定时任务的时候，肯
定不能同一时刻多个业务后台服务都去执行定时任务， 这样就会带来重复计算以及业务逻辑混乱
的问题。
这时候，就需要使用分布式锁，进行资源的锁定。那么在执行定时任务的函数中，首先进行分布式
锁的获取，如果可以获取的到，那么这台机器就执行正常的业务数据统计逻辑计算。如果获取不到
则证明目前已有其他的服务进程执行这个定时任务，就不用自己操作执行了，只需要返回就行了。
如下图所示：
#####11.1.2 避免用户重复下单
分布式实现方式有很多种：
- 数据库乐观锁方式
- 基于 Redis 的分布式锁
- 基于 ZK 的分布式锁
咱们这篇文章主要是讲 Redis，那么我们重点介绍基于 Redis 如何实现分布式锁。
分布式锁实现要保证几个基本点。 - 互斥性：任意时刻，只有一个资源能够获取到锁。
- 容灾性：能够在未成功释放锁的的情况下，一定时限内能够恢复锁的正常功能。
- 统一性：加锁和解锁保证同一资源来进行操作。
加锁代码演示：
解锁代码演示：
##11.2 分布式自增 ID
应用场景
随着用户以及交易量的增加， 我们可能会针对用户数据，商品数据，以及订单数据进行分库分表
的操作。这时候由于进行了分库分表的行为，所以 MySQL 自增 ID 的形式来唯一表示一行数据
的方案不可行了。 因此需要一个分布式 ID 生成器，来提供唯一 ID 的信息。
实现方式
通常对于分布式自增 ID 的实现方式有下面几种： - 利用数据库自增 ID 的属性
- 通过 UUID 来实现唯一 ID 生成
- Twitter 的 SnowFlake 算法
- 利用 Redis 生成唯一 ID
在这里我们自然是说 Redis 来实现唯一 ID 的形式了。使用 Redis 的 INCR 命令来实现唯一
ID。
Redis 是单进程单线程架构，不会因为多个取号方的 INCR 命令导致取号重复。因此，基于 Redis
的 INCR 命令实现序列号的生成基本能满足全局唯一与单调递增的特性。
代码相对简单， 不做详细的展示了。
##12.Redis 集群模式
作为缓存数据库，肯定要考虑缓存服务稳定性相关的保障机制。
持久化机制就是一种保障方式。持久化机制保证了 Redis 服务器重启的情况下也不会损失（或少
量损失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。
随着 Redis 使用场景越来越多，技术发展越来越完善，在 Redis 整体服务上的容错、扩容、稳
定各个方面都需要不断优化。 因此在 Redis 的集群模式上也有不同的搭建方式来应对各种需求。
总结来说，Redis 集群模式有三种：
主从模式
哨兵模式
Cluster 集群模式
####12.1 主从模式
为了 Redis 服务避免单点故障，通常的做法是将 Redis 数据复制多个副本以部署在不同的服务
器上。这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此，Redis 提供
了复制（ replication ）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步
到其他数据库上。
Redis 服务器分为两类：一类是主数据库（Master），另一类是从数据库（Slave）。
主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。
从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，
而一个从数据库只能拥有一个主数据库。
如图所示：
优点 - 一个主，可以有多个从，并以非阻塞的方式完成数据同步；
- 从服务器提供读服务，分散主服务的压力，实现读写分离；
- 从服务器之前可以彼此连接和同步请求，减少主服务同步压力。
缺点 - 不具备容错和恢复功能，主服务存在单点风险；
- Redis 的主从复制采用全量复制，需要服务器有足够的空余内存；
- 主从模式较难支持在线扩容。
###12.2 哨兵模式
Redis 提供的 sentinel（哨兵）机制，通过 sentinel 模式启动redis后，自动监控 Master/Slave
的运行状态，基本原理是：心跳机制 + 投票裁决。
简单来说，哨兵的作用就是监控 Redis 系统的运行状况。它的功能包括以下两个： - 监控主数据库和从数据库是否正常运行；
- 主数据库出现故障时自动将从数据库转换为主数据库。
哨兵模式主要有下面几个内容：
监控（ Monitoring ）：Sentinel 会定期检查主从服务器是否处于正常工作状态。
提醒（ Notification ）：当被监控的某个 Redis 服务器出现异常时，Sentinel 可以通过
API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel 会开
始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，
并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务
器时，集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效
服务器。
Redis Sentinel 是一个分布式系统，你可以在一个架构中运行多个 Sentinel 进程（ progress ）。
优点 - 哨兵模式主从可以切换，具备基本的故障转移能力；
- 哨兵模式具备主从模式的所有优点。
缺点 - 哨兵模式也很难支持在线扩容操作；
- 集群的配置信息管理比较复杂
###12.3 Cluster 集群模式
Redis Cluster 是一种服务器 Sharding 技术，3.0 版本开始正式提供。采用无中心结构，每个节
点保存数据和整个集群状态,每个节点都和其他所有节点连接。如图所示：
Cluster 集群结构特点： - Redis Cluster 所有的物理节点都映射到 [ 0-16383 ] slot 上（不一定均匀分布），Cluster
负责维护节点、桶、值之间的关系； - 在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384 的值，从之前
划分的 16384 个桶中选择一个； - 所有的 Redis 节点彼此互联（PING-PONG 机制），内部使用二进制协议优化传输效率；
- 超过半数的节点检测到某个节点失效时则判定该节点失效；
- 使用端与 Redis 节点链接,不需要中间 proxy 层，直接可以操作，使用端不需要连接集群
所有节点，连接集群中任何一个可用节点即可。
优点 - 无中心架构，节点间数据共享，可动态调整数据分布；
- 节点可动态添加删除，扩展性比较灵活；
一线互联网大厂Java核心面试题库
正逢面试跳槽季，给大家整理了大厂问到的一些面试真题，由于文章长度限制，只给大家展示了部分题目，更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传，感兴趣的朋友可以看看支持一波！
外链图片转存中…(img-GzU7ioJn-1631094021108)]
正逢面试跳槽季，给大家整理了大厂问到的一些面试真题，由于文章长度限制，只给大家展示了部分题目，更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传，感兴趣的朋友可以看看支持一波！
725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
