Redis 支持哪些数据结构？

字符串（string）：字符串是 Redis 最基本的数据结构，它可以是普通的字符串或者二进制数据，最大长度为512MB。 哈希（hash）：Redis哈希是一个键值对集合，其中键和值都是字符串类型。哈希适用于存储对象。 列表（list）：Redis列表是一个链表，每个节点都包含了一个字符串，列表支持正反两个方向的遍历。 集合（set）：Redis集合是字符串的无序集合，支持添加、删除、判断元素是否存在等基本操作，还支持交、并、差等操作。 有序集合（sorted set）：Redis有序集合和集合类似，区别在于集合中的元素可以关联一个分数（score），根据分数进行排序。

Redis 如何实现持久化？

RDB快照

RDB快照是一种将Redis在某个时间点上的数据生成一个快照文件的方式。快照文件保存的是Redis的数据在某个时间点上的副本，以二进制形式存储。RDB快照可以手动或者定时进行，也可以根据用户设定的规则进行自动备份。快照文件可以用于恢复Redis在快照文件生成时的数据。

优点

• RDB快照对于数据恢复来说非常快，因为它只需要将快照文件读入内存，就可以将Redis恢复到该时间点的状态。
• RDB快照生成的文件体积相对较小，因为它只保存了Redis在某个时间点上的数据副本。
• RDB快照不需要额外的磁盘空间来记录Redis的修改操作。

缺点

• RDB快照是间隔性的，如果在两个快照文件之间出现宕机或者断电等异常情况，Redis将会丢失这两个快照文件之间的数据。
• RDB快照在进行备份时，Redis的进程需要持续的写入磁盘，这样就会增加Redis的响应时间，可能会对性能产生影响。
• RDB快照只能恢复到最近的快照时刻，如果在快照生成后Redis出现了错误，那么快照中保存的数据可能已经过时了。

AOF日志

AOF（Append Only File）是一种以日志的形式记录Redis的写操作的持久化方式。每当Redis执行一个写操作时，都会将该操作写入AOF日志文件。AOF文件是一个文本文件，其内容为Redis执行的所有写操作命令。可以通过重放AOF文件来重新构建原来的数据集。

优点

• AOF日志是实时记录的，如果Redis宕机或者断电等异常情况发生，只要AOF文件中记录的操作已经被写入磁盘，就可以保证不会丢失数据。
• AOF日志可以配置同步频率，减小数据丢失的可能性。可以选择每次写操作都同步到磁盘，或者每秒同步一次。
• AOF日志文件内容是文本形式，可以通过文本编辑器来查看或修改内容，方便调试和维护。
• AOF日志文件是追加写入的，不需要进行复杂的磁盘IO操作，因此相对于RDB快照更加高效。
• AOF日志记录了Redis的所有写操作，可以根据AOF日志文件重放操作，恢复出

缺点：

• AOF日志方式的缺点在于AOF文件可能会变得很大，特别是在写入数据频繁的情况下，AOF文件会变得越来越大，占用越来越多的磁盘空间。此外，AOF文件重写（AOF rewrite）的过程比较耗时，并且需要足够的磁盘空间来存储临时文件。

Redis 的数据淘汰策略有哪些？如何选择合适的策略？

当Redis内存不足以容纳新数据时，需要采取一种数据淘汰策略来释放内存。Redis提供了几种不同的数据淘汰策略，以便根据实际应用场景和需求来选择合适的策略。

以下是Redis支持的数据淘汰策略：

1. noeviction（不删除）：这种策略下，当内存不足时，Redis不会删除任何数据。如果达到最大内存限制，任何写入数据的操作将会返回一个错误。这种策略适用于那些希望确保数据持久性并手动管理内存的场景。
2. allkeys-lru（Least Recently Used，最近最少使用）：在这种策略下，Redis会根据最近的访问频率删除数据。在需要释放内存时，Redis会从所有键中选择最近最少使用的键进行淘汰。这种策略适用于大多数场景，尤其是那些需要缓存数据并根据数据访问频率来决定淘汰顺序的应用。
3. volatile-lru（最近最少使用，只针对设置了过期时间的键）：与allkeys-lru类似，但仅针对设置了过期时间的键进行淘汰。这种策略适用于那些希望保留永久数据并仅根据访问频率淘汰具有过期时间的数据的场景。
4. allkeys-random（随机删除）：在这种策略下，Redis会在需要释放内存时从所有键中随机选择一个进行淘汰。这种策略可能导致一些重要但访问频率较低的数据被删除，因此在选择时需要谨慎。
5. volatile-random（随机删除，只针对设置了过期时间的键）：与allkeys-random类似，但仅针对设置了过期时间的键进行淘汰。这种策略适用于那些希望保留永久数据并随机淘汰具有过期时间的数据的场景。
6. volatile-ttl（根据TTL值淘汰，只针对设置了过期时间的键）：在这种策略下，Redis会根据键的剩余生存时间（TTL）进行淘汰。具有较短剩余生存时间的键将优先被淘汰。这种策略适用于那些希望基于数据的剩余生存时间来决定淘汰顺序的场景。

Redis 的缓存穿透和缓存雪崩是什么？如何解决？

缓存穿透

缓存穿透指的是查询一个不存在的数据，由于缓存和数据库都没有相应的数据，所以每次查询都会访问数据库，从而导致数据库压力过大。攻击者可以利用这一特性通过构造恶意的请求来使缓存失效，从而攻击后端数据库。

解决办法：

• 布隆过滤器：使用布隆过滤器过滤掉不存在的数据，从而减少对数据库的访问。
• 缓存空对象：将不存在的数据也缓存起来，存入缓存的空对象，这样在下次请求的时候就可以从缓存中取到这个空对象，避免对数据库的访问。
• 限流：对缓存穿透的恶意请求进行限流，限制其访问频率。

