前言

前文介绍了redis入门知识，接下来我们继续深入介绍redis集群以及高可用相关知识，并补充我在工作中的一些经验。

redis高级面试题合集

1. redis数据结构的底层实现方案？

Redis的数据结构底层实现主要依赖于一种称为"简单动态字符串"（Simple Dynamic String，SDS）、“字典”（也称为哈希表）、“跳跃表”（Skiplist）、“整数集合”（Intset）、“压缩列表”（Ziplist）等自定义数据结构，以及C语言中的数组和链表等基础数据结构。以下是这些数据结构在Redis中的使用：
简单动态字符串（SDS）：Redis没有直接使用C语言传统的字符串表示（以空字符结尾的字符数组），而是自己构建了一种名为简单动态字符串（SDS）的抽象类型，用于表示所有的字符串值。相比于C语言的字符串，SDS具有自动分配和释放内存、二进制安全、预分配空间减少内存分配次数等优点。
字典（哈希表）：Redis的字典相当于Java语言中的HashMap，它是无序字典，内部实现为哈希表，对添加、删除、查找操作的时间复杂度都是O(1)。Redis使用字典作为哈希类型（Hash）的底层实现之一，当哈希类型元素个数不多且元素值不大时，Redis使用压缩列表作为底层实现。
跳跃表（Skiplist）：跳跃表是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。Redis使用跳跃表作为有序集合（Zset）和集合（Set）类型的底层实现之一，当有序集合或集合的元素数量较多或者元素值较大时，Redis会使用跳跃表作为底层实现。
整数集合（Intset）：当一个集合类型的元素都是整数，并且数量不多的时候，Redis就使用整数集合作为内部实现。整数集合（intset）是紧凑的数组结构，同时支持16位、32位和64位整数，并且会根据实际元素的大小进行自动升级。
压缩列表（Ziplist）：压缩列表是Redis为了节约内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点（每个节点可以保存一个字节数组或者一个整数值），每个节点可以保存一个长度小于64字节的字节数组或者一个绝对值小于64的整数。
以上这些数据结构的选择和使用，使得Redis在性能和内存使用上达到了一个很好的平衡。

2. 什么是redis cluster？

Redis Cluster是Redis的分布式解决方案，它在Redis 3.0版本中正式推出，用于解决Redis在分布式方面的需求。Redis Cluster的主要目标是提供高性能、高可用性和线性可扩展性。
在Redis Cluster中，数据被自动分片，每个节点负责一定数量的槽（slot）。每个键值对都会映射到一个具体的槽上，这样就可以找到数据具体保存在哪个节点上了。同时，当集群中的一部分节点失效或者无法进行通讯时，仍然可以继续处理命令请求，并且具有自动故障转移的能力。
Redis Cluster采用虚拟槽分区，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，即槽。每个节点都会负责一定数量的槽，当数据被插入到Redis Cluster时，会根据键的哈希值找到对应的槽，然后由槽所在的节点来保存这个数据。
Redis Cluster还提供了多种配置和策略来优化性能和可靠性，例如可以通过配置save和bgsave命令来控制RDB持久化的频率和触发条件，通过配置appendfsync选项来控制AOF持久化的方式等。
总的来说，Redis Cluster是为了解决Redis在分布式方面的需求而设计的，通过数据分片、自动故障转移等技术，保证了高性能、高可用性和线性可扩展性。

3. redis如何保障高可用，如何监控集群，故障后如何快速恢复？

Redis保障高可用的方式主要有主从复制、哨兵和集群部署。
主从复制：主节点负责写操作，从节点负责读取和同步主节点的数据。一旦主节点发生故障，可以快速切换到从节点，提供读写服务，实现故障转移。
哨兵：Redis Sentinel是一个监控和自动故障恢复系统，可以监视Redis主从节点的健康状况。当主节点发生故障时，Sentinel可以自动检测并启动故障转移过程**，选择一个从节点升级为新的主节点，确保系统的持续可用性**。
集群：Redis Cluster是一种分布式Redis解决方案，它将数据分片存储在多个节点上，并自动管理节点间的数据分布和故障转移。集群提供了高可用性和扩展性，允许在集群中添加或删除节点而不会影响整个系统的可用性。
监控Redis集群可以使用Redis自带的命令或第三方工具，例如redis-cli、redis-sentinel、redis-top等。这些工具可以查看Redis节点的状态、内存使用情况、网络延迟等关键指标，帮助管理员及时发现问题并采取行动。
故障恢复策略包括主从切换、故障节点恢复和数据同步等。具体来说，如果主节点发生故障，可以通过自动或手动的方式将一个从节点升级为新的主节点，并更新其他从节点和应用程序的配置，使它们指向新的主节点。对于故障节点恢复，可以使用Redis自带的故障恢复工具或外部工具进行数据恢复。数据同步可以采用RDB快照或AOF日志文件进行数据恢复。
此外，定期对Redis数据库进行备份是一种常见的高可用性策略。备份数据可以在主节点故障时用于恢复。备份可以通过使用Redis自带的BGSAVE命令或外部工具来实现。
综上所述，通过部署不同的架构模式、监控和警报系统以及定义有效的故障恢复策略，Redis可以提供高可用性的服务。

