Redis知识点整理

一、Redis基础

1、基础数据结构

• 字符串（String）：存储一个字符串值。
• 哈希（Hash）：存储字段和与其关联的值的映射。
• 列表（List）：一个包含字符串元素的有序列表。
• 集合（Set）：一个不重复且无序的字符串集合。
• 有序集合（Sorted Set）：一个与每个成员相关联的分数的有序集合。

2、基础操作

2.1 String

set name "张三"
get name // return "张三"

2.2 List

lpush mylist "1" // 左插入
rpush mylist "2" 
lrange mylist 0 -1

2.3 Hash

HMSET user:001 username antirez password P1pp0 age 34 // 插入三组hash数据
HSET user:001 password 12345 // 更改其中一个值
HGETALL user:001 // return "username" "antirez" "password" "12345 " "age" "34"

2.4 Set

sadd myset "one" 
sadd myset "two"
smembers myset  // 返回所有元素
sismember myset "one" // 是否存在 1 --> 存在  0 --> 不存在
sunion myset yourset // 对两个集合求并集

2.5 Sorted Set

zadd myzset 1 baidu.com // 给集合添加一个序号为 1 的数据
zrange myzset 0 -1 with scores // 返回所有集合以及其序号
zrange myzset 0 -1  // 返回所有集合

3、布隆过滤器

布隆过滤器（Bloom Filter）是一种数据结构，用于快速判断一个元素是否存在于一个大集合中。其核心思想是通过多个哈希函数将元素映射到一个位数组中，可以有效地减少存储空间的需求和查询时间。在实际应用中，Redis 布隆过滤器常用于缓存系统和数据过滤。

以下是 Redis 布隆过滤器的一些关键特点和操作：

存储结构： Redis 布隆过滤器通常由一个位数组（bitmap）和多个哈希函数组成。位数组是一个二进制数组，每个位表示一个元素是否存在于集合中。多个哈希函数用于将输入元素映射到位数组的多个位置。

添加元素： 当要向布隆过滤器中添加一个新元素时，将该元素经过多个哈希函数计算出对应的位数组位置，并将这些位置的值设为1。

检查元素： 当需要检查一个元素是否存在于布隆过滤器中时，将该元素经过多个哈希函数计算出对应的位数组位置，并检查这些位置的值是否都为1。如果其中有任何一个位置的值为0，则可以确定该元素一定不存在于集合中；如果所有位置的值都为1，则可能存在于集合中，但也可能是误判。

误判率： 布隆过滤器允许一定的误判率，即当一个元素被判断不存在于集合中时，可能实际上存在于集合中。误判率取决于位数组的大小和哈希函数的数量。误判率越低，性能越差。

容量和性能： 通过适当选择位数组的大小和哈希函数的数量，可以平衡布隆过滤器的存储空间占用和查询性能。更大的位数组和更多的哈希函数可以降低误判率，但会增加存储空间和查询时间。

在 Redis 中，可以使用以下几个命令操作布隆过滤器：

• BF.ADD：向布隆过滤器中添加一个元素。
• BF.EXISTS：检查一个元素是否存在于布隆过滤器中。
• BF.MADD：批量添加元素到布隆过滤器中。
• BF.MEXISTS：批量检查元素是否存在于布隆过滤器中。

使用 Redis 布隆过滤器能够在高效地判断一个元素是否存在于一个大集合中的同时，减少存储空间的占用和查询时间，是在缓存系统和数据过滤中常用的工具之一。

4、慢查询

在 Redis 中，慢查询是指执行时间超过一定阈值的命令查询操作。慢查询可能会影响 Redis 的性能和响应速度，因此及时发现和解决慢查询问题对于保障 Redis 的正常运行和性能优化至关重要。

以下是一些处理 Redis 慢查询的方法和技巧：

开启慢查询日志： Redis 提供了开启慢查询日志的功能，可以记录执行时间超过指定阈值的命令。通过配置 slowlog-log-slower-than 参数设置慢查询的阈值（单位为微秒），然后将 slowlog-max-len 参数设置为一个非零值，表示保存慢查询日志的条目数量限制。慢查询日志可以通过 SLOWLOG GET 命令查看和分析。

使用监控工具： 除了内置的慢查询日志外，还可以使用监控工具来实时监视 Redis 的性能和慢查询情况。例如，可以使用 Redis 的官方工具 RedisInsight 或者第三方监控工具如 RedisStat、RedisLive 等。

