回答当Redis内存不足时，我们可以使用如下几个策略来进行优化。一、增加物理内存这是最直观有效的方法，内存不够，那就加内存，而且现在内存便宜。二、使用集群方案使用Redis集群方案将数据分散在多个节点，这样可以有效的解决Redis内存不足问题。为什么需要RedisCluster？它解决了什么问题？三、配置maxmemory-policy和maxmemorymaxmemory用于配置Redis能够使用的最大内存容量，一旦内存使用达到这个限制，Redis就会根据maxmemory-policy指定的策略来处理内存溢出。请描述一下Redis的缓存淘汰策略Redis缓存满了怎么办？四、优化数据结构使用压缩算法：Redis支持压缩存储，可以将存储的数据进行压缩以减小内存占用。减少key的长度：key的长度会占用Redis的内存，尽量减少key的长度，可以有效减小Redis的内存占用。选择合适的数据结

回答Redispipeline是Redis的一种优化计划，主要通过减少网络往返次数（RTT）来提高命令执行效率。当我们需要执行多个命令时，如果采取依次调用Redis并等待Redis响应的方式来处理，然而这种一来一回的通信模式在命令多、网络延迟显著的情况下会严重影响应用的性能。采用pipeline会有如下几个显著的优势。减少网络延迟：通过pipeline，可以将多个命令打包后再一起发送，然后接收所有命令的响应。这样只需要一次往返就可以完成多个命令的交互，减少了网络延迟。提高命令吞吐率：因为减少了网络往返次数，可以在更短的时间内执行更多的命令，从而提高了系统的整体命令处理速度。扩展Redis性能瓶颈主要是网络，主要原因就在于Redis执行命令的时间通常在微妙级别。正常情况下，我们执行一条Redis命令流程要经过如下几个步骤：客户端发送Redis命令，阻塞等待Redis应答Redis接收到命令，

回答Redis在持久化时有如下几种情况会阻塞Redis服务器。执行SAVE命令：当我们手动执行SAVE命令时，Redis会阻塞所有其他客户端的请求直到RDB快照文件创建完毕。执行BGSAVE命令：虽然BGSAVE是在一个子进程中进行的，在创建RDB快照文件过程中，主进程依然可以继续响应客户端请求。但是在执行BGSAVE命令后，主进程需要进行一次fork()操作，fork()操作在内存资源紧张或者数据集较大的情况下可能非常耗时，这期间主进程会被短暂阻塞。重写AOF文件：与BGSAVE命令一样，重写AOF文件（BGREWRITEAOF）也是发生在fork子进程过程中。配置always同步策略：在always同步策略的模式下，Redis的每个写命令都会被同步写入到磁盘中，写命令的响应时间会因为磁盘I/O速度受限而增加，从而导致阻塞。关于Redis的持久化请阅读：Redis的持久化机制是怎样的？

回答Redis的高性能是我们毋庸置疑的，但是Redis也会存在阻塞的情况，导致整个系统变慢，从而影响用户体验。以下几种场景会导致Redis阻塞。一、慢查询若Redis执行一个命令的时间超过指定的阈值（slowlog-log-slower-than），则Redis会将该命令记录到慢查询日志中。由于Redis执行命令是单线程，如果执行某个命令花费时间比较长，则会阻塞其他命令的执行，如果执行大量的慢查询，则会严重阻碍Redis服务的性能。关于慢查询详情请阅读：了解Redis的慢查询吗？二、操作大key大key是指key对应的value很大。大key可能导致Redis阻塞的情况有两种：超时阻塞：由于Redis是单线程执行命令的，操作大key比较耗时，这会阻塞其他命令的执行。同时，如果我们要删除某个大key，则需要一次性释放所有与该key相关联的内存，这是一个相当消耗CPU的过程。网络阻塞：大key

