Redis ⽣产问题

什么是缓存穿透？怎么解决？

缓存穿透是指用户发起大量的请求，而这些请求所涉及的数据在缓存中并不存在，因此每次请求都会穿透缓存直接到数据库中进行查询。当这种现象达到一定规模时，会对数据库造成极大的压力，可能导致数据库崩溃，严重影响系统的稳定性和性能。

解决缓存穿透的方法主要有以下两种：

缓存无效 key：为了解决这个问题，可以在查询数据库时，无论数据是否存在，都将这个 key 及其对应的结果（比如空值或者特定标记）写入缓存，并设置一个较短的过期时间。这样即使下次同样的请求过来，也能从缓存中获取结果，避免了对数据库的直接访问。
布隆过滤器（Bloom Filter）：布隆过滤器是一种空间效率极高的概率型数据结构，用于判断一个元素是否在一个集合中。对于大量可能不存在的 key 查询，我们可以先通过布隆过滤器进行校验，如果布隆过滤器判断某个 key 一定不存在，则直接返回；如果布隆过滤器判断可能存在，则再继续去缓存或数据库中查找。虽然布隆过滤器存在一定的误判率（可能会将存在的 key 判定为不存在），但是对于防止缓存穿透而言，已经能够起到很好的效果。

什么是缓存雪崩？怎么解决？

缓存雪崩是指缓存系统在某一时刻大面积地失效或者宕机，导致所有原本应该由缓存处理的请求瞬间全部涌向数据库，从而使得数据库压力剧增，可能会导致数据库崩溃，服务无法正常提供。

解决缓存雪崩问题可以采用以下策略：

Redis集群：通过构建Redis集群，实现主从复制、读写分离以及分布式缓存，即使某台服务器出现问题，其他服务器仍能保证缓存服务的可用性，从而避免单点故障导致的雪崩效应。
缓存失效隔离：在设计缓存过期时间时，尽量避免让所有缓存在同一时间失效。例如，可以给每个缓存对象加上一个随机的过期时间偏差，或者采用定期刷新策略而非固定过期策略。
限流降级：当检测到数据库请求压力过大时，可以通过熔断机制暂时拒绝部分非核心业务的请求，保护数据库不受冲击。同时，可以使用如Hystrix等工具实现服务降级和流量控制。
预加载/缓存重建：在缓存失效前，提前重新加载新的缓存，或者在缓存失效时，采用异步方式重建缓存，确保数据库不会因为短时间内大量请求而瘫痪。
备份冗余：建立备用缓存实例或系统，一旦主缓存发生问题，可以迅速切换至备用系统，保证服务连续性。
合理的缓存更新策略：比如可以采用LRU(最近最少使用)替换策略，结合缓存依赖更新，而不是简单粗暴的一次性大面积失效。

主从复制、读写分离以及分布式缓存

主从复制（Master-Slave Replication）：在Redis中，主从复制是一种数据同步策略。在一个Redis实例集群中，一个Redis节点作为主节点（Master），负责接收所有的写操作请求，其他的节点作为从节点（Slave）。主节点会把接收到的所有数据更改（包括写操作）以日志的形式发送给从节点，从节点再根据这些日志信息对自身数据进行更新，从而实现主从之间的数据同步。这样一来，从节点就可以用来处理读请求，分散主节点的压力，同时也提高了系统的容错性，如果主节点出现故障，可以从已同步的从节点中选举出一个新的主节点。
读写分离（Read/Write Splitting）：读写分离是数据库架构优化的一种常见手段。在Redis场景下，通常结合主从复制实现。主节点负责处理所有的写操作，保持数据的最新状态；从节点则负责处理读操作。这样做的好处是可以提高系统的并发能力，因为写操作往往比读操作更消耗资源，且容易产生锁竞争。同时，多个从节点可以横向扩展读取能力，减轻数据库的压力。
分布式缓存（Distributed Caching）：分布式缓存是指将缓存系统部署在多台机器上，形成一个整体对外提供服务。在Redis中，常见的分布式缓存方案有Redis Cluster和客户端分片（如Codis、Twemproxy等）。
- Redis Cluster：Redis原生支持的分布式解决方案，它将数据按照slot（槽）分配到不同的Redis节点上，客户端可以直接与任意Redis节点通信，节点会自动转发请求到正确的节点上。Redis Cluster支持数据分片和高可用性，每个槽都有一个主节点和至少一个从节点，当主节点不可用时，可以自动切换到从节点。
- 客户端分片：客户端在发送请求之前，根据某种规则（如一致性哈希）决定请求应该发往哪个Redis实例，从而实现数据的分布式存储。这种方式下，客户端需要承担更多的逻辑，但提供了更高的灵活性。

