Redis及缓存相关面试

最新推荐文章于 2024-05-06 09:54:26 发布

Aaron.JJJ

最新推荐文章于 2024-05-06 09:54:26 发布

阅读量155

点赞数 1

分类专栏：面试文章标签： redis 缓存

本文链接：https://blog.csdn.net/m0_46484214/article/details/107664943

版权

面试专栏收录该内容

9 篇文章 0 订阅

订阅专栏

写在前面：
先声明下，这个面试专题，主要是写给自己的，用来在挤公交的时候学习下，顺便做个分享。。。我就是个小菜鸡。

](Redis相关)

缓存

本地缓存是指程序级别的缓存组件，它的特点是本地缓存和应用程序会运行在同一个进程中，所以本地缓存的操作会非常快，因为在同一个进程内也意味着不会有网络上的延迟和开销。

本地缓存适用于单节点非集群的应用场景，它的优点是快，缺点是多程序无法共享缓存，比如分布式用户 Session 会话信息保存，由于每次用户访问的服务器可能是不同的，如果不能共享缓存，那么就意味着每次的请求操作都有可能被系统阻止，因为会话信息只保存在某一个服务器上，当请求没有被转发到这台存储了用户信息的服务器时，就会被认为是非登录的违规操作。
无法共享缓存可能会造成系统资源的浪费，这是因为每个系统都单独维护了一份属于自己的缓存，而同一份缓存有可能被多个系统单独进行存储，从而浪费了系统资源。

分布式缓存是指将应用系统和缓存组件进行分离的缓存机制，这样多个应用系统就可以共享一套缓存数据了，它的特点是共享缓存服务和可集群部署，为缓存系统提供了高可用的运行环境，以及缓存共享的程序运行机制。

本地缓存可以使用 EhCache 和 Google 的 Guava 来实现，而分布式缓存可以使用 Redis 或 Memcached 来实现。
由于 Redis 本身就是独立的缓存系统，因此可以作为第三方来提供共享的数据缓存，而 Redis 的分布式支持主从、哨兵和集群的模式，所以它就可以支持分布式的缓存，而 Memcached 的情况也是类似的。

EhCache 和 Guava 的使用及特点分析

EhCache 是目前比较流行的开源缓存框架，是用纯 Java 语言实现的简单、快速的 Cache 组件。EhCache 支持内存缓存和磁盘缓存，支持 LRU（Least Recently Used，最近很少使用）、LFU（Least Frequently Used，最近不常被使用）和 FIFO（First In First Out，先进先出）等多种淘汰算法，并且支持分布式的缓存系统。

LRU 和 LFU 的区别

LRU 算法有一个缺点，比如说很久没有使用的一个键值，如果最近被访问了一次，那么即使它是使用次数最少的缓存，它也不会被淘汰；而 LFU 算法解决了偶尔被访问一次之后，数据就不会被淘汰的问题，它是根据总访问次数来淘汰数据的，其核心思想是“如果数据过去被访问多次，那么将来它被访问次数也会比较多”。因此 LFU 可以理解为比 LRU 更加合理的淘汰算法。

EhCache 最初是独立的本地缓存框架组件，在后期的发展中（从 1.2 版）开始支持分布式缓存，分布式缓存主要支持 RMI、JGroups、EhCache Server 等方式。
EhCache 的特点是，它使用起来比较简单，并且本身的 jar 包不是不大，简单的配置之后就可以正常使用了。EhCache 的使用比较灵活，它支持多种缓存策略的配置，它同时支持内存和磁盘缓存两种方式，在 EhCache 1.2 之后也开始支持分布式缓存了。

Guava Cache 是 Google 开源的 Guava 里的一个子功能，它是一个内存型的本地缓存实现方案，提供了线程安全的缓存操作机制。
Guava Cache 的架构设计灵感来源于 ConcurrentHashMap，它使用了多个 segments 方式的细粒度锁，在保证线程安全的同时，支持了高并发的使用场景。Guava Cache 类似于 Map 集合的方式对键值对进行操作，只不过多了过期淘汰等处理逻辑。

自定义缓存的实现思路

首先需要定义一个存放缓存值的实体类，这个类里包含了缓存的相关信息，比如缓存的 key 和 value，缓存的存入时间、最后使用时间和命中次数（预留字段，用于支持 LFU 缓存淘汰），再使用 ConcurrentHashMap 保存缓存的 key 和 value 对象（缓存值的实体类），然后再新增一个缓存操作的工具类，用于添加和删除缓存，最后再缓存启动时，开启一个无限循环的线程用于检测并删除过期的缓存。