分析慢查询日志： 通过分析慢查询日志，可以找出哪些命令执行时间较长，然后针对性地进行优化或调整。可以根据慢查询日志中的命令信息、执行时间、客户端信息等，找出慢查询的原因，并采取相应的措施进行优化。

优化命令和数据结构： 对于经常出现慢查询的命令，可以考虑优化命令的使用方式或者选择更合适的数据结构来存储数据。例如，可以尽量减少频繁调用的命令、使用合适的数据结构来降低查询复杂度等。

提升硬件性能： 如果 Redis 实例的性能受到硬件限制，可以考虑提升硬件配置来改善性能。例如，增加 CPU 核心数、内存容量、使用 SSD 硬盘等。

使用集群和分片： 如果单个 Redis 实例无法满足需求，可以考虑使用 Redis 集群或者分片技术来水平扩展 Redis 的性能和容量。

通过以上方法和技巧，可以有效地处理 Redis 的慢查询问题，提升 Redis 的性能和响应速度，从而更好地支撑应用程序的需求。

5、LUA脚本

Lua 是一种轻量级的、可嵌入的脚本语言，常用于扩展和定制各种应用程序。在 Redis 中，Lua 脚本得到了广泛的应用，可以通过执行 Lua 脚本来实现一些复杂的操作，例如原子性地执行多个命令、实现复杂的数据操作逻辑等。

6、发布-订阅模式

7、Redis线程模型

Redis 内部使用文件事件处理器（file event handler） ，这个文件事件处理器是单线程的，所以Redis 才叫做单线程的模型。它采用非阻塞IO多路复用机制同时监听多个 socket ，根据 socket 上的事件来选择对应的事件处理器进行处理。文件事件处理器的结构包含 4 个部分：

• 多个 socket 。
• IO 多路复用程序。
• 文件事件分派器。
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）。

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

下面来大致说一下这个图：
1、 客户端 Socket01 向 Redis 的 Server Socket 请求建立连接，此时 Server Socket 会产生一个AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 Socket01，并将该 Socket01 的 AE_READABLE 事件与命令请求处理器关联。
2、假设此时客户端发送了一个 set key value 请求，此时 Redis 中的 Socket01 会产生AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 Socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 Socket01 的 set key value 并在自己内存中完成 set key value 的设置。操作完成后，它会将 Socket01 的 AE_WRITABLE 事件与命令回复处理器关联。
3、 如果此时客户端准备好接收返回结果了，那么 Redis 中的 Socket01 会产生一个AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 Socket01 输入本次操作的一个结果，比如 ok ，之后解除 Socket01 的AE_WRITABLE 事件与命令回复处理器的关联。

8、Redis管道

Redis Pipeline 是一种用于优化 Redis 数据库性能的机制，它允许客户端将多个命令打包发送到服务器，减少了网络往返的开销，提高了整体的执行效率。下面详细解释一下 Redis Pipeline 的工作原理和优势：

8.1 特点

• 单个命令：通常情况下，客户端发送一个命令到 Redis 服务器，并等待服务器的响应，然后再发送下一个命令。这种方式存在网络往返的延迟，尤其在需要执行大量独立命令时会导致性能下降。
• Pipeline：通过 Pipeline，客户端可以将多个命令打包发送到服务器，而不需要等待每个命令的响应，服务器会一次性处理所有命令，并将结果一次性返回给客户端。
• 批量发送：客户端将多个命令打包发送到服务器，服务器会按照命令的顺序依次执行，然后将所有命令的结果返回给客户端。
• 无序执行：尽管 Pipeline 会按照发送的顺序依次执行命令，但是并不保证命令的执行顺序与发送顺序完全一致。这是因为 Redis 是单线程的，可能会有其他命令插入到 Pipeline 中间。
• 原子性保证：Pipeline 中的所有命令都是原子执行的，即要么全部执行成功，要么全部执行失败。

8.2 优势

• 减少网络往返延迟：通过 Pipeline，客户端可以在单个请求中发送多个命令，减少了网络通信的往返次数，提高了性能。
• 减少服务器压力：减少了网络通信的次数，降低了服务器的负载压力，特别是在需要大量并发命令的场景下效果明显。
• 提高吞吐量：由于减少了网络往返的开销，整体的命令执行效率得到提升，使得系统的吞吐量也相应增加。
• 原子性操作：Pipeline 中的所有命令都是原子执行的，保证了数据的一致性和完整性。

8.3 使用场景

