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