应用场景

• 缓存
• 单机里用JVM锁锁,在集群中用分布式锁
• 无锁化
  • 原子操作是一种提供无锁并发访问控制的方法。
  • 多个操作写到一个Lua脚本中执行。

Redis 到底有多快

Redis 官方提供了一个测试脚本，可以供我们测试 Redis 的吞吐量：

• redis-benchmark -q -n 100000：测试常用命令的吞吐量。
• redis-benchmark -t set,lpush -n 100000 -q：测试 Redis 处理 set 和 lpush 命令的吞吐量。
• redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"：测试 Redis 处理 Lua 脚本等吞吐量。

Redis 为什么这么快

• Redis 是纯内存结构的，避免了磁盘 I/O 等耗时操作。
• Redis 命令处理的核心模块为单线程，减少了锁竞争，以及频繁创建线程和销毁线程的代价，减少了线程上下文切换的消耗。
• 采用了 I/O 多路复用机制，大大提升了并发效率。

redis线程模型

IO模型维度的特征

IO模型使用了多路复用器，在linux系统中使用的是EPOLL
类似netty的BOSS,WORKER使用一个EventLoopGroup(threads=1)
单线程的Reactor模型，每次循环取socket中的命令然后逐一操作，可以保证socket中的指令是按顺序的，不保证不同的socket也就是客户端的命令的顺序性。

数据架构模型

自身的内存存储数据，读写操作不涉及磁盘IO
redis除了提供了Value具备类型还为每种类型实现了一些操作命令
实现了计算向数据移动，而非数据向计算移动，这样在IO的成本上有一定的优势
且在数据结构类型上，丰富了一些统计类属性，读写操作中，写操作会O(1)负载度更新length类属性，使得读操作也是O(1)的

Redis是单线程还是多线程

Redis 从 4.0 版本开始就有了多线程的概念，虽然处理命令请求的核心模块确实是保证了单线程执行，然而在其它许多地方已经有了多线程，比如：在后台删除对象，通过 Redis 模块实现阻塞命令，生成 dump 文件，以及 6.0 版本中网络 I/O 实现了多线程等，但是无论什么版本,工作线程就是一个。

所谓的单线程，只是说 Redis 处理客户端的请求（即执行命令）时，是单线程去执行的，并不是说整个 Redis 都是单线程。

单线程满足了Redis的串行原子,只不过IO多线程后,把输入/输出放到更多的线程里去并行,多线程存在客户端被读取的顺序不能被保障，但在一个连接socket里是可以被保障的。

面向IO模型编程的时候,有内核的事。第一步从内核把数据搬运到程序里；第二步搬运回来的数据做计算（比如Netty）

Redis为什么使用单线程来执行请求

CPU 成为 Redis 瓶颈的情况并不常见，成为 Redis 瓶颈的通常是内存或网络带宽。例如，在一个普通的 Linux 系统上使用 命令，Redis 可以每秒完成 100 万个请求，所以如果我们的应用程序主要使用 O(N) 或 O(log(N)) 复杂度的命令，它几乎不会使用太多的 CPU。

既然 CPU 不会成为瓶颈，理所当然的就没必要去使用多线程来执行命令，同时多线程一定会比单线程快吗？答案是不一定。因为多线程也是有代价的，最直接的两个代价就是线程的创建和销毁（当然可以通过线程池来一定程度减少频繁的创建线程和销毁线程）以及线程的上下文切换。

在我们的日常系统中，主要可以区分为两种：CPU 密集型 和 IO 密集型：

1. CPU 密集型：这种系统就说明 CPU 的利用率很高，那么使用多线程反而会增加上下文切换而带来额外的开销，所以使用多线程效率可能会不升反降。

举个例子：假如你现在在干活，你一直不停的在做一件事，需要 1 分钟可以做完，但是你中途总是被人打断，需要花 1 秒钟时间步行到旁边去做另一件事，假如这件事也需要 1 分钟，那么你因为反复切换做两件事，每切换一次就要花 1 秒钟，最后做完这 2 件事的时间肯定大于 2 分钟（取决于中途切换的次数），但是如果中途不被打断，你做完一件事再去做另一件事，那么你最多只需要切换 1 次，也就是 2 分 1 秒就能做完。