4. 如何防范和优化大key？

识别大key：通过使用Redis的命令或一些开源工具来帮助我们找到这些大key。例如，可以使用Redis的MEMORY USAGE命令来获取key的内存使用情况，或者使用第三方工具如redis-cli的keys命令结合正则表达式来找出占用空间较大的key。
优化大key：如果发现有大key，需要对其进行优化。优化大key的方法有很多种，例如拆分大key、使用更有效的数据结构、设置过期时间、异步删除等。具体选择哪种方法取决于应用的具体需求和场景。例如，如果一个大key是一个列表或集合，可以考虑将其拆分为多个小的列表或集合，以提高性能和可扩展性。
控制数据大小：对于字符串类型的数据，可以将其控制在10KB以内；对于hash、list、set、zset等元素，尽量不超过5000个元素。这样可以有效减少内存占用和提高Redis的性能。
监控和告警：配置节点级别的入网最大带宽、出网最大带宽、CPU利用率等监控指标的告警。如果某个节点存在热key，这个节点的带宽占用、CPU利用率等指标都会比其他节点高，此时该节点容易触发告警，便于用户发现潜在的热key。
避免热点key：在设计Redis Key时，应尽量避免热点Key的产生。可以通过哈希分片、读写分离等策略来实现。例如，可以将一个大的列表或集合分成多个小的列表或集合，每个小的列表或集合部署在不同的Redis节点上，从而避免单一节点上的热点问题。
总之，防范和优化大key是Redis使用中一个重要的性能优化点。通过合理设计数据结构、使用缓存淘汰机制、使用读写分离、分片集群部署等策略，可以有效解决和预防大key问题，从而提高Redis的稳定性和性能。

5. 如何应对热点数据？

在Redis中，热key（hot key）是指被频繁访问的某个key。由于Redis是单线程模型，大量的请求集中在一个热key上可能导致性能问题，甚至可能导致Redis服务器宕机。热key产生的原因有很多，例如缓存击穿、数据结构选择不当、热点数据等**。识别热key可以通过客户端收集统计、Proxy层收集统计、使用Redis自带命令或工具等方法实现**。解决热key问题的方法包括本地缓存、合理设计数据结构、使用缓存淘汰机制、使用读写分离、分片集群部署等。

6. 介绍一下redis分布式锁的实现方案？

分布式锁的实现原理是利用Redis的原子操作来控制对共享资源的访问，以避免多个系统或进程同时访问和修改同一资源，导致数据不一致的问题。
在Redis中，可以使用SETNX（SET if Not eXists）命令来实现分布式锁。SETNX命令用于设置一个键的值，如果该键不存在，则设置成功，返回1；如果键已经存在，则设置失败，返回0。利用这个特性，可以让多个系统或进程在获取锁时都执行SETNX命令，只有第一个成功获取到锁的进程才能执行共享资源的操作，其他进程需要等待获取锁。
为了保证分布式锁的安全性和可靠性，可以采取以下几个措施：
互斥性：确保在同一时间只有一个客户端能够持有锁。Redis的SETNX命令本身就具有互斥性，即同一时间只有一个客户端能够成功获取到锁。
锁超时：为了避免死锁和资源永久性占用，可以为锁设置一个超时时间。当锁的持有时间超过设定的超时时间后，锁自动失效，其他客户端可以获取锁。
锁续期：在获取到锁后，客户端需要定期向Redis服务器发送心跳保持锁的有效性。如果客户端因为异常崩溃而未能及时释放锁****，其他客户端会因为无法获取到锁而等待超时。为了避免这种情况发生**，可以为锁设置一个续期时间，当客户端发送的心跳超时后，锁自动失效。
锁的释放：当客户端完成共享资源的操作后，需要显式地释放锁。如果客户端在完成操作后未能释放锁，会导致其他客户端无法获取到锁，造成死锁。因此，客户端在获取到锁后一定要记得在操作完成后释放锁。
容错性：如果Redis服务器出现故障或网络延迟等问题导致客户端未能获取到锁，客户端应该有一定的容错机制来处理这种情况。例如，可以重试获取锁的操作或者等待一段时间后再尝试获取。
持久化：为了防止Redis服务器崩溃导致锁丢失，可以开启Redis的持久化功能（如RDB或AOF持久化），将数据定期持久化到磁盘中。这样即使Redis服务器崩溃，数据也不会丢失。
通过以上措施可以保证分布式锁的安全性和可靠性**，避免多个系统或进程同时访问和修改同一资源导致的数据不一致问题。