• 批量写入：需要一次性写入大量数据到 Redis，可以使用 Pipeline 将多个写入命令一次性发送到服务器，减少网络开销。
• 批量读取：需要一次性读取多个键的值，可以使用 Pipeline 将多个读取命令一次性发送到服务器，减少网络开销。
• 事务操作：可以将多个 Redis 命令打包成一个事务，使用 Pipeline 一次性发送到服务器，实现原子性操作。
• 计算密集型任务：某些计算密集型任务可以通过 Pipeline 批量发送，减少网络通信开销，提高性能。

总的来说，Redis Pipeline 是一种非常有效的性能优化机制，特别适用于需要大量并发操作或者批量操作的场景，能够显著提高 Redis 数据库的整体性能和吞吐量。

9、Springboot整合Redis

二、Redis持久化

1、RDB

1.1 工作原理

• 生成快照：RDB 是通过生成数据库的快照来进行持久化的。当满足一定条件时（比如达到一定时间间隔或者写入一定数量的命令），Redis 会fork一个子进程，将当前内存中的数据以快照的形式写入到磁盘上的一个 RDB 文件中。
• 写入策略：RDB 文件是一个二进制文件，保存了 Redis 在某个时间点上的数据库状态，包括所有的键值对、过期时间等信息。
• 恢复数据：当需要恢复数据时，Redis 可以通过加载 RDB 文件来重新构建数据库的状态。

1.2 优势

• 性能高：RDB 在进行持久化时，不会影响 Redis 的性能，因为是将内存数据直接写入磁盘，速度较快。
• 文件紧凑：RDB 文件相对较小，因为它只保存了某个时间点的数据库状态，不需要保存历史操作。

1.3 使用场景

• 备份恢复：适用于备份和恢复数据，以及周期性地保存数据库快照。
• 灾难恢复：在发生系统故障或断电情况下，可以使用 RDB 文件快速恢复数据。

2、AOF

2.1 工作原理

• 记录写命令：AOF 是通过追加方式记录每个写操作的命令来进行持久化的。每当有一个写操作（比如 SET、DEL 等）发生时，Redis 就会将这个命令追加到 AOF 文件的末尾。
• 持久化策略：Redis 支持多种 AOF 持久化策略，包括每个写命令、每秒钟记录一次、不定期记录等。
• 恢复数据：当需要恢复数据时，Redis 可以通过重新执行 AOF 文件中保存的写命令来恢复数据库的状态。

2.2 优势

• 持久化更可靠：AOF 持久化方式比 RDB 更可靠，因为它记录了每个写操作，避免了数据丢失的风险。
• 数据更完整：AOF 文件记录了写操作的历史，因此可以更完整地恢复数据库状态。

2.3 使用场景

• 数据完整性要求高：对数据完整性要求较高，不能容忍数据丢失的场景。
• 恢复速度不是关键：不介意稍微慢一点，但要求数据完整性高的场景。

3、 RDB与AOF的选择

• 两者结合使用：Redis 支持同时使用 RDB 和 AOF，这样既能享受 RDB 的高性能备份和恢复，又能保证 AOF 的数据完整性。
• 根据需求选择：根据实际需求选择适合的持久化方式。如果对数据的实时性要求不是很高，但是对数据完整性要求较高，可以选择 AOF；如果对性能要求较高，可以选择 RDB。
• 持久化配置：Redis 允许用户通过配置文件灵活地选择和调整 RDB 和 AOF 的持久化参数，以满足不同的业务需求

总的来说，RDB 和 AOF 是 Redis 中常用的持久化方式，各有优势和适用场景。选择合适的持久化方式或者结合两者使用，可以有效保证数据的安全性和可靠性。

三、Redis事务

Redis事务即一次性、顺序性、排他性的执行一个队列中的一系列命令。与关系型数据库事务不同，它不保证原子性，也没有隔离级别。相关命令如下：

• MULTI：事务开始，标记一个事务块的开始。
• EXEC：提交事务，Redis执行事务中的所有命令。
• DISCARD：取消事务，放弃执行已加入的所有事务命令。
• WATCH：可以设置监视一个或多个键，当被监视的键被其他客户端改变时，事务被中断（类似于CAS）。

1、正常执行事务

MULTI                  # 开始事务
SET key1 value1        # 将命令加入事务
SET key2 value2        # 将命令加入事务
GET key3               # 将命令加入事务
EXEC                   # 提交事务

2、事务取消

MULTI                  # 开始事务
SET key1 value1        # 将命令加入事务
GET key3               # 将命令加入事务
DISCARD                # 取消事务