2. IO 密集型：IO 操作也可以分为磁盘 IO 和网络 IO 等操作。大部分 IO 操作的特点是比较耗时且 CPU 利用率不高，所以 Redis 6.0 版本网络 IO 会改进为多线程。至于磁盘 IO，因为 Redis 中的数据都存储在内存（也可以持久化），所以并不会过多的涉及到磁盘操作。

举个例子：假如你现在给树苗浇水，你每浇完一次水之后就需要等别人给你加水之后你才能继续浇，那么假如这个等待过程需要 5 秒钟，也就是说你浇完一次水就可以休息 5 秒钟，而你切换去做另一件事来回只需要 2 秒，那么你完全可以先去做另一件事，做完之后再回来继续浇水，这样就可以充分利用你空闲的 5 秒钟时间，从而提升了效率。

使用多线程还会带来一个问题就是数据的安全性，所以多线程编程都会涉及到锁竞争，由此也会带来额外的开销。

IO 多路复用机制

I/O 指的是网络 I/O， 多路指的是多个 TCP 连接（如 Socket），复用指的是复用一个或多个线程。I/O 多路复用的核心原理就是不再由应用程序自己来监听连接，而是由服务器内核替应用程序监听。

在 Redis 中，其多路复用有多种实现，如：select，epoll，evport，kqueue 等。

我们用去餐厅吃饭的例子来解释一下 I/O 多路复用机制（点餐人相当于客户端，餐厅的厨房相当于服务器，厨师就是线程）。

• 阻塞 IO：张三去餐厅吃饭，点了一道菜，这时候他啥事也不干了，就是一直等，等到厨师炒好菜，他就把菜端走开始吃饭了。也就是在菜被炒好之前，张三被阻塞了，这就是 BIO（阻塞 IO），效率非常低下。
• 非阻塞 IO：张三去餐厅吃饭，点了一道菜，这时候张三他不会一直等，找了个位置坐下，刷刷抖音，打打电话，做点其它事，然后每隔一段时间就去厨房问一下自己的菜好了没有。这种就属于非阻塞 IO，这种方式虽然可以提高性能，但是如果有大量 IO 都来定期轮询，也会给服务器造成非常大的负担。
• 事件驱动机制：张三去餐厅吃饭，点了一道菜，这时候他找了个位置坐下来等，接下来厨房（服务器）有两种做法：
  • 厨房把菜做好了直接把菜端出去，但是端菜的人并不知道这道菜是谁的，于是就挨个询问顾客，这就是多路复用中的 select 模型，不过 select 模型最多只能监听 1024 个 socket（poll 模型解决了这个限制问题）。
  • 厨房把菜做好了直接把菜放在窗口上，大喊一声：“某某菜做好了，是谁的快过来拿。”这时候听到通知的顾客就会自己去拿，这就是多路复用中的 epoll 模型。

需要注意的是：在 IO 多路复用机制下，客户端可以阻塞也可以选择不阻塞（大部分场景下是阻塞 IO），这个要具体情况具体分析，但是在多路复用机制下，服务端就可以通过多线程（上面示例中可以多几个厨师同时炒菜）来提升并发效率。

Redis 中 I/O 多路复用的应用

Redis 服务器是一个事件驱动程序，服务器需要处理两类事件：文件事件和时间事件。

• 文件事件：Redis 服务器和客户端（或其它服务器）进行通信会产生相应的文件事件，然后服务器通过监听并处理这些事件来完成一系列的通信操作。
• 时间事件：Redis 内部的一些在给定时间之内需要进行的操作。

Redis 的文件事件处理器以单线程的方式运行，其内部使用了 I/O 多路复用程序来同时监听多个套接字（Socket）连接，提升了性能的同时又保持了内部单线程设计的简单性。下图就是文件事件处理器的示意图：

