1.4 数据存储
1、Redis 的数据过期策略是什么？
Redis的数据过期策略包括两种机制：被动删除和主动删除。
-
被动删除：
- 当某个键被访问时，如果发现这个键已经过期，Redis会立即删除这个键。这意味着如果一个过期的键从未被访问，它就不会被自动删除。这是一种惰性删除策略。
-
主动删除：
- Redis会定期随机测试一些键的过期时间。如果发现某些键已经过期，它就会删除这些键。这个过程是在Redis的定时任务中进行的，通常称为过期键扫描。
过期键扫描的具体步骤：
- Redis每隔一段时间执行一次过期扫描任务，它会随机抽查一些键，并检查它们是否过期。
- 如果抽查中发现超过25%的键已经过期，Redis会立即再次抽查。
- 这个过程会重复执行，直到过期键的比例降到25%以下。
这种组合策略有助于保持Redis内存的使用效率，避免大量过期键占用内存，但同时也不会因为删除操作而造成服务器性能的显著下降。
另外，当内存不足时，Redis还可以配置使用volatile-*或allkeys-*等淘汰策略来删除键，以释放内存，这些策略和键过期是分开的，但在管理内存方面发挥着互补作用。
volatile-或allkeys-
在Redis中，当使用的内存超过了为Redis配置的最大内存限制时，Redis会触发数据淘汰策略来释放内存。volatile-*和allkeys-*是两类不同的数据淘汰策略，它们定义了当内存不足时Redis如何选择和淘汰数据。
这些策略可以在Redis的配置文件中设置，或者通过CONFIG SET命令动态设置。
-
volatile-* 策略：
- 这些策略只会考虑那些设置了过期时间的键（也就是说，它们是"易失性"的）。
- volatile-lru：从已设置过期时间的键中使用近似最近最少使用算法（LRU）淘汰数据。
- volatile-ttl：从已设置过期时间的键中淘汰那些剩余时间（TTL）最短的键。
- volatile-random：随机淘汰已设置过期时间的键。
-
allkeys-* 策略：
- 这些策略会考虑所有的键，不论它们是否设置了过期时间。
- allkeys-lru：从所有的键中使用近似最近最少使用算法（LRU）淘汰数据。
- allkeys-random：从所有的键中随机淘汰数据。
- no-eviction：不淘汰任何数据，如果内存不足，对于写操作会返回错误。
在这些策略中，"LRU"算法试图淘汰那些最近最少被访问的键，而"TTL"算法淘汰的是那些即将到期的键。"Random"算法则是完全随机选择键来淘汰。
选择哪种淘汰策略取决于你的应用场景和你希望如何处理内存压力。通常来说，如果你的应用可以接受偶尔的随机数据丢失，使用“allkeys-lru”可以帮助你保持Redis性能；如果你希望只有那些设置了过期时间的数据在内存不足时被淘汰，那么使用“volatile-lru”可能更适合你。
2、持久化文件对过期策略的处理？Redis 有哪些内存淘汰机制？
Redis通过maxmemory配置指令处理持久化文件及过期键的驱逐策略，该指令限制数据集的内存使用量。当达到内存限制时，Redis会根据maxmemory-policy配置指令确定的行为来执行。可用的驱逐策略包括：
- noeviction：达到内存限制时，不再接受新的写操作。
- allkeys-lru：淘汰最近最少使用的键。
- allkeys-lfu：淘汰最不经常使用的键。
- volatile-lru：淘汰具有过期设置的最近最少使用的键。
- volatile-lfu：淘汰具有过期设置的最不经常使用的键。
- allkeys-random：随机淘汰键以腾出空间。
- volatile-random：随机淘汰具有过期设置的键。
- volatile-ttl：淘汰具有最短剩余生存时间(TTL)且有过期设置的键。
这些策略可以在运行时设置和修改，可以通过Redis的监控命令来监控它们的性能。
4、Redis 有哪些持久化机制？
Redis 是一种内存数据库，它的数据都是存储在内存中的。为了避免数据丢失，Redis 提供了多种持久化机制来将数据保存到磁盘中。
以下是 Redis 提供的两种主要的持久化机制：
-
RDB（Redis DataBase）：RDB 是 Redis 的默认持久化机制，它会定期将 Redis 中的数据以二进制文件的形式保存到磁盘中。RDB 文件是一个经过压缩的二进制文件，其中包含了 Redis 中所有键值对的序列化数据。
-
AOF（Append Only File）：AOF 是另一种持久化机制，它会将 Redis 执行的每一个写操作都记录到一个 Append Only File 中。当 Redis 重启时，它会读取 AOF 文件并重新执行其中的写操作，从而恢复数据。
除了以上两种主要的持久化机制外，Redis 还提供了其他一些辅助的持久化机制，例如：
- 复制（Replication）：Redis 支持主从复制，即可以将主节点的数据复制到多个从节点中。这样可以在主节点发生故障时，从节点可以提供备份数据。
- 哨兵（Sentinel）：哨兵是 Redis 的高可用解决方案，它可以监控 Redis 主节点的状态，并在主节点发生故障时自动切换到从节点。
5、RDB v.s. AOF
Redis的RDB（快照）和AOF（追加文件）是两种主要的数据持久化机制：
-
RDB：通过定期创建数据集的快照来进行持久化。在
redis.conf配置文件中可以设置快照的创建条件，如save 60 10000意味着至少有10000个键被改变且60秒已过去时，Redis将创建一个快照。 -
AOF：记录每个写操作命令，并在服务器重启时通过重放这些命令来重建数据集。在
redis.conf文件中，可以通过appendonly yes来开启AOF，以及通过appendfsync指令来设置同步的频率。
何时需要持久化：
- 如果你需要在服务器重启后还能恢复数据，就需要持久化。
- 如果你的数据更新非常频繁，或者说数据丢失的代价非常高，推荐使用AOF。
- 如果你可以接受短时间内的数据丢失，可以只使用RDB。
性能比较：
- RDB的性能通常比AOF好，因为它是周期性的，对实时性能影响较小。
- AOF可能会因为频繁的磁盘写操作而降低性能，但可以通过调整
appendfsync的策略来优化。
举例 1：
- 在一个需要保证数据不丢失的电商平台上，可以启用AOF持久化，并设置为每秒同步一次，以确保即使在系统崩溃的情况下，也只会丢失一秒钟的数据。
- 对于一个内容发布系统，其中的数据更新不是非常频繁，可以使用RDB持久化来减少对性能的影响，同时也能保证数据的安全性。
举例 2：
假设有一个实时数据分析系统，需要频繁地写入大量的数据，并需要快速地读取数据进行分析。在这种情况下，RDB 可能是更好的选择，因为它可以定期将数据保存到磁盘中，同时可以快速地恢复数据。如果数据的完整性要求较高，可以考虑使用 AOF 进行备份，以保证数据不会丢失。
另一个例子是一个需要保存用户操作记录的系统。在这种情况下，AOF 可能是更好的选择，因为它可以将每次用户的操作都记录到磁盘中，以便在需要时进行审计或恢复。同时，由于用户操作记录相对较少，因此 AOF 的性能影响可能相对较小。
RDB 和 AOF会把数据写到哪里？在哪里设置，如何恢复数据？
Re