单点故障

单点故障（Single Point of Failure，SPOF）是指在系统架构中，如果某个组件或节点发生故障，会导致整个系统或关键服务无法正常运行的情况。换句话说，就是系统过于依赖某个单一的组件，这个组件一旦出现故障，就会引发连锁反应，导致整个系统的服务质量严重下降甚至完全瘫痪。

在分布式系统和云计算环境中，单点故障是一个必须要重视和避免的问题。例如，在使用Redis作为缓存服务时，如果只有一台Redis服务器，那么这台服务器就构成了单点故障。一旦这台服务器由于硬件损坏、软件错误、网络中断等原因无法提供服务，整个缓存系统就失效了，所有原本应该由缓存处理的请求会全部涌向后端数据库，可能造成数据库负载过高甚至崩溃。

为了避免单点故障，通常采取以下策略：

冗余备份：配置多个相同功能的组件或节点，如在Redis中采用主从复制或多副本的方式，当主节点出现故障时，可以从从节点或备份节点中快速切换，维持服务的连续性。
集群化部署：例如使用Redis Cluster，将数据和服务分布在多个节点上，即使部分节点故障，剩余节点仍能继续提供服务。
负载均衡：通过负载均衡器将请求均匀地分布到各个节点，即使个别节点出现故障，也可以快速剔除故障节点，将流量引向健康节点。
分区和分布式处理：将数据和服务进行水平拆分，分别部署在不同节点或集群上，降低单个组件的重要性。
高可用架构设计：例如使用ZooKeeper、etcd等组件进行服务注册与发现，及时感知和应对单点故障。

如何保证缓存和数据库数据的⼀致性？

直写数据库，缓存失效（Cache Aside Pattern） 这是最常见的缓存策略。首先尝试从缓存中读取数据，如果缓存命中，则直接返回；如果缓存未命中，则查询数据库并将查询结果写入缓存。当数据发生更新时，先更新数据库，然后使缓存失效，后续请求再次触发缓存重建。这种方法不能保证强一致性，但在大多数情况下能满足最终一致性要求。
先更新数据库，再删除缓存（Write Through Pattern） 当数据需要更新时，先更新数据库，更新成功后再删除对应的缓存项，使得后续请求会重新从数据库加载新数据到缓存。这种方法可以确保数据库与缓存数据最终一致，但仍然可能出现短暂的时间窗口内缓存与数据库数据不一致的情况。
先更新缓存，再更新数据库（Write Behind / Write Back Pattern） 当数据需要更新时，首先更新缓存，然后异步地将修改的数据同步到数据库。这种策略可以减少对数据库的访问压力，提高系统的响应速度，但是增加了数据不一致的风险，特别是在系统崩溃或其他异常情况发生时，可能造成缓存中有已更新的数据但还未持久化到数据库的问题。为了缓解这一问题，通常会在缓存中维护一个待同步队列，确保在系统重启后能够恢复未完成的同步任务。

在实际应用中，常常会结合使用这些策略，并引入额外的机制（如分布式事务、消息队列等）来进一步增强数据一致性保障。

Redis 集群

如何保证 Redis 服务⾼可⽤？

Redis Sentinel（哨兵）集群是用来监控和管理Redis主从集群的组件，它可以提供高可用性解决方案，确保Redis服务的稳定性和可靠性。以下是Redis Sentinel集群如何保证Redis服务高可用的主要方式：