I/O 多路复用程序虽然会同时监听多个 Socket 连接，但是其会将监听的 Socket 都放到一个队列里面，然后通过这个队列有序的、同步的将每个 Socket 对应的事件传送给文件事件分派器，再由文件事件分派器分派给对应的事件处理器进行处理，只有当一个 Socket 所对应的事件被处理完毕之后，I/O 多路复用程序才会继续向文件事件分派器传送下一个 Socket 所对应的事件，这也可以验证上面的结论，处理客户端的命令请求是单线程的方式逐个处理，但是事件处理器内并不是只有一个线程。

Redis线程安全

• redis可以保障内部串行
• 业务上要自行保障顺序

Redis缓存穿透、击穿、雪崩

缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存击穿

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。
缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存雪崩

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

解决方案

• 使用互斥锁(mutex key)

  业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

  SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。在redis2.6.1之前版本未实现setnx的过期时间

• “提前”使用互斥锁(mutex key)：

  在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。

• “永远不过期”：

  这里的“永远不过期”包含两层意思：

  • 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
  • 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期

​ 从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

总结

• 穿透：缓存不存在，数据库不存在，高并发，少量key
• 击穿：缓存不存在，数据库存在，高并发，少量key
• 雪崩：缓存不存在，数据库存在，高并发，大量key

都可以使用限流的互斥锁，保障数据库的稳定

redis事务是怎么实现的

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。事务可以一次执行多个命令， 并且带有以下两个重要的保证：

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

EXEC 命令负责触发并执行事务中的所有命令：

如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中。

然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。

如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。

使用redis-check-aof程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

从 2.2 版本开始，Redis 还可以通过乐观锁（optimistic lock）实现 CAS （check-and-set）操作。

事务中的错误

使用事务时可能会遇上以下两种错误：

1. 事务在执行 EXEC 之前，入队的命令可能会出错。比如说，命令可能会产生语法错误（参数数量错误，参数名错误，等等），或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。
2. 命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。

对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。

不过，从 Redis 2.6.5 开始，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。

在 Redis 2.6.5 以前， Redis 只执行事务中那些入队成功的命令，而忽略那些入队失败的命令。 而新的处理方式则使得在流水线（pipeline）中包含事务变得简单，因为发送事务和读取事务的回复都只需要和服务器进行一次通讯。

至于那些在 EXEC 命令执行之后所产生的错误， 并没有对它们进行特别处理： 即使事务中有某个/某些命令在执行时产生了错误， 事务中的其他命令仍然会继续执行。

Redis不支持回滚

Redis 在事务失败时不进行回滚，而是继续执行余下的命令。

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

在通常情况下， 回滚并不能解决编程错误带来的问题。

举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2。又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

redis集群方案

• 主从复制集群
  • 主从复制集群，手动切换
  • 带有哨兵的HA的主从复制集群
• 分片集群
  • 客户端实现路由索引的分片集群
  • 使用中间件代理层的分片集群
  • redis自身实现的cluster分片集群

redis主从复制的原理

主从复制机制

当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave的更新，以便于将自身数据集的改变复制给 slave ， ：包括客户端的写入、key 的过期或被逐出等等。
当 master 和 slave 之间的连接断开之后，因为网络问题、或者是主从意识到连接超时， slave 重新连接上 master 并会尝试进行部分重同步：这意味着它会尝试只获取在断开连接期间内丢失的命令流。
当无法进行部分重同步时， slave 会请求进行全量重同步。这会涉及到一个更复杂的过程，例如 master需要创建所有数据的快照，将之发送给 slave ，之后在数据集更改时持续发送命令流到 slave 。

主从复制的关注点