缓存的问题

缓存失效

导致缓存失效，特别是很多 key 一起失效的原因。
服务系统查数据，首先会查缓存，如果缓存数据不存在，就进一步查 DB，最后查到数据后回种到缓存并返回。缓存的性能比 DB 高 50~100 倍以上，所以我们希望数据查询尽可能命中缓存，这样系统负荷最小，性能最佳。缓存里的数据存储基本上都是以 key 为索引进行存储和获取的。业务访问时，如果大量的 key 同时过期，很多缓存数据访问都会 miss，进而穿透到 DB，DB 的压力就会明显上升，由于 DB 的性能较差，只在缓存的 1%~2% 以下，这样请求的慢查率会明显上升。这就是缓存失效的问题。
解决方案：对于批量 key 缓存失效的问题，原因既然是预置的固定过期时间，在设计缓存的过期时间时，使用公式：过期时间=baes 时间+随机时间。

缓存穿透

指的是对某个一定不存在的数据进行请求，该请求将会穿透缓存到达数据库。
解决方案：

对这些不存在的数据缓存一个空数据；
对这类请求进行过滤。

缓存穿透，则意味着有特殊访客在查询一个不存在的 key，导致每次查询都会穿透到 DB，如果这个特殊访客再控制一批肉鸡机器，持续访问你系统里不存在的 key，就会对 DB 产生很大的压力，从而影响正常服务。
场景：比如通过不存在的 UID 访问用户，通过不存在的车次 ID 查看购票信息。用户输入错误，偶尔几个这种请求问题不大，但如果是大量这种请求，就会对系统影响非常大。

解决方案：
第一种方案就是，查询这些不存在的数据时，第一次查 DB，虽然没查到结果返回 NULL，仍然记录这个 key 到缓存，只是这个 key 对应的 value 是一个特殊设置的值。
第二种方案是，构建一个 BloomFilter 缓存过滤器，记录全量数据，这样访问数据时，可以直接通过 BloomFilter 判断这个 key 是否存在，如果不存在直接返回即可，根本无需查缓存和 DB。

BloomFilter 的算法是，首先分配一块内存空间做 bit 数组，数组的 bit 位初始值全部设为 0，加入元素时，采用 k 个相互独立的 Hash 函数计算，然后将元素 Hash 映射的 K 个位置全部设置为 1。检测 key 时，仍然用这 k 个 Hash 函数计算出 k 个位置，如果位置全部为 1，则表明 key 存在，否则不存在。

缓存雪崩

指的是由于数据没有被加载到缓存中，或者缓存数据在同一时间大面积失效（过期），又或者缓存服务器宕机，导致大量的请求都到达数据库。
在有缓存的系统中，系统非常依赖于缓存，缓存分担了很大一部分的数据请求。当发生缓存雪崩时，数据库无法处理这么大的请求，导致数据库崩溃。

解决方案：

为了防止缓存在同一时间大面积过期导致的缓存雪崩，可以通过观察用户行为，合理设置缓存过>期时间来实现；
为了防止缓存服务器宕机出现的缓存雪崩，可以使用分布式缓存，分布式缓存中每一个节点只缓存部分的数据，当某个节点宕机时可以保证其它节点的缓存仍然可用。
也可以进行缓存预热，避免在系统刚启动不久由于还未将大量数据进行缓存而导致缓存雪崩。

缓存雪崩是指部分缓存节点不可用，导致整个缓存体系甚至甚至服务系统不可用的情况。缓存雪崩按照缓存是否 rehash（即是否漂移）分两种情况：

缓存不支持 rehash 导致的系统雪崩不可用
缓存支持 rehash 导致的缓存雪崩不可用

第一种情况比较容易理解，缓存节点不支持 rehash，较多缓存节点不可用时，大量 Cache 访问会失败，根据缓存读写模型，这些请求会进一步访问 DB，而且 DB 可承载的访问量要远比缓存小的多，请求量过大，就很容易造成 DB 过载，大量慢查询，最终阻塞甚至 Crash，从而导致服务异常。