3、事务队列存在命令错误

MULTI                  # 开始事务
SETTTTT key1 value1        # 错误命令
SET key2 value2        # 将命令加入事务
GET key3               # 将命令加入事务
EXEC                   # 此时执行错误会直接报错

4、事务队列发生执行错误

SET key1 value1
MULTI              # 开始事务
INCR key1          # 错误执行 （value1 为 String）
SET key1 value2    # 将命令加入事务
EXEC               # 成功执行
GET key1           # 返回 value2 

四、分布式锁

五、高并发Redis 集群

Redis集群有三种模式，分别是主从复制模式、哨兵模式和集群模式。下面详细解释每种模式的特点和用途：

1、主从复制模式

主从复制是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

优点：

• 数据冗余和备份：主节点负责处理写操作，而从节点则复制主节点的数据副本。这种复制机制确保了数据的冗余和备份，提高了系统的可靠性和稳定性。
• 读写分离：主节点负责处理写操作，而从节点可以处理读操作，从而分担了主节点的读负载。这种读写分离的架构可以提高系统的性能和吞吐量。
• 故障转移：当主节点失效时，Redis主从复制模式能够自动进行故障转移，选举一个新的主节点，并将从节点提升为新的主节点，以保持系统的可用性。
• 数据一致性：Redis主从复制模式保证了数据的一致性，即使主节点发生故障，新的主节点也会通过复制从节点上的数据来保持一致性。
• 扩展性：通过添加更多的从节点，Redis主从复制模式可以实现横向扩展，从而处理更大规模的数据和更高的并发访问。

缺点：

• 单点故障：主节点仍然是单点故障的一个潜在风险，如果主节点失效，可能会导致一段时间内的服务中断。
• 写入性能受限：由于写操作必须由主节点处理，主节点可能成为系统的性能瓶颈，特别是在高写入负载的情况下。
• 配置管理复杂：主从复制模式需要管理主节点和从节点之间的复制配置，以及故障转移和重新配置的相关问题，增加了系统的管理和维护成本。

用途：

• 主从复制模式适用于需要数据冗余和读取负载均衡的场景。
• 可以用于构建读写分离架构，将读操作分发到从节点上，从而提高系统的性能和吞吐量。

2、哨兵模式

Redis哨兵模式是一种基于主从复制的高可用性解决方案，通过引入一组哨兵节点监视Redis集群中的主节点，并在主节点失效时自动进行故障转移，以保证系统的可用性。

优点：

• 主节点监视：哨兵节点定期检查主节点的健康状态，包括网络连接、性能指标和持久化状态等，以确保主节点的正常运行。
• 自动故障检测：当主节点失效或不可达时，哨兵节点能够检测到故障，并立即启动故障转移流程，选举一个新的主节点并更新从节点的配置。
• 故障转移：哨兵节点负责监视主节点的状态，并在必要时触发故障转移，将失效的主节点替换为一个健康的从节点，以保持系统的可用性。
• 配置自动更新：哨兵节点会自动更新集群的配置，将新的主节点信息通知给所有客户端和其他哨兵节点，以确保所有节点都能够正确识别新的主节点。
• 多哨兵节点支持：哨兵模式支持多个哨兵节点部署，以提高系统的可靠性和容错能力。如果一个哨兵节点发生故障，其他哨兵节点仍然可以继续监视和管理集群。

缺点：

• 配置复杂性：部署和配置哨兵模式需要一定的经验和技术，特别是在管理多个哨兵节点和处理故障转移过程中。
• 性能开销：哨兵节点会定期发送心跳检测主节点的状态，可能会增加一定的网络流量和系统负载，对系统性能产生一定的开销。
• 延迟故障检测：哨兵模式依赖于心跳机制检测主节点的状态，可能存在一定的延迟，导致故障检测和故障转移的响应时间较长。

用途：

• 哨兵模式适用于需要实现Redis集群的自动故障转移和高可用性的场景。
• 可以用于构建具有故障转移能力的Redis集群，提高系统的稳定性和可靠性。

3、集群模式

Redis集群模式是Redis官方推荐的分布式解决方案，用于实现数据分区、负载均衡和故障容错。Redis集群模式通过将数据划分为多个槽位，并将槽位分布在多个节点上，实现数据的分布式存储和高可用性。

优点：