Redis 使用异步复制，slave 和 master 之间异步地确认处理的数据量
一个 master 可以拥有多个 slave
slave 可以接受其他 slave 的连接。除了多个 slave 可以连接到同一个 master 之外， slave 之间也可以像层叠状的结构（cascading like structure）连接到其他 slave 。自 Redis 4.0 起，所有的 sub slave 将会从 master 收到完全一样的复制流。
Redis 复制在 master 侧是非阻塞的。这意味着 master 在一个或多个 slave 进行初次同步或者是部分重同步时，可以继续处理查询请求。
复制在 slave 侧大部分也是非阻塞的。当 slave 进行初次同步时，它可以使用旧数据集处理查询请求，假设你在 redis.conf 中配置了让 Redis 这样做的话。否则，你可以配置如果复制流断开， Redis slave会返回一个 error 给客户端。但是，在初次同步之后，旧数据集必须被删除，同时加载新的数据集。
slave 在这个短暂的时间窗口内（如果数据集很大，会持续较长时间），会阻塞到来的连接请求。自 Redis4.0 开始，可以配置 Redis 使删除旧数据集的操作在另一个不同的线程中进行，但是，加载新数据集的操作依然需要在主线程中进行并且会阻塞 slave 。
复制既可以被用在可伸缩性，以便只读查询可以有多个 slave 进行（例如 O(N) 复杂度的慢操作可以被下放到 slave ），或者仅用于数据安全。

可以使用复制来避免 master 将全部数据集写入磁盘造成的开销：一种典型的技术是配置你的 masterRedis.conf 以避免对磁盘进行持久化，然后连接一个 slave ，其配置为不定期保存或是启用 AOF。但是，这个设置必须小心处理，因为重新启动的 master 程序将从一个空数据集开始：如果一个 slave 试图与它同步，那么这个 slave 也会被清空。
任何时候数据安全性都是很重要的，所以如果 master 使用复制功能的同时未配置持久化，那么自动重启进程这项应该被禁用。

Redis 复制功能

每一个 Redis master 都有一个 replication ID ：这是一个较大的伪随机字符串，标记了一个给定的数据集。每个 master 也持有一个偏移量，master 将自己产生的复制流发送给 slave 时，发送多少个字节的数据，自身的偏移量就会增加多少，目的是当有新的操作修改自己的数据集时，它可以以此更新 slave的状态。复制偏移量即使在没有一个 slave 连接到 master 时，也会自增，所以基本上每一对给定的

Replication ID, offset

都会标识一个 master 数据集的确切版本。
当 slave 连接到 master 时，它们使用 PSYNC 命令来发送它们记录的旧的 master replication ID 和它们至今为止处理的偏移量。通过这种方式， master 能够仅发送 slave 所需的增量部分。但是如果 master的缓冲区中没有足够的命令积压缓冲记录，或者如果 slave 引用了不再知道的历史记录（replication
ID），则会转而进行一个全量重同步：在这种情况下， slave 会得到一个完整的数据集副本，从头开始。
下面是一个全量同步的工作细节：
master 开启一个后台保存进程，以便于生产一个 RDB 文件。同时它开始缓冲所有从客户端接收到的新的写入命令。当后台保存完成时， master 将数据集文件传输给 slave， slave将之保存在磁盘上，然后加载文件到内存。再然后 master 会发送所有缓冲的命令发给 slav e。这个过程以指令流的形式完成并且和 Redis 协议本身的格式相同。
你可以用 telnet 自己进行尝试。在服务器正在做一些工作的同时连接到 Redis 端口并发出 SYNC 命令。你将会看到一个批量传输，并且之后每一个 master 接收到的命令都将在 telnet 回话中被重新发出。事实上 SYNC 是一个旧协议，在新的 Redis 实例中已经不再被使用，但是其仍然向后兼容：但它不允许部分重同步，所以现在 PSYNC 被用来替代 SYNC。
之前说过，当主从之间的连接因为一些原因崩溃之后， slave 能够自动重连。如果 master 收到了多个slave 要求同步的请求，它会执行一个单独的后台保存，以便于为多个 slave 服务。

无需磁盘参与的复制

正常情况下，一个全量重同步要求在磁盘上创建一个 RDB 文件，然后将它从磁盘加载进内存，然后slave以此进行数据同步。
如果磁盘性能很低的话，这对 master 是一个压力很大的操作。Redis 2.8.18 是第一个支持无磁盘复制的版本。在此设置中，子进程直接发送 RDB 文件给 slave，无需使用磁盘作为中间储存介质。

Redis删除过期key策略

过期精度

在 Redis 2.4 及以前版本，过期期时间有0-1秒的误差。从 Redis 2.6 起，过期时间误差缩小到0-1毫秒。

过期和持久