第二种情况是因为缓存分布设计时，很多同学会选择一致性 Hash 分布方式，同时在部分节点异常时，采用 rehash 策略，即把异常节点请求平均分散到其他缓存节点。在一般情况下，一致性 Hash 分布+rehash 策略可以很好得运行，但在较大的流量洪峰到临之时，如果大流量 key 比较集中，正好在某 1～2 个缓存节点，很容易将这些缓存节点的内存、网卡过载，缓存节点异常 Crash，然后这些异常节点下线，这些大流量 key 请求又被 rehash 到其他缓存节点，进而导致其他缓存节点也被过载 Crash，缓存异常持续扩散，最终导致整个缓存体系异常，无法对外提供服务。

解决方案：

方案一，对业务 DB 的访问增加读写开关，当发现 DB 请求变慢、阻塞，慢请求超过阀值时，就会关闭读开关，部分或所有读 DB 的请求进行 failfast 立即返回，待 DB 恢复后再打开读开关，如下图。
方案二，对缓存增加多个副本，缓存异常或请求 miss 后，再读取其他缓存副本，而且多个缓存副本尽量部署在不同机架，从而确保在任何情况下，缓存系统都会正常对外提供服务。
方案三，对缓存体系进行实时监控，当请求访问的慢速比超过阀值时，及时报警，通过机器替换、服务替换进行及时恢复；也可以通过各种自动故障转移策略，自动关闭异常接口、停止边缘服务、停止部分非核心功能措施，确保在极端场景下，核心功能的正常运行。

数据不一致

导致数据不一致的场景也不少。如下图所示，在缓存机器的带宽被打满，或者机房网络出现波动时，缓存更新失败，新数据没有写入缓存，就会导致缓存和 DB 的数据不一致。缓存 rehash 时，某个缓存机器反复异常，多次上下线，更新请求多次 rehash。这样，一份数据存在多个节点，且每次 rehash 只更新某个节点，导致一些缓存节点产生脏数据。

解决方案:

第一个方案，cache 更新失败后，可以进行重试，如果重试失败，则将失败的 key 写入队列机服务，待缓存访问恢复后，将这些 key 从缓存删除。这些 key 在再次被查询时，重新从 DB 加载，从而保证数据的一致性。
第二个方案，缓存时间适当调短，让缓存数据及早过期后，然后从 DB 重新加载，确保数据的最终一致性。
第三个方案，不采用 rehash 漂移策略，而采用缓存分层策略，尽量避免脏数据产生。

数据并发竞争

数据并发竞争，主要是由于多个进程/线程中，有大量并发请求获取相同的数据，而这个数据 key 因为正好过期、被剔除等各种原因在缓存中不存在，这些进程/线程之间没有任何协调，然后一起并发查询 DB，请求那个相同的 key，最终导致 DB 压力大增。

解决方案

方案一是使用全局锁。如下图所示，即当缓存请求 miss 后，先尝试加全局锁，只有加全局锁成功的线程，才可以到 DB 去加载数据。其他进程/线程在读取缓存数据 miss 时，如果发现这个 key 有全局锁，就进行等待，待之前的线程将数据从 DB 回种到缓存后，再从缓存获取。
方案二是，对缓存数据保持多个备份，即便其中一个备份中的数据过期或被剔除了，还可以访问其他备份，从而减少数据并发竞争的情况。

HotKey

在突发事件发生时，大量用户同时去访问这个突发热点信息，访问这个 Hot key，这个突发热点信息所在的缓存节点就很容易出现过载和卡顿现象，甚至会被 Crash。

解决：
解决方案
要解决这种极热 key 的问题，首先要找出这些 Hot key 来。找到热 key 后，就有很多解决办法了。

首先可以将这些热 key 进行分散处理，比如一个热 key 名字叫 hotkey，可以被分散为 hotkey#1、hotkey#2、hotkey#3，……hotkey#n，这 n 个 key 分散存在多个缓存节点，然后 client 端请求时，随机访问其中某个后缀的 hotkey，这样就可以把热 key 的请求打散，避免一个缓存节点过载。
其次，也可以 key 的名字不变，对缓存提前进行多副本+多级结合的缓存架构设计。
再次，如果热 key 较多，还可以通过监控体系对缓存的 SLA 实时监控，通过快速扩容来减少热 key 的冲击。
最后，业务端还可以使用本地缓存，将这些热 key 记录在本地缓存，来减少对远程缓存的冲击。

BigKey