• 高可用性：Redis集群通过自动故障转移和数据冗余，保证了系统在节点失效时仍然能够提供服务，提高了系统的可用性和稳定性。
• 横向扩展：Redis集群支持横向扩展，可以根据需要动态添加更多的节点，以处理更大规模的数据和更高的并发访问。
• 负载均衡：Redis集群通过数据分区和请求路由机制实现了负载均衡，可以有效地分摊读写负载，提高系统的性能和吞吐量。
• 动态伸缩：Redis集群支持节点的动态添加和移除，可以根据系统的负载和需求灵活调整集群的规模，而无需停机或中断服务。

缺点：

• 复杂性：配置和管理Redis集群需要一定的技术和经验，特别是在处理故障转移、数据再平衡和节点扩缩容等方面的复杂性。
• 网络开销：Redis集群节点之间需要进行频繁的通信和数据同步，可能会产生较大的网络开销，对系统的性能产生一定影响。
• 数据一致性延迟：在节点失效和故障转移过程中，可能会出现数据一致性延迟的情况，影响系统的实时性和准确性。
  用途：
• 集群模式适用于需要横向扩展和高性能的大规模Redis部署场景。
• 可以用于构建分布式缓存、会话存储、实时数据分析等应用，满足不同场景下的性能和可用性要求。

六、Redis缓存使用问题

数据一致性

消息队列

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

在Redis中，有三个常见的问题，分别是击穿（Cache Breakdown）、穿透（Cache Penetration）、雪崩（Cache Avalanche）。下面介绍这三个问题以及解决方案：

• 缓存击穿（Cache Breakdown）：
  当某个热点数据在缓存中过期后，有大量的并发请求同时访问该数据，导致缓存无法命中，从而请求直接穿透到数据库，导致数据库压力激增。
  解决方案：
  • 对于即将过期的数据，使用互斥锁（Mutex）进行加锁，防止大量的并发请求同时访问数据库。
  • 对于缓存未命中的请求，将请求先发送到消息队列中，通过消息队列来控制数据库的并发访问。
• 缓存穿透（Cache Penetration）：
  恶意攻击者发送大量的恶意请求，请求的数据在缓存中不存在，但是却都会直接访问数据库，导致数据库压力过大。
  解决方案：
  • 使用布隆过滤器（Bloom Filter）等技术，对请求的数据进行过滤，判断数据是否存在于缓存中，从而避免对数据库的不必要访问。
  • 当缓存未命中时，将空结果（Null）也缓存起来，设置较短的过期时间，防止大量的恶意请求反复穿透到数据库。
• 缓存雪崩（Cache Avalanche）：
  当缓存中的大量数据同时过期失效，导致大量的请求直接访问数据库，造成数据库压力激增。
  解决方案：
  • 设置合理的缓存过期时间，避免所有缓存数据同时过期失效。
  • 使用不同的过期时间，对缓存数据进行分散，避免同时过期失效。
  • 引入热点数据预热机制，在系统空闲时对热点数据进行预加载，避免大量请求同时访问。

综合来看，对于这三个问题，通常的解决方案包括合理设置缓存过期时间、使用互斥锁进行并发控制、使用布隆过滤器进行数据过滤、对空结果进行缓存、热点数据预热等。通过综合运用这些技术手段，可以有效地解决Redis中的击穿、穿透和雪崩问题，提高系统的稳定性和性能。

热点Key、BigKey

在Redis中，热点Key（Hot Key）和Big Key（大Key）是两个常见的性能问题，它们都可能导致Redis集群的性能下降和可用性问题。

1、热点Key
热点Key是指在Redis中频繁被访问的Key，通常是由于某些业务场景导致某个Key的访问频率远高于其他Key。热点Key可能会导致某个节点的负载过高，成为系统的性能瓶颈，进而影响整个Redis集群的性能和稳定性。

解决方案：

• 数据分片：将热点数据均匀分布到多个节点上，避免单个节点负载过高。
• 使用缓存预热：在系统启动时，预先加载热点数据到缓存中，避免大量请求同时访问热点数据。
• 定时过期：针对热点Key设置较短的过期时间，定期更新缓存，避免数据过期失效。

2、Big Key
大Key是指Redis中存储的某个Key所对应的数据结构非常大，可能包含大量的元素或者占用大量的内存空间。大Key可能会导致Redis节点的内存占用过高，影响Redis集群的性能和可用性，甚至引发内存溢出问题。

解决方案：