回答Redis的慢查询是一个记录查询执行时间超过指定阈值的查询命令的功能。它的工作原理是：当一个命令的执行时间超过slowlog-log-slower-than设置的阈值时，该命令就会被记录到慢查询日志中。日志中详细记录了慢查询发生的时间、执行时长、具体什么命令等信息。它有两个参数：slowlog-log-slower-than：慢查询阈值，单位为微秒，当命令执行时间超过这个阈值时，命令会被记录到慢查询日志中。如果该值设置为负数，则会关闭Redis慢查询功能。slowlog-max-len：慢查询日志长度，用于限制慢查询日志的大小，防止消耗过多内存。慢查询日志是一个先进先出队列，当新的慢查询产生且日志已满时，最旧的记录会被移除。扩展如何使用慢查询Redis提供了以下命令用于慢查询日志的操作：SLOWLOGGET[n]：查看最近的n条慢查询记录。不输入[n]的值，则表示查询所有的慢查询日志。

回答在Redis生产环境中我们是禁止使用KEYS命令的。因为KEYS命令它会返回所有匹配的key，Redis在执行该命令时会扫描整个键空间来匹配该模式下的所有key，这个操作的时间复杂度为O(N)，N表示Redis中key的总数，这意味如果在Redis中的key非常多的情况下，KEYS命令的执行可能会非常慢。同时，由于Redis是单线程的，当它在执行KEYS命令时，它会阻塞其他所有命令的执行，这会严重拖慢整个服务的吞吐量。扩展使用Scan代替keysSCAN命令是KEYS命令的一个安全替代品。SCAN命令不像KEYS一次性锁定Redis整个key空间，而是采用逐步迭代Redis中的key，每次调用只返回一小部分key，并可以在多次调用中使用游标来继续迭代。这种方式就大大减少了对Redis服务器的性能影响。SCANcursor[MATCHpattern][COUNTcount]cursor：