7. 在分布式环境下，如何解决Redis的数据一致性问题？

主从复制：Redis支持主从复制功能，一个主节点可以有多个从节点。主节点将数据写入操作同步给从节点，从而保证主从节点数据一致。通过配置和部署合理的复制策略，可以实现数据的冗余备份和故障转移。
事务处理：Redis支持事务操作，可以将多个命令打包在一起执行，保证原子性。事务可以用来处理多个相关操作，确保数据一致性。通过合理使用事务，可以避免在分布式环境下出现数据不一致的问题。
分布式锁：通过使用分布式锁，可以实现对多个节点的互斥访问，避免并发竞争导致的数据不一致问题。Redis提供的SETNX命令可以用于实现分布式锁，通过锁的机制来保证数据操作的原子性和一致性。
数据分片：将数据分散存储在多个节点上，每个节点只负责一部分数据。通过合理的数据分片策略，可以避免单点故障和数据一致性问题。同时，通过分片可以提高系统的可扩展性和性能。
哈希槽分配：Redis Cluster将数据分散存储在多个节点上，每个节点负责一部分哈希槽。通过哈希槽的分配算法，可以保证相同的键始终映射到同一个节点上，从而保证数据的一致性。
**数据校验和检查：**定期进行数据校验和检查，确保数据的完整性和一致性。可以使用Redis提供的命令或工具来检查数据的完整性和一致性。

8. 如何处理Redis的缓存击穿和缓存雪崩问题？

保持缓存层的高可用性：使用Redis哨兵模式或者Redis集群部署方式，即使个别Redis节点下线，整个缓存层依然可以使用。此外，可以在多个机房部署Redis，这样即便机房死机，依然可以实现缓存层的高可用。
限流降级组件：无论是缓存层还是存储层都会有出错的概率，可以将它们视为资源。在高并发系统中，推荐服务中如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成整个推荐服务不可用。
缓存不过期：Redis中保存的key永不失效，这样就不会出现大量缓存同时失效的问题，但随之而来的是Redis需要更多的存储空间。
优化缓存过期时间：设计缓存时，为每一个key选择合适的过期时间，避免大量的key在同一时刻同时失效，造成缓存雪崩。可以采取一些策略来分散缓存失效的时间，例如在原有的失效时间基础上增加一个随机值，例如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，降低集体失效的事件发生概率。
使用互斥锁重建缓存：在高并发场景下，为了避免大量的请求同时到达存储层查询数据、重建缓存，可以使用互斥锁控制。根据key去缓存层查询数据，当缓存层为命中时，对key加锁，然后从存储层查询数据，将数据写入缓存层，最后释放锁。若其他线程发现获取锁失败，则让线程休眠一段时间后重试。
空结果进行缓存：对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，可以考虑将空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

9. 设计一个缓存架构？

我们针对电商场景中常用的商品详情页来进行设计。商品详情页涉及商品数据、类目数据、图片视频、价格、营销氛围、图文详情、推荐等。整个调用链路涉及多方数据，如何保障各节点的响应速度以及高可用至关重要。我们可以在调用外部数据的rpc层进行抽象：预定义是否缓存、缓存key、缓存val、缓存超时等抽象方法，由模板进行统一管理，在实现层编码具体的逻辑。这样我们就通过模板方法规范了缓存架构，并在某些场景下进行部分能力的降级、兜底等。

10. 在工作中遇到过哪些问题？

在某场景下使用redis中的List结构，由于内部封装限制了List的size为1000，所以在封装方法时直接配置了1000，这样每次List查询都会扫描 1000的数据。在某次上游接口压测时，缓存缓冲区打满，导致分片不均部分CPU达到100。好在有降级方案，及时切换了redis保障了服务可用性。
总结：在平时的使用中，在考虑采用某种结构时要考虑底层实现方式、数据大小（防止大key）、配置是否合理、是否会有性能问题、以及降级方案等