监控Redis实例： Sentinel集群不断地监控Redis主从服务器的运行状态，包括它们的存活状态、是否能够正确响应命令请求等。一旦检测到主节点下线或者其他故障，Sentinel将会启动故障转移流程。
自动故障转移：当主节点不可达时，Sentinel集群能够自动进行故障转移操作，从现有的从节点中选举出一个新的主节点，并将其他从节点指向新的主节点。这个过程不需要人工干预，极大提升了Redis服务的可用性。
配置中心： Sentinel集群还作为一个配置中心，客户端连接到Sentinel获取当前Redis主节点的信息，当主节点发生变更时，Sentinel会通知客户端新的主节点位置，客户端可以据此动态调整连接目标。
主观下线与客观下线： Sentinel在判定节点是否下线时，采用了主观下线和客观下线两个阶段。主观下线是指单个Sentinel节点认为某个Redis节点不可达，客观下线则是多数Sentinel节点都确认该节点不可达，这样可以避免因网络波动等因素导致的误判。
故障恢复：当原主节点故障恢复后，Sentinel会将其设置为新的主节点的从节点，确保数据的完整性和一致性。

通过搭建Redis Sentinel集群，可以在无需人工干预的情况下，实现Redis服务的自动故障检测、自动故障转移和自动故障恢复，从而极大地提高了Redis服务的高可用性。

Sentinel（哨兵）有什么作⽤？

Redis Sentinel（哨兵）是一个分布式系统，主要用于监控Redis集群中各节点的运行状态，并在检测到故障时自动执行故障转移操作，从而保证Redis服务的高可用性和数据完整性。其主要作用包括：

监控Redis节点： Sentinel会持续监控Redis主从集群中的每一个节点，检查它们是否可达，是否能正常提供服务。监控内容包括但不限于节点的网络连通性、响应时间、角色（主节点还是从节点）等。
故障检测： Sentinel不仅能够实时监测Redis节点的状态，还能准确识别节点的故障情况，包括主观下线（单个Sentinel节点认为某个Redis节点不可达）和客观下线（多个Sentinel节点都认为某个Redis节点不可达）。当检测到节点故障时，Sentinel会立即作出反应。
自动故障转移：当主节点发生故障时，Sentinel集群会自动触发故障转移流程，从现有的从节点中选举出一个新的主节点，并将其他从节点指向新的主节点。整个故障转移过程是自动化的，无须人工干预。
配置提供者： Sentinel充当了Redis客户端与Redis集群之间的中间件，客户端可以通过询问Sentinel来获取当前主节点的信息。当主节点发生变更时，Sentinel会通知客户端新的主节点地址，客户端可以根据通知做出相应的连接调整。
系统恢复：当原来的主节点故障解除并重新上线时，Sentinel会将其设置为新主节点的从节点，从而实现系统的平滑恢复和数据的重新同步。

Redis 缓存的数据量太⼤怎么办?

当Redis缓存的数据量过大时，可能会遇到内存不足、单节点性能瓶颈等问题，此时可以考虑使用Redis Cluster来解决：

Redis Cluster是Redis官方提供的分布式解决方案，它将数据分散在多个Redis节点上，每个节点仅存储一部分数据，从而实现了水平扩展的能力。以下是使用Redis Cluster应对大容量缓存数据的具体措施：

数据分片（Sharding）： Redis Cluster通过数据分片技术，将数据分割成多个槽（Slot），并将这些槽均匀分配到多个Redis节点上。客户端在写入或查询数据时，通过CRC16算法计算键所属的槽位，并找到对应的Redis节点进行操作，从而有效地分散数据存储和访问的压力。
扩容缩容：随着数据量的增长，可以通过添加新的Redis节点加入Cluster，系统会自动重新分配部分槽到新节点上，实现在线扩容。同样，当数据量减少时，也可以通过迁移槽位的方式安全地移除节点，实现缩容。
高可用性：每个槽在Redis Cluster中都有一个主节点和零个或多个从节点，主节点负责处理槽位相关的读写请求，从节点负责同步主节点数据，以备主节点出现故障时能够快速切换。这种主从模式提供了高可用保障，降低了单点故障风险。
故障转移：当主节点发生故障时，Redis Cluster内部的Sentinel系统（虽然不同于独立的Redis Sentinel）会自动检测并触发故障转移，将从节点提升为主节点，确保服务的连续性。

通过上述措施，Redis Cluster能够在不影响服务的前提下，有效应对大规模缓存数据的存储需求，实现Redis的水平扩展和高可用性。

CRC16算法

CRC16（Cyclic Redundancy Check，循环冗余校验）是一种基于二进制位运算的校验码生成算法，广泛应用于数据传输和存储过程中校验数据完整性。在Redis Cluster中，CRC16算法用于对键（Key）进行哈希，确定该键所属的槽（Slot）编号，进而决定该键值对应该存储在哪个Redis节点上。