如果这些大 key 占总体数据的比例很小，存 Mc，对应的 slab 较少，导致很容易被频繁剔除，DB 反复加载，从而导致查询较慢。如果业务中这种大 key 很多，而这种 key 被大量访问，缓存组件的网卡、带宽很容易被打满，也会导致较多的大 key 慢查询。另外，如果大 key 缓存的字段较多，每个字段的变更都会引发对这个缓存数据的变更，同时这些 key 也会被频繁地读取，读写相互影响，也会导致慢查现象。最后，大 key 一旦被缓存淘汰，DB 加载可能需要花费很多时间，这也会导致大 key 查询慢的问题。
大 key 的业务场景也比较常见。比如互联网系统中需要保存用户最新 1万个粉丝的业务，比如一个用户个人信息缓存，包括基本资料、关系图谱计数、发 feed 统计等。

解决:

如果数据存在 Redis 中，比如业务数据存 set 格式，大 key 对应的 set 结构有几千几万个元素，这种写入 Redis 时会消耗很长的时间，导致 Redis 卡顿。此时，可以扩展新的数据结构，同时让 client 在这些大 key 写缓存之前，进行序列化构建，然后通过 restore 一次性写入。
第三种方案是，将大 key 分拆为多个 key，尽量减少大 key 的存在。同时由于大 key 一旦穿透到 DB，加载耗时很大，所以可以对这些大 key 进行特殊照顾，比如设置较长的过期时间，比如缓存内部在淘汰 key 时，同等条件下，尽量不淘汰这些大 key。

Redis

过期策略

定时删除是指在设置键值的过期时间时，创建一个定时事件，当到达过期时间后，事件处理器会执行删除过期键的操作。它的优点是可以及时的释放内存空间，缺点是需要开启多个延迟执行事件来处理清除任务，这样就会造成大量任务事件堆积，占用了很多系统资源。
惰性删除不会主动删除过期键，而是在每次请求时才会判断此值是否过期，如果过期则删除键值，否则就返回 null。它的优点是只会占用少量的系统资源，缺点是清除不够及时，会造成一定的空间浪费。
定期删除是指每隔一段时间检查一次数据库，随机删除一些过期键值。

Redis 使用的是定期删除和惰性删除这两种策略。
惰性删除是指 Redis 服务器不主动删除过期的键值，而是当访问键值时，再检查当前的键值是否过期，如果过期则执行删除并返回 null 给客户端；如果没过期则正常返回值信息给客户端。

它的优点是不会浪费太多的系统资源，只是在每次访问时才检查键值是否过期。缺点是删除过期键不及时，造成了一定的空间浪费。

定期删除是指 Redis 服务器每隔一段时间会检查一下数据库，看看是否有过期键可以被清除。

默认情况下 Redis 定期检查的频率是每秒扫描 10 次，用于定期清除过期键。当然此值还可以通过配置文件进行设置，在 redis.conf 中修改配置“hz”即可，默认的值为“hz 10”。

淘汰策略

Redis 具体有 6 种淘汰策略：

策略	描述
volatile-lru	从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
volatile-ttl	从已设置过期时间的数据集中挑选将要过期的数据淘汰
volatile-random	从已设置过期时间的数据集中任意选择数据淘汰
allkeys-lru	从所有数据集中挑选最近最少使用的数据淘汰
allkeys-random	从所有数据集中任意选择数据进行淘汰
noeviction	禁止驱逐数据

volatile-lfu: 淘汰所有设置了过期时间的键值中最少使用的键值；
allkeys-lfu: 淘汰整个键值中最少使用的键值。

内存淘汰算法

内存淘汰算法主要包含两种：LRU 淘汰算法和 LFU 淘汰算法。

LRU（ Least Recently Used，最近最少使用）淘汰算法：是一种常用的页面置换算法，也就是说最久没有使用的缓存将会被淘汰。
LRU 是基于链表结构实现的，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要进行内存淘汰时，只需要删除链表尾部的元素即可。

Redis 使用的是一种近似 LRU 算法，目的是为了更好的节约内存，它的实现方式是给现有的数据结构添加一个额外的字段，用于记录此键值的最后一次访问时间。Redis 内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值 (此值可配置) ，然后淘汰最久没有使用的数据。

LFU（Least Frequently Used，最不常用的）淘汰算法：最不常用的算法是根据总访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。
LFU 相对来说比 LRU 更“智能”，因为它解决了使用频率很低的缓存，只是最近被访问了一次就不会被删除的问题。如果是使用 LRU 类似这种情况数据是不会被删除的，而使用 LFU 的话，这个数据就会被删除。

跳跃表（ZSET）