• Keys的过期时间使用Unix时间戳存储(从Redis 2.6开始以毫秒为单位)。这意味着即使Redis实例不可用，时间也是一直在流逝的。
• 要想过期的工作处理好，计算机必须采用稳定的时间。 如果你将RDB文件在两台时钟不同步的电脑间同步，有趣的事会发生（所有的 keys装载时就会过期）。
• 即使正在运行的实例也会检查计算机的时钟，例如如果你设置了一个key的有效期是1000秒，然后设置你的计算机时间为未来2000秒，这时key会立即失效，而不是等1000秒之后。

淘汰策略

Redis keys过期有两种方式

被动式

程序或手动delete

主动式

当一些客户端尝试访问它时，key会被发现并主动的过期。
当然，这样是不够的，因为有些过期的keys，永远不会访问他们。 无论如何，这些keys应该过期，所以定时随机测试设置keys的过期时间。所有这些过期的keys将会从密钥空间删除。
具体就是Redis每秒10次做的事情：

1. 测试随机的20个keys进行相关过期检测。
2. 删除所有已经过期的keys。
3. 如果有多于25%的keys过期，重复步奏1

不断重复过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时刻，最多会清除25%的过期keys。

在复制AOF文件时如何处理过期

为了获得正确的行为而不牺牲一致性，当一个key过期， DEL 将会随着AOF文字一起合成到所有附加的slaves。在master实例中，这种方法是集中的，并且不存在一致性错误的机会。
然而，当slaves连接到master时，不会独立过期keys（会等到master执行DEL命令），他们任然会在数据集里面存在，所以当slave当选为master时淘汰keys会独立执行，然后成为master。

扩展

绝对时间点过期
相对时间点过期
时钟轮算法

回收策略

• noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）
• allkeys lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。
• volatile lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。
• allkeys random: 回收随机的键使得新添加的数据有空间存放。
• volatile random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。
• volatile ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。
• volatile lfu：从所有配置了过期时间的键中驱逐使用频率最少的键
• allkeys lfu：从所有键中驱逐使用频率最少的键

如果没有键满足回收的前提条件的话，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。

选择正确的回收策略是非常重要的，这取决于你的应用的访问模式，不过你可以在运行时进行相关的策略调整，并且监控缓存命中率和没命中的次数，通过RedisINFO命令输出以便调优。

一般的经验规则:

• 使用allkeys-lru策略：当你希望你的请求符合一个幂定律分布，也就是说，你希望部分的子集元素将比其它其它元素被访问的更多。如果你不确定选择什么，这是个很好的选择。.
• 使用allkeys-random：如果你是循环访问，所有的键被连续的扫描，或者你希望请求分布正常（所有元素被访问的概率都差不多）。
• 使用volatile-ttl：如果你想要通过创建缓存对象时设置TTL值，来决定哪些对象应该被过期。

allkeys-lru 和 volatile-random策略对于当你想要单一的实例实现缓存及持久化一些键时很有用。不过一般运行两个实例是解决这个问题的更好方法。

为了键设置过期时间也是需要消耗内存的，所以使用allkeys-lru这种策略更加高效，因为没有必要为键取设置过期时间当内存有压力时。

回收进程如何工作

• 一个客户端运行了新的命令，添加了新的数据。
• Redis检查内存使用情况，如果大于maxmemory的限制, 则根据设定好的策略进行回收。
• 一个新的命令被执行等。
• 不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下。

如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到一个新的键），不用多久内存限制就会被这个内存使用量超越。

Redis缓存预热

• 提前把数据塞入redis
• 开发逻辑上也要规避差集(没缓存的),会造成击穿,穿透,雪崩

数据库与缓存不一致问题

redis和mysql,只有只读的时候，肯定不存在数据不一致的问题。只有同时存在读写并且是并行的场景下会存在读写不一致。

缓存更新推荐使用删除而不是修改，因为逻辑比较简单。

先修改数据库，再删除缓存

需要考虑删除缓存失败的重试机制。

先删除缓存，再修改数据库

会存在线程T1删除了redis缓存，在更新数据库的时候由于网络延迟;线程T2进来先查询缓存，查询不到，会从mysql查询到旧数据并放入缓存。
此时线程T1再把数据库的数据修改了。数据库里的是新数据。导致redis和数据库的数据不一致。