缓存雪崩

缓存雪崩指的是缓存中大量的数据同时过期，导致大量的请求直接到数据库查询，从而使数据库压力过大，甚至崩溃。

解决办法：

• 设置缓存失效时间的随机值，避免同一时间大量的数据失效，从而分散缓存的更新压力。
• 设置热点数据的缓存时间长一些，避免热点数据同时失效。
• 集群部署，将缓存分散到不同的节点上，降低单个节点的压力。
• 数据预热，将热点数据提前加载到缓存中，避免在大量请求到来时缓存未命中导致数据库压力过大。

可以参考：[如何实现高并发的商品缓存]()

Redis 的并发竞争问题是如何解决的？

Redis 的并发竞争问题主要是指多个客户端同时访问同一个 key 时可能发生的问题，包括数据的并发写入和读取，以及缓存热点的并发访问等。

为了解决这些问题，Redis 提供了以下的解决方案：

1. 使用事务：不推荐了。
2. 使用 Lua 脚本：Redis 支持执行 Lua 脚本，通过将多个命令打包成一个脚本，可以一次性将所有的命令发送到 Redis 服务端，减少竞争的概率。
3. 使用分布式锁：Redis 可以通过 SETNX、GETSET、EXPIRE 等命令来实现分布式锁。使用分布式锁可以将某个 key 的操作变为串行化，保证在同一时间只有一个客户端对该 key 进行操作。
4. 使用 Redisson：Redisson 是基于 Redis 实现的 Java 分布式应用程序的框架，提供了分布式对象、分布式锁、分布式集合等功能，可以方便地解决 Redis 的并发竞争问题。

Redis 的主从复制和哨兵模式是什么？有什么区别？

1. 主从复制是将一个节点的数据完全复制到另一个节点，这个被复制的节点就是主节点（Master），而接受数据复制的节点就是从节点（Slave）。主节点将自己的数据同步到从节点上，从节点只能读取数据，不能进行写入。
2. 哨兵模式则是将多个节点组成一个集群，其中一个节点作为主节点，其他节点作为从节点，当主节点故障时，哨兵模式会自动选举出一个从节点作为新的主节点，确保服务的高可用性。
3. 主从复制是一种简单的实现方式，适用于数据量不太大、数据量变化不频繁的情况。
4. 哨兵模式则适用于数据量比较大、需要高可用性的场景。哨兵模式还可以进行故障检测和自动切换，确保在主节点发生故障时能够快速切换到从节点。
5. 主从复制的配置比较简单，但在主节点发生故障时需要手动将从节点升级为主节点，需要手动介入。
6. 哨兵模式则能够自动检测主节点的状态，当主节点发生故障时能够自动进行切换，降低了管理的难度。

Redis 的红锁是什么？他是如何解决死锁的？

Redis的红锁（RedLock）是一种基于Redis的分布式锁算法，它可以在多个独立的Redis节点之间协调实现全局唯一的互斥锁。这种算法能够解决在分布式系统中出现的死锁问题。

红锁算法的基本原理如下：

1. 在实现红锁时，我们需要有N个独立的Redis节点（至少是3个），并且这些节点之间不需要进行任何形式的通信。这样可以降低单点故障风险和网络通信延迟对锁机制的影响。
2. 当客户端想要获取锁时，它需要向所有的Redis节点发送一个请求。这个请求包括锁的标识（key）、客户端生成的随机值（value）以及锁的有效期（TTL，Time To Live）。
3. 每个Redis节点在收到请求后，会尝试在本地设置这个锁。如果设置成功，节点会返回一个成功的响应。如果锁已经存在，节点会返回一个失败的响应。
4. 客户端需要收集所有Redis节点的响应。如果一定比例（通常是大于一半）的节点设置锁成功，客户端认为锁已经成功获取。否则，客户端会认为获取锁失败。
5. 如果客户端成功获取锁，它可以执行需要互斥保护的操作。在操作完成后，客户端需要向所有的Redis节点发送解锁请求。解锁请求中需要携带锁的标识和客户端生成的随机值。节点在收到解锁请求后，会校验锁的value是否与请求中的value一致。如果一致，则删除锁；如果不一致，则保持锁不变。这样可以避免误解锁。
6. 在锁的有效期内，如果客户端没有主动解锁，那么锁会自动过期。这样可以防止因客户端崩溃或其他原因导致的死锁。

红锁算法并不能提供强一致性保证，但对于许多实际应用场景，这种最终一致性的锁机制已经足够使用。

红锁算法可以有效地降低分布式环境中死锁的风险，但不能完全保证彻底解决死锁问题。这是因为它在设计上追求的是可用性和容错性，而不是强一致性。在一些极端情况下，红锁算法可能仍然会遇到死锁的问题。

例如，假设在一个由5个Redis节点组成的红锁环境中，客户端A成功地获取到了锁（在3个以上的节点上设置了锁）。在客户端A完成操作并试图解锁之前，由于网络分区或节点故障，部分节点与客户端失去了联系。此时，如果客户端B尝试获取锁，它可能在与客户端A没有失去联系的节点上成功地获取到锁。这种情况下，两个客户端都认为自己持有锁，从而可能导致死锁。

尽管红锁算法无法完全避免死锁，但在实际应用中，这种极端情况发生的概率是相对较低的。对于大多数应用场景来说，红锁算法提供的最终一致性以及容错性已经足够满足需求。然而，如果你的应用对一致性要求非常高，可能需要考虑其他的分布式锁实现方法，如基于分布式事务的锁、基于ZooKeeper的锁等。