是有序集合的底层实现之一。

跳跃表是基于多指针有序链表实现的，可以看成多个有序链表。
在查找时，从上层指针开始查找，找到对应的区间之后再到下一层去查找。

与红黑树等平衡树相比，跳跃表具有以下优点：

插入速度非常快速，因为不需要进行旋转等操作来维护平衡性；
更容易实现；
支持无锁操作。

分布式锁实现

在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。

可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。

持久化

Redis 是内存型数据库，为了保证数据在断电后不会丢失，需要将内存中的数据持久化到硬盘上。

步骤：

客户端向服务端发送写操作（此时数据在客户端的内存中）
数据库服务端接收到写请求的数据（数据在服务端的内存中）
服务端调用write这个系统调用，将数据往磁盘上写（数据写在内存的缓冲区中）
操作系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中）
磁盘控制器将数据写到磁盘的物理介质中（真正落到磁盘上）

RDB 持久化（默认）

操作：在conf文件中修改

save 900 1
在一定间隔（900s）时间中，检测到至少key（1个）变化，然后持久化数据。

RDB：将数据库快照以二进制的方式保存到磁盘中。

SAVE 阻塞式持久化

执行命令时Redis主进程把内存数据写入到RDB文件中直到创建完毕，期间Redis不能处理任

何命令。

BGSAVE 非阻塞式持久化

创建一个子进程把内存中数据写入RDB文件里同时主进程处理命令请求。

1). Redis使用fork函数创建子进程；

2). 父进程继续接收并处理命令请求，子进程将内存数据写入临时文件;

3).子进程写入所有数据后会用临时文件替换旧RDB文件；

rdb的劣势：快照是一次全量备份，存储的是内存数据的的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个紫禁城专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反映出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

AOF 持久化

操作:在conf文件中修改

appendonly no ---->appendonly yes

以协议文本方式，将所有对数据库进行过写入的命令和参数记录到 AOF 文件，从而记录数据库状
态

appendfsync选项 (3个)

always
服务器每执行一个事件就把AOF缓冲区的内容强制性的写入硬盘上的AOF文件里，保证了数据持久化的完整性，效率是最慢的但最安全的；
everysec
每隔一秒进行一次文件同步把AOF缓存数据写入AOF文件里
兼顾了效率和完整性，极端情况服务器宕机只会丢失一秒内对Redis数据库的写操作
no
默认系统的缓存区写入磁盘的机制，不做程序强制
数据安全性和完整性差一些

缺点：

对于同一份数据来说，AOF日志文件通常rdb数据快照文件大
写QPS会比RDB支持的写QPS低。

对比

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据决策决定
轻重	重	轻

重写机制

存储命令的过程中增长很快，为了压缩AOF的持久化文件，所以提供重写机制。

触发条件
1). 没有 BGSAVE 命令在进行防止于RDB的冲突
2). 没有 BGREWRITEAOF 在进行防止和手动AOF冲突
3). 当前 AOF 文件大小至少大于设定值基本要求太小没意义
4).当前AOF 文件大小和最后一次 AOF 重写后的大小之间的比率 >= 指定的增长百分比

数据恢复优先级

1). 如果只配置 AOF ，重启时加载 AOF 文件恢复数据；
2).如果同时配置了 RDB 和 AOF ，启动只加载 AOF 文件恢复数据；
3).如果只配置 RDB，启动将加载 dump 文件恢复数据

4.0版本混合持久化

一个同时包含 RDB 数据和 AOF 数据的 AOF 文件
RDB 数据位于 AOF 文件的开头，储存服务器开始执行重写操作时的数据库状态
重写操作执行之后执行的 Redis 命令，则会继续以 AOF 格式追加到 AOF 文件的
末尾

主从复制

redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。
主从复制实现了读写分离

过程：
1：当一个从数据库启动时，会向主数据库发送sync命令，
2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来
3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。
4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

Redis的哨兵(sentinel)

系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

Redis做分布式锁

redis单实例中,通过setnx来实现

多节点redis实现的分布式锁算法(RedLock):有效防止单点故障