• 拆分大Key：将大Key拆分成多个小Key，减少单个Key所占用的内存空间。
• 使用分布式数据结构：使用Redis的分布式数据结构，如分布式哈希表（Hash）、分布式集合（Set）等来分散数据。
• 定期清理：定期检查大Key，并清理或者分割大Key，释放内存空间。

针对热点Key和大Key问题，需要结合具体的业务场景和数据特点来进行优化和解决。通过合理的数据分片、缓存预热、定期过期等技术手段，可以有效地减轻Redis集群的负载，提高系统的性能和可用性。

数据倾斜

在Redis集群中，数据会按照一定的算法分布在slot上，而slot会被分配到集群中每个redis实例上。Redis数据倾斜是指某些键或某些分片上的数据量远远超过其他键或分片的情况。数据倾斜一般分为两种：

• 数据量倾斜：在某些情况下，实例上的数据分布不均匀，某个实例上的时候特别多。
• 数据访问倾斜：虽然每个实例上的数据量差别不大，但是某个实例上的数据是热点数据，被访问的非常频繁。

1、数据量倾斜

• 存在bigkey
• slot分配不均匀
• HashTag使用不当

2、数据访问倾斜
数据量访问倾斜往往是因为Hot Key导致

脑裂

Redis脑裂（Redis Split-Brain）是指在分布式Redis集群中出现的一种问题，其中集群中的节点由于某种原因失去了彼此之间的联系，导致集群分裂成多个孤立的子集群。这可能会导致数据一致性问题，因为每个孤立的子集群都可能认为自己是整个集群的唯一领导者（master），从而导致数据冲突和数据丢失。
产生原因：

• 网络分区：网络分区是最常见的原因之一，其中集群中的节点由于网络故障或延迟而无法互相通信。
• 节点故障：如果Redis集群中的某个节点发生故障，而其他节点无法检测到该节点的状态，可能会导致脑裂。
• 节点配置不一致：如果Redis集群中的节点配置不一致，例如不同的配置文件或不同的集群配置，可能会导致节点之间的通信问题，从而导致脑裂。

解决方案：
应对脑裂的解决办法应该是去限制原主库接收请求，Redis提供了两个配置项。

• min-slaves-to-write：与主节点通信的从节点数量必须大于等于该值（至少N个健康从库），否则主节点拒绝写入。
• min-slaves-max-lag：主节点与从节点通信的ACK消息延迟必须小于该值（最大消息延迟T秒），否则主节点拒绝写入。

主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的请求了。

Redis缓存刷新策略

1、定时刷新：

• 定时刷新是指在固定的时间间隔内定期刷新缓存数据。可以通过Redis的定时任务或者外部调度器（比如cron job）来实现。
• 适用于数据更新频率较低且可以容忍一定延迟的场景，例如定期更新某些静态数据或者数据变化不频繁的场景。

2、基于过期时间的刷新：

• 利用Redis的过期时间特性，设置缓存数据的过期时间，在数据过期时自动刷新。
• 可以通过在数据过期之前触发异步刷新操作来实现，确保在数据过期时能够及时获取到最新数据。
• 适用于数据更新频率较低，但需要保证缓存数据时效性的场景。

3、基于事件驱动的刷新：

• 当数据发生变化时，触发相应的事件，通知缓存层进行数据刷新。
• 可以利用消息队列、发布-订阅模式或者数据库触发器等机制来实现。
• 适用于数据更新频率较高，需要实时刷新缓存数据的场景。

4、手动触发刷新：

• 在数据变化时，手动调用刷新接口来更新相关缓存数据。
• 需要在数据写入或更新操作之后主动调用刷新接口，确保缓存数据与数据库数据保持一致。
• 适用于需要精确控制缓存刷新时机的场景，例如对数据一致性要求较高的业务场景。

5、淘汰策略：

• 当缓存空间不足时，根据一定的淘汰策略来选择需要刷新的缓存数据，以释放缓存空间。
• 常见的淘汰策略包括最近最少使用（LRU）、最少访问频率（LFU）等。
• 适用于需要动态调整缓存数据数量的场景，确保缓存数据的重要性和可用性。

Redis数据删除策略

• 定时删除：定时删除时给key都设置一个过期的时间，当达到删除时间节点时，立即执行对key的删除。
• 惰性删除：Redis的惰性删除是指在进行缓存淘汰（eviction）时，Redis不会主动删除已过期的数据，而是在需要访问某个键时，才会检查该键是否已过期，如果过期则立即删除。
• 定期删除：上述两种方式的折中方案。周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度。同时也会启用惰性删除。

Redis应用场景