CRC16的基本原理是通过对输入数据（在这里是Redis的键）进行一系列的二进制位运算，生成一个16位的校验码。在Redis Cluster中，它将所有可能的键映射到0到16383（即2^14）范围内的槽编号上。这样，当需要确定一个键应该被存储在哪个节点时，首先通过CRC16算法计算出该键的哈希值，然后对该哈希值进行取模操作（对16384取模），得到的就是该键所在的槽编号。

举例来说，假设有一个键"example:key"，经过CRC16算法计算后得到一个16位的哈希值，对16384取模后得到具体的槽位号，从而确定这个键值对应该存储在拥有该槽位的Redis节点上。这样，通过CRC16算法进行数据分片，可以将大量数据均匀地分布到各个Redis节点，实现Redis Cluster的分布式存储和负载均衡。

Redis Cluster 虚拟槽分区有什么优点？

Redis Cluster采用虚拟槽分区（Virtual Slot Sharding）策略来管理数据分布，这种设计具有多个显著的优点：

动态扩容缩容：
- 虚拟槽分区使得Redis Cluster能够灵活地进行水平扩展。每个Redis节点负责一定数量的槽，当需要增加或减少节点时，只需将部分槽从已有节点迁移到新节点或者反之，而无需迁移全部数据，这极大地简化了集群的扩展过程。
数据均衡分布：
- Redis一共定义了16384个槽，键根据其CRC16哈希值被映射到不同的槽中。这样一来，数据在集群中的分布相对均匀，避免了单点过载的问题，实现了负载均衡。
高可用与容错性：
- 由于每个键只关联到特定的槽而不是特定的节点，当某个节点失效时，其负责的槽可以快速地被其他可用节点接管，从而保证了系统的高可用性。客户端可以通过查询集群元数据自动找到新的节点位置，实现故障转移。
解耦数据与节点：
- 通过虚拟槽的方式，数据与Redis节点之间不存在硬编码的关系，这意味着添加或移除节点不会影响数据的整体分布逻辑，增强了系统的可维护性和灵活性。
易于理解和操作：
- 对于开发者和运维人员而言，理解槽的概念比直接处理复杂的节点间数据迁移要直观得多，而且在进行集群操作时，如添加、删除节点或重新分配槽等，都有明确的操作流程和指导原则。

综上所述，Redis Cluster的虚拟槽分区机制有效地解决了大规模数据集下的分布式存储问题，同时大大提高了系统的扩展能力和容错能力。

Redis Cluster 中的各个节点是如何实现数据⼀致性的？

Redis Cluster中的各个节点并不直接采用强一致性协议（如Paxos或Raft）来保证数据一致性，而是通过一种叫做Gossip协议的成员传播协议来维护集群状态的一致性，以及在必要时通过主从复制机制来保证数据的最终一致性。

Gossip协议： Redis Cluster利用Gossip协议来进行节点间的信息交换，包括节点的加入、离开、故障状态变化等信息。每个节点周期性地与其他节点通讯，交换关于集群中其他节点的状态信息。这样，当某个节点发生故障或者新增节点时，整个集群可以迅速得知并作出相应调整，如进行故障转移、数据重分布等。
主从复制： Redis Cluster中每个主节点拥有若干从节点，主节点的数据会实时同步到从节点。当主节点发生故障时，集群会通过Gossip协议达成共识，选举一个从节点晋升为主节点，并重新分配故障主节点的槽至新的主节点。在这个过程中，虽然不是强一致性，但由于Redis数据结构的特性以及主从复制机制，可以实现最终一致性。
数据分区与分布式事务： Redis Cluster通过虚拟槽分区的方式来分配数据，确保每个键只会被映射到一个槽中，而每个槽只能被一个主节点持有。因此，涉及到跨槽的数据一致性问题较少，大部分操作都是针对单个主节点的。对于少量的跨槽事务，Redis Cluster暂不直接支持ACID事务，但可以通过Lua脚本等方式模拟分布式事务处理，确保数据在限定条件下的原子性和一致性。

总的来说，Redis Cluster通过Gossip协议来维护集群成员及角色状态的一致性，通过主从复制来保证单个槽内数据的最终一致性，结合数据分区策略，有效降低了实现数据一致性的复杂度和开销。

Redis八股（部分）