回答Redis通过一个叫做过期字典（可以看作是hash表）来保存数据过期的时间。当我们为一个key设置过期时间，例如SETsikesike-javaEX100，Redis会在国企字典中添加一个题目，其中key指向该键（sike），value是当前时间加上指定的秒数（转换成的Unix时间戳）。数据结构如下：typedefstructredisDb{...dict*dict;//数据库键空间,保存着数据库中所有键值对dict*expires//过期字典,保存着键的过期时间...}redisDb;我们知道Redis的过期数据删除分为两种策略：惰性删除和定时删除。惰性删除：每次访问某个key时，Redis会首先在过期字典中查找这个key，如果已找到且时间戳大于当前时间戳，表明该key已过期，则Redis会立刻从从所有相关的数据结构中删除该key，包括过期字典和该key本身的数据结构。定时删除：Re

回答虽然Redis最常用的用途是作为内存使用，提供高性能的缓存解决方案。但是它的功能远不止于此，以下是Redis除了作为缓存外的常见应用场景。一、消息队列Redis支持发布/订阅模式，可以用作消息队列来处理异步任务或实现系统间的消息传递。生产者通过PUBLISH命令向特定频道发布消息。消费者使用SUBSCRIBE命令订阅一个或多个频道，订阅频道后，消费者便可以接收到所有发送到该频道的消息。详细情况请阅读：怎么使用Redis实现一个消息队列二、计数器Redis的命令是原子性的，所以它非常适合用作计数器，比如网站访问统计、在线活动的用户数统计或社交媒体中的点赞和评论计数。Redis提供了四个命令来操作计数：INCR：用于将键的整数值增加1。DECR：用于将键的整数值减少1。INCRBY：增加指定的整数值。DECRBY：减少指定的整数值。例如：INCRtest_counter这样会给test_c

回答RedisCluster中采用哈希槽而不是一致性hash算法，主要原因是为了简化节点的管理和数据的迁移。一、故障转移在RedisCluster中，每个Master节点都有一个或多个Slave节点，Slave节点会复制Master节点的数据。当Master节点出现故障时，Slave节点会被迅速提升Master节点，接管Master节点负责的哈希槽和数据，继续提供服务。而一致性哈希算法是没有Master-Slaver的概念的，当一个节点失败时，其负责的数据会自动转移到哈希环中的下一个节点，虽然这种方案是可行的，但是还是存在一些问题的：数据重分配代价高：数据迁移到下一个节点，原节点的数据需要在下一个节点上面重建，重建过程代价会比较高。可能会有缓存雪崩：数据迁移过程中，可能会导致大量请求无法命中缓存，而直接落入数据库，导致数据库宕机，造成缓存雪崩。二、数据倾斜在实际生产场景中，我们大概率会遇到

回答可以提供服务。RedisCluster扩容、缩容的本质其实是slot的迁移。在slot迁移过程，如果客户端给当前Redis节点发送请求，则有两种情况：如果该key所对应的slot还在当前Redis节点，则直接处理，并返回处理结果。如果该key所对应的slot还在迁移过程中，则该节点返回一个ASK重定向错误，告诉客户端该请求对应的slot正在进行迁移，请去目标节点发送请求吧。客户端接受ASK响应后，则先向目标节点发送一个ASKING指令，告诉目标节点，接下来的这条指令，你必须执行，然后紧接着发送原请求。如果该key所对应的slot不在当前Redis节点，或者已经被迁移到其他目标节点了，则该节点返回一个MOVED重定向错误，客户端接受响应后，直接向目标节点发送指令即可，同时会更新客户端的slot缓存关于RedisCluster扩容、缩容详情请阅读：RedisCluster是如何进行分片的？

回答RedisCluster中节点间采用Gossip（流言）协议进行通信。Gossip协议不需要集群中的所有节点都完全了解集群中每一个节点的详细信息，它的核心在于通过节点间的随机交换信息来实现整个集群中各节点的信息的最终一致性。在RedisCluster中，所有节点都持有一份数据，如果某个节点出现了数据变更，则该节点会把数据不断地发送给其他节点，其他节点接收到信息后进行数据变更，一段时间后，整个RedisCluster集群中的所有节点都会完成数据变更，从而保证整个集群所有节点的数据都是完整的。扩展每个节点都有一个专门用于节点间通信的端口号，就是自己提供服务的端口号+10000。每个节点会定期向另外几个节点发送PING消息，同时其他节点接收到PING之后会返回PONG消息。消息分类Gossip协议的主要职责就是信息交换，在RedisCluster中，Gossip消息可分为：PING消息、PO

回答RedisCluster采用的是一种基于Raft的选举算法，且使用Gossip协议来进行节点间的信息交换，包括节点状态的更新。整个选举过程分为如下几个步骤：故障发现在RedisCluster，每个节点都会定期向其他节点发送心跳数据（PING），如果一个主节点在指定时间内没有响应PING，那么首先发现这一情况的节点会认为该主节点可能失效了，并开始向其他节点发送带有故障主节点的FAIL消息。选举触发当超过半数的节点确认收到关于同一个主节点的FAIL消息，该主节点会被RedisCluster标记为FAIL。一旦主节点被标注为FAIL，则该主节点中的从节点会触发选举机制，共同竞争成为Master节点。选举从节点（A）将自己记录的集群currentEpoch（选举轮次标记）加1，并广播FAILOVER_AUTH_REQUEST消息给集群中其他节点进行选举。集群中的其他节点接收到该消息后，判断请求

回答一、保证足够的容错性和高可用性RedisCluster的设计目标就是保证Redis集群中即使部分节点失败的情况下仍然能保证整个集群的稳定运行。如果只有两个主节点，一旦其中一个主节点失败，那么整个集群的压力就全部集中到一个节点上了，而该节点可能因为无法承担全部的数据和请求而导致奔溃。至少三个主节点，一个主节点失败，其余主节点依然可以通过互相协作来继续提供服务。二、选举和决策的一致性在RedisCluster中，主节点使用Raft算法进行故障检测和Master选举。而Raft算法要求多数节点存活来保持集群状态的一致性和决策的有效性，即新Master的选举需要大于半数的集群Master节点同意才能选举成功。如果整个集群只有两个节点，其中一个挂了，另外一个主节点则无法根据协议进行决策，也就会因为无法选举新的Master节点导致无法实现故障转移了。关于RedisCluster选举请参考：在Red

回答在RedisCluster中，客户端请求路由有三种：MOVED重定向：MOVED重定向是最常见的路由方式。当客户端向任意Redis节点发送请求，如果该节点不负责该请求的槽，则它会返回一个MOVED错误，附带正确节点的地址（目标节点），则客户端向目标节点发送请求。ASK重定向：ASK重定向用于RedisCluster正在进行哈希槽重分配过程的一种临时方案。当一个哈希槽正在从一个节点迁移到另外一个节点，而客户端发送的请求恰好落在这个迁移的哈希槽上，则源节点会返回一个ASK错误，指示客户端这个请求应临时发送到目标节点。Smart客户端：Smart客户端会独立维护一份集群的节点和哈希槽映射表，并能够自动处理MOVED和ASK重定向，无需手动干预。而且当某个节点与槽的映射关系发生改变时，客户端也会及时更新。扩展MOVED重定向MOVED重定向的过程如下：客户端基于本地的哈希槽与节点的映射关系，向

回答RedisCluster采用分片（sharding）的方式来提供数据的水平扩展能力。RedisCluster使用哈希槽来分配数据到不同的节点。每个key通过CRC16算法得到一个哈希值，然后根据这个哈希值来确定key应该被放置在哪个哈希槽中。RedisCluster一共有16384个哈希槽，每个节点负责管理一部分哈希槽。假如有三个Redis节点，那么第一个节点负责0~5460，第二个节点负责5461~10922，第三个节点负责10923~16383。当一个客户端尝试访问一个key时，同样使用CRC16算法来确定访问的key在哪一个哈希槽中，然后直接连接到负责该槽的节点。客户端请求路由目前主流方式有三种：moved重定向、ask重定向以及smart智能客户端。当RedisCluster中的节点有增加时，RedisCluster新增节点进行上线操作，以及哈希槽的重分配，即需要将其他现有Re

回答在RedisCluster中，数据的分布是通过哈希槽来实现的。Redis将所有的key"均匀"地分布在16384个哈希槽中，当我们使用某个key进行操作时，需要先确认该key是属于哪个哈希槽，然后再去进行操作。Redis采用CRC16算法对key进行哈希计算，然后将得到的哈希值与16383进行位与运算（hash%16384），这样就可以确保key被均匀地分布在0~16383这些槽位之间。hash_slot=CRC16(key)mod16384扩展CRC16CRC16（CyclicRedundancyCheck16bit）即循环冗余校验码，是一种常用的校验算法，主要用于数据通讯和数据存储领域，用于检测数据传输或存储中的错误。在RedisCluster中，CRC16用于计算key的哈希槽位置。CRC16是基于多项式运算，在计算时，数据被视为一个巨大的二进制数字。这个数字

回答RedisCluster是Redis的一种分布式解决方案，它通过分片（sharding）来进行数据管理（「分治思想」的一种实践），并提供复制和故障转移的功能。Redis开始时只有一个Master主节点，为了提升Redis数据的可靠性，升级了主从模式。但是，这样无法解决Redis服务的可靠性。后面，加入了哨兵模式，提升了Redis的可靠性。不过，无论是主从模型还是加入了哨兵模式，处理命令的永远都是一个Master节点，Master节点里面存储了所有的数据，这样就面临两个问题：如果数据太多，导致内存暴增，会导致单一的Master节点无法加载所有的数据。Master节点在并发较高的情况下，会因为网络I/O的限制，导致处理速度较慢。解决这两个问题有两种办法：纵向扩展：升级硬件。比如增加内存和使用更好的网络设备。横向扩展：RedisCluster。单个Master节点有问题，那我就使用多个Mas

回答Redis持久化有两种：RDB和AOF。RDB：是将Redis在某个时间点的数据快照写入磁盘。AOF：是将Redis执行的每个命令追加到文件中。大key就意味着value数据比计较大，则他会对Redis持久化产生如下几个影响。一、内存和CPU使用增加在执行RDB生成快照文件时和AOF重写时，Redis需要处理Redis内存中的所有数据，如果存在大key，那么在这个处理过程中会消耗更多的内存和CPU资源。同时，AOF文件中包含了Redis执行的每一条命令，如果大key变更频繁，会导致AOF文件迅速增大，严重影响存储效率。尤其是在处理AOF重写机制时，如果有大key需要重写，那么将对CPU和磁盘I/O产生较大的压力。二、增加fork()操作的成本在生产RDB快照文件（bgsave）和AOF重写过程中，Redis需要执行fork()操作来生成子进程，如果有大key，则会增加Redis内存使用

回答缓存预热是指在系统启动之前或者高峰来临之前，提前将热点数据加载到缓存中的过程。缓存预热的目的是为了提高缓存命中率和系统的响应速度。一般来说缓存预热有如下几个作用：提高响应速度：预先将热点数据加载到缓存中，可以确保用户在实际访问时，能够从缓存中快速获取数据，从而提高系统响应速度。避免冷启动问题：系统启动后，缓存中是没有数据的，这被称之为冷启动。面对用户请求时，请求直达数据库，如果请求量较大，则会加大数据库压力。缓存预热提前将数据加载进缓存中可以避免请求直达数据库。平滑流量高峰：在流量高峰来临之前，将热点数据加载进缓存可以使系统能够更加从容地应对流量高峰，避免因为突然的流量增加而影响系统性能。缓存预热的实现通常需要依赖于对业务的理解，因为缓存容量有限，你不能将所有数据一股脑子全部加载进缓存中，所以我们需要确定哪些属于热点数据。实现的方法有如下几种：一、系统启动时加载这是一种很常见，也是我们

回答缓存穿透是指请求一个根本不存在的数据（不在缓存中也不在数据库中），由于数据在数据库也不存在所以就无法加载到缓存中，这就导致这个不存在的数据每次请求都要到数据库里面去查询，给数据库带来了不必要的访问压力。如果这类请求非常频繁，这会严重影响数据库的性能，甚至会使数据库奔溃。缓存穿透的发生一般是这两种情况业务误操作。比如数据库和缓存中的数据被误删了，导致数据库和缓存中都没有数据了。黑客攻击。比如黑客估计访问大量不存在的业务数据。应对缓存穿透，常见的方案有三种。一、过滤非法请求在API入口增加请求参数的判断，判断参数是否合理、参数中是否有非法值、必要请求字段是否存在等等校验手段，如果判断是恶意请求就直接返回错误，避免请求进一步到缓存和数据库。二、缓存空值如果查询数据库数据不存在时，则在缓存中存储空值（或默认值），这样当再次访问相同的不存在的数据时，可以直接返回缓存中的空值（或默认值），不需要再

回答缓存击穿属于缓存雪崩的子集，它是指缓存中的某个热点key在缓存中不存在时（比如过期），此时大量请求访问该热点key，由于无法命中缓存，会直接访问数据库，导致数据库压力剧增，严重时甚至会让数据库奔溃。缓存击穿的关键点在于单一热点缓存数据失效，瞬间海量请求压垮数据库。应对缓存击穿的方案和应对缓存雪崩一样，可以采取如下两种方案：设置热点数据永不过期。对于一些访问频率极高的热点数据，我们设置它永不过期，如果有更新的话，就更新缓存数据。使用分布式锁。当业务线程在处理请求时，如果发现访问的数据不在缓存中时，就增加一个分布式锁，然后该业务线程去加载缓存，其他线程由于获取不到分布式锁会被阻塞。具体方案请参考：什么是缓存雪崩？如何避免缓存雪崩？

回答缓存雪崩是指在缓存系统中，由于大量的数据同时过期或者Redis故障宕机时，由于此时Redis无法处理，于是大量请求都落在数据库上，从而导致数据库的压力剧增，甚至会造成数据库奔溃的现象，从而形成一系列连锁反应，造成整个系统崩溃。解决缓存雪崩主要从两个方面着手，由于造成它产生的原因是大量数据同时过期或者Redis服务宕机，所以我们可以从这两个方法来着手。一、大量数据过期设置不同的缓存过期时间。在原有的过期时间上加上一个随机数，这样就会使得缓存的过期时间不会太集中。设置热点数据永不过期。对于一些访问频率极高的热点数据，我们设置它永不过期，如果有更新的话，就更新缓存数据。使用分布式锁。当业务线程在处理请求时，如果发现访问的数据不在缓存中时，就增加一个分布式锁，然后该业务线程去加载缓存，其他线程由于获取不到分布式锁会被阻塞。二、Redis服务宕机使用Redis集群。采用Redis集群架构，即使某

回答所谓“热key”是指短时间内被大量访问的某个key。热key问题则是指某个key被大量访问，导致Redis服务压力过大，从而压垮Redis服务的情况。与大key问题相似，解决热key一般分为两个步骤：发现热key发现热key的方式有多种。提前预知。例如在做商品秒杀的时候，很容易就能判断这些参与秒杀的商品的key就是热key。在客户端收集。在访问Redis之前，加一个统计，统计访问key的访问次数，若某个key短时间的访问量大幅度增加，那么该key就是热key。使用Proxy层做收集。在应用程序和Redis之间再增加一次Proxy作为应用程序访问Redis的统一入口，由它来负责key的访问统计。使用Redis自带命令。Redis4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。使用开源。例如京东开源的jd-hotkey，是一款高

回答当Redis主节点被标注客观下线后，Sentinel会选举出一个Leader来完成故障转移。主要分为如下几个步骤。一、选择新的主节点在执行故障转移过程中，首先需要从从节点中选择出来一个合适的节点当做主节点。选择的标准可以参考下面这篇文章。Sentinel如何选择出新的master?二、晋升主节点当选出最合适的从节点后，Sentinel会向该节点发送SLAVEOFNOONE命令来让它晋升为新的主节点。三、配置更新当从节点晋升为主节点后，Sentinel会更新其它从节点的配置，让它们开始复制新的主节点，命令为：SLAVEOF<new-master-ip><new-master-port>。四、通知客户端和其他Sentinel故障转移完成后，领导者Sentinel会通知其他Sentinel节点新的主节点信息，确保整个Sentinel系统的信息是一致的。当旧的主节点恢复

回答Sentinel发现master节点客观下线后，会自动开启故障转移流程，选择一个合适的Slave节点晋升为新的Master。这个过程分为筛选备选节点和选择Master两个步骤。一、使用如下条件筛选备选节点Slave节点状态处于S_DOWN、O_DOWN、DISCONNECTED的除外。最近一次ping应答时间不超过5倍ping的间隔。假如ping的间隔为1秒，则最近一次应答延迟不应超过5秒。info_refresh应答不超过3倍info_refresh的间隔。Slave节点与Master节点失去联系的时间不能超过（(now-master->s_down_since_time)+(master->down_after_period*10)）。slave_priority不等于0。这个值在配置文件中指定，默认为100。二、从备选节点中按照如下顺序选择新的Master较低的sla

回答一旦确认主节点客观下线，就需要进行故障转移。这个时候各个Sentinel之间会进行一次选举，选出一个领导者来负责这次的故障转移流程。Sentinel之间通过发送RAFT的投票协议消息来选举领导者。每个Sentinel节点都会给某一个请求它进行投票的Sentinel节点投票，但在整个选举过程中，每个Sentinel只能投一次票。通常情况下，第一个请求投票的Sentinel会获得同意。如果某个Sentinel节点发现自己得到的票数已经超过半数且超过<quorum>，那么它就成为领导者。如果这个过程中有多个Sentinel成为领导者，那么将等待一段时间重新进行选择，直到有且只有一个Sentinel节点成为领导者为止。扩展假如有A、B、C、D四个节点构成Sentinel集群。假如A率先完成客观下线，则A会向B、C、D发出成为领导者的申请，由于B、C、D没有同意过其他Sentinel

回答每个Sentinel节点每隔一秒就会向Redis节点发送PING命令，已确认节点是否在线。若一个Sentinel节点在规定时间内（默认是sentineldown-after-milliseconds配置项指定的时间）没有收到被监控Redis节点的响应，它会将该节点标记为主观下线（SDOWN），即该Sentinel节点认为这个Redis节点不可达。当一个Redis节点被标注为主观下线后，由于主观下线是一家之言，会存在误判的情况，所以该Sentinel会向其他Sentinel对该Redis节点的看法，如果超过一定数量（quorum）的Sentinel都认为该Redis节点不可达，那么该节点会被标记为客观下线（ODOWN），这是一个全局共识，意味着多数Sentinel认为该节点确实出现了问题。扩展主观下线主观下线（SDOWN）是指单个Sentinel根据自身的监控结果认为某个Redis节点（

回答Sentinel（哨兵）是运行在特殊模式下的Redis服务器。它不支持读写操作，主要作用是配合Redis的主从复制功能，实现对主从节点的监控、对下线的主节点进行故障转移和通知。Sentinel主要有如下几个功能：监控：Sentinel会监控所有Redis节点的状态。自动故障转移：如果Redis主节点无法正常工作，Sentinel可以自动将这个主节点下的一个从节点升级为新的主节点，并让其他从节点指向这个新的主节点。通知：当Sentinel选举了新的主节点后，可以通过API向客户端进行通知。配置提供者：客户端在初始化时，通过连接Sentinel来获得当前Redis服务的主节点地址。监控和自动故障转移使得Sentinel能够完成主节点故障发现和自动转移，配置提供者和通知则是实现通知客户端主节点变更的关键。扩展Sentinel的架构在Sentinel的架构中，一般包含两个部分：多个Sentin

回答Redis提供了两种持久化方式：RDB和AOF，两种持久化方式对过期键的处理方式不一样。RDB对过期键的处理RDB是Redis内存的快照，它保存Redis在某一时刻的数据状态。当在进行RDB持久化时，Redis会遍历所有键的过期时间，并且不会将已经过期的键写入到RDB文件中。因此，在RDB文件中，不包含过期的键。当Redis从RDB文件恢复时，它加载的数据是快照时刻的有效数据集，不包含过期数据。AOF对过期键的处理对于过期键，AOF的处理方式是：如果Redis中的某个键过期了没有被删除，AOF文件不会有任何影响。当过期键被删除后（惰性删除和定期删除），AOF文件后会增加一个DEL命令，记录该记录已被删除了。在AOF重写过程中，Redis会检查所有键的过期时间，它不会将已经过期的键重新写入新的AOF文件中。<<<<<<更多阅读Redis主从模式中，对过

回答这里要分为主节点和从节点两个部分介绍。主节点对过期键的处理Redis主节点对过期键的处理采用一种“延迟释放”的策略，当key过期后，它的内存并不一定会立刻释放，而是等待合适的机会再释放。这种“延迟释放”的策略，Redis有两种方案：惰性删除：当你尝试访问一个Key时，Redis会首先检查这个Key是否过期，如果过期则返回null并删除它，如果没有过期则返回数据。定期删除：Redis每隔一段时间随机抽取一部分过期数据，然后删除这些过期数据。Rediskey过期了，为什么内存没释放呢？从节点对过期键的处理在主从架构中，从节点对过期键的处理会有一点特殊。从节点上key的过期时间和主节点保持一致，但即便key已过期，从节点也不会主动地去删除这些过期的key，而是通过同步主节点的删除操作来进行。无论主节点是通过惰性删除还是定期删除，这个删除操作会被记录在主节点的AOF文件中（如果已开启AOF），