假设有5个完全独立的redis主服务器
1.获取当前时间戳
2.client尝试按照顺序使用相同的key,value获取所有redis服务的锁，在获取锁的过程中的获取时间比锁过期时间短很多，这是为了不要过长时间等待已经关闭的redis服务。并且试着获取下一个redis实例。
比如：TTL为5s,设置获取锁最多用1s，所以如果一秒内无法获取锁，就放弃获取这个锁，从而尝试获取下个锁
3.client通过获取所有能获取的锁后的时间减去第一步的时间，这个时间差要小于TTL时间并且至少有3个redis实例成功获取锁，才算真正的获取锁成功
4.如果成功获取锁，则锁的真正有效时间是 TTL减去第三步的时间差的时间；比如：TTL 是5s,获取所有锁用了2s,则真正锁有效时间为3s(其实应该再减去时钟漂移);
5.如果客户端由于某些原因获取锁失败，便会开始解锁所有redis实例；因为可能已经获取了小于3个锁，必须释放，否则影响其他client获取锁

算法示意图如下：

Redis 的 SETNX 指令

使用 SETNX（set if not exist）指令插入一个键值对，如果 Key 已经存在，那么会返回 False，否则插入成功并返回 True。

SETNX 指令和数据库的唯一索引类似，保证了只存在一个 Key 的键值对，那么可以用一个 Key 的键值对是否存在来判断是否存于锁定状态。

EXPIRE 指令可以为一个键值对设置一个过期时间，从而避免了数据库唯一索引实现方式中释放锁失败的问题。

Redis 的 RedLock 算法

使用了多个 Redis 实例来实现分布式锁，这是为了保证在发生单点故障时仍然可用。

尝试从 N 个互相独立 Redis 实例获取锁；
计算获取锁消耗的时间，只有时间小于锁的过期时间，并且从大多数（N / 2 + 1）实例上获取了锁，才认为获取锁成功；
如果获取锁失败，就到每个实例上释放锁。

LRU

以下是基于双向链表 + HashMap 的 LRU 算法实现，对算法的解释如下：

访问某个节点时，将其从原来的位置删除，并重新插入到链表头部。这样就能保证链表尾部存储的就是最近最久未使用的节点，当节点数量大于缓存最大空间时就淘汰链表尾部的节点。
为了使删除操作时间复杂度为 O(1)，就不能采用遍历的方式找到某个节点。HashMap 存储着 Key 到节点的映射，通过 Key 就能以 O(1) 的时间得到节点，然后再以 O(1) 的时间将其从双向队列中删除。

public class LRU<K, V> implements Iterable<K> {

    private Node head;
    private Node tail;
    private HashMap<K, Node> map;
    private int maxSize;

    private class Node {

        Node pre;
        Node next;
        K k;
        V v;

        public Node(K k, V v) {
            this.k = k;
            this.v = v;
        }
    }


    public LRU(int maxSize) {

        this.maxSize = maxSize;
        this.map = new HashMap<>(maxSize * 4 / 3);

        head = new Node(null, null);
        tail = new Node(null, null);

        head.next = tail;
        tail.pre = head;
    }


    public V get(K key) {

        if (!map.containsKey(key)) {
            return null;
        }

        Node node = map.get(key);
        unlink(node);
        appendHead(node);

        return node.v;
    }


    public void put(K key, V value) {

        if (map.containsKey(key)) {
            Node node = map.get(key);
            unlink(node);
        }

        Node node = new Node(key, value);
        map.put(key, node);
        appendHead(node);

        if (map.size() > maxSize) {
            Node toRemove = removeTail();
            map.remove(toRemove.k);
        }
    }


    private void unlink(Node node) {

        Node pre = node.pre;
        Node next = node.next;

        pre.next = next;
        next.pre = pre;

        node.pre = null;
        node.next = null;
    }


    private void appendHead(Node node) {
        Node next = head.next;
        node.next = next;
        next.pre = node;
        node.pre = head;
        head.next = node;
    }


    private Node removeTail() {

        Node node = tail.pre;

        Node pre = node.pre;
        tail.pre = pre;
        pre.next = tail;

        node.pre = null;
        node.next = null;

        return node;
    }


    @Override
    public Iterator<K> iterator() {

        return new Iterator<K>() {
            private Node cur = head.next;

            @Override
            public boolean hasNext() {
                return cur != tail;
            }

            @Override
            public K next() {
                Node node = cur;
                cur = cur.next;
                return node.k;
            }
        };
    }
}

Aaron.JJJ

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis及缓存相关面试

if (!map.containsKey(key)) { return null; } Node node = map.get(key); unlink(node); appendHead(node); return node.v;}public void put(K key, V value) { if (map.containsKey(key)) { Node node = map.get(key);...
复制链接

扫一扫