解决：使用延时双删。线程T1增加一步2次删除缓存的操作。

即：删除缓存–>更新数据库–>再次删除缓存。

这样只会存在更新数据库和再次删除缓存之间的数据不一致，之后的数据都是一致的。

注意: 第2次删除要设置延迟时间，比如500ms（这个根据实际业务分析），防止线程2先从数据库查询到旧数据，然后线程T1第2次删除的时候，被线程2的旧数据给覆盖了。

不管是先操作数据库还是先操作缓存，都会存在数据不一致的问题。

因为redis和数据库之间的操作不是原子性的。要保证原子性只能上锁，但这会影响系统的吞吐量，违背的使用redis是提高系统的性能。

所以一般只保证最终一致性，而不是强一致性。AP和CP只能保证一种，这个需要取舍。

当然最终一致性也存在删除缓存失败的场景，这个可以利用MQ异步重试机制去删除。

Redis主从不一致

• Redis的确默认时弱一致性,异步的同步
• 锁不能用主从(单实例/分片集群/redlock)
  • 解决：redisson
• redis配置中配置同步因子(同步比例）,趋向于强一致性（违背redis的ap）
• wait（违背redis的ap）

Redis持久化原理

• 异步线程知识点
• 计算机组成原理
• fork
• copy on write
• 系统IO
• pagecache
• fsync

redis持久化方式

• RDB持久化
  • 能够在指定的时间间隔能对你的数据进行快照存储.
• AOF持久化
  • 记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
• 如果只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB和AOF持久化方式的不同

RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

AOF 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export）AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

4.X版本的整合策略

• 在AOF重写策略上做了优化
• 在重写AOF文件时，4.x版本以前是把内存数据集的操作指令落地，而新版本是把内存的数据集以rdb的形式落地
• 这样重写后的AOF依然追加的是日志，但是，在恢复的时候是先rdb再增量的日志，性能更优秀

Redis分布式锁命令

SETNX
格式：setnx key value 将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作,操作失败。
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
加锁：set key value nx ex 10s
释放锁：delete key

Redis如何做分布式锁

假设有两个服务A、B都希望获得锁，执行过程大致如下:

1. 服务A为了获得锁，向Redis发起如下命令: SET productId:lock 0xx9p03001 NX EX 30000 其中，”productId”由自己定义，可以是与本次业务有关的id，”0xx9p03001”是一串随机值，必须保证全局唯一，“NX”指的是当且仅当key(也就是”productId:lock”)在Redis中不存在时，返回执行成功，否则执行失败。”EX 30000”指的是在30秒后，key将被自动删除。执行命令后返回成功，表明服务成功的获得了锁。
2. 服务B为了获得锁，向Redis发起同样的命令: SET productId:lock 0000111 NX EX 30000。由于Redis内已经存在同名key，且并未过期，因此命令执行失败，服务B未能获得锁。服务B进入循环请求状态，比如每隔1秒钟(自行设置)向Redis发送请求，直到执行成功并获得锁。
3. 服务A的业务代码执行时长超过了30秒，导致key超时，因此Redis自动删除了key。此时服务B再次发送命令执行成功，假设本次请求中设置的value值为0000222。此时需要在服务A中对key进行续期。
4. 服务A执行完毕，为了释放锁，服务A会主动向Redis发起删除key的请求。注意: 在删除key之前，一定要判断服务A持有的value与Redis内存储的value是否一致。比如当前场景下，Redis中的锁早就不是服务A持有的那一把了，而是由服务2创建，如果贸然使用服务A持有的key来删除锁，则会误将服务2的锁释放掉。此外，由于删除锁时涉及到一系列判断逻辑，因此一般使用lua脚本，具体如下:

if redis.call("get", KEYS[1])==ARGV[1] then
    return redis.call("del", KEYS[1])
    else
return 0
end

Redis分布式锁死锁场景

• 加锁，没有释放锁。需要加释放锁的操作。比如delete key。
• 加锁后，程序还没有执行释放锁，程序挂了。需要用的key的过期机制。

（完）