架构师-redis内存淘汰机制
·
- no - eviction（不淘汰）
- 原理：
- 这是 Redis 内存淘汰机制中最 “保守” 的一种策略。当 Redis 使用的内存达到配置的最大内存限制（maxmemory）时，如果有新的数据需要写入，Redis 会直接返回错误，而不会删除任何现有的数据来为新数据腾出空间。
- 应用场景：
- 适用于对数据完整性要求极高的场景。例如，在一些金融交易系统的缓存应用中，数据的准确性和完整性至关重要。如果缓存的数据是交易记录或者关键的账户信息，为了避免任何数据丢失的风险，采用 no - eviction 策略可以确保即使内存不足，也不会丢失已经存储在 Redis 中的数据。
- 原理：
- allkeys - lru（Least Recently Used，所有键最近最少使用）
- 原理：
- 当 Redis 内存达到 maxmemory 时，会在所有的键（包括设置了过期时间和没有设置过期时间的键）中，选择最近最少使用的键进行删除。Redis 通过一个 LRU 算法的近似实现来跟踪键的访问时间。这个近似的 LRU 算法使用了一个双向链表和一个字典结构。每次访问一个键时，它会将这个键移动到双向链表的头部，表示这个键是最近使用过的。当需要删除键时，就从链表的尾部开始删除，因为尾部的键是最近最少使用的。
- 应用场景：
- 广泛应用于缓存系统。例如，在一个 Web 应用的页面缓存场景中，用户频繁访问的页面缓存会被保留，而那些长时间没有被访问的页面缓存对应的键会被优先删除，以腾出空间给新的页面缓存。这样可以保证缓存中存储的是用户最可能访问的页面，提高缓存的命中率和系统的整体性能。
- 原理：
- volatile - lru（设置过期时间的键中最近最少使用）
- 原理：
- 与 allkeys - lru 类似，但是它只在设置了过期时间的键中选择最近最少使用的键进行删除。Redis 同样使用 LRU 算法的近似实现来跟踪这些键的访问时间。当内存达到 maxmemory 且需要删除键来腾出空间时，只会考虑那些已经设置了过期时间的键，从这些键中选择最近最少使用的进行删除。
- 应用场景：
- 适用于同时存在有过期时间和无过期时间键的场景。比如在一个广告投放系统的缓存中，广告缓存数据通常会设置过期时间，而一些系统配置参数等键可能没有过期时间。采用 volatile - lru 策略，当内存紧张时，只会从广告缓存这些带有过期时间的键中选择最近最少使用的进行删除，而不会影响没有过期时间的系统配置参数等键。
- 原理：
- allkeys - random（所有键随机）
- 原理：
- 当 Redis 内存达到 maxmemory 时，会在所有的键（包括有过期时间和无过期时间的键）中随机选择一个键进行删除。这个策略没有考虑键的使用频率，只是简单地随机选择要删除的键。
- 应用场景：
- 适用于对数据访问模式不太明确或者数据重要性相对比较均衡的场景。例如，在一个简单的键值存储系统中，存储的数据类型和访问频率都比较复杂，难以通过 LRU 等策略来有效管理内存，采用 allkeys - random 策略可以在一定程度上避免某些键一直占用内存而无法被删除的情况。
- 原理：
- volatile - random（设置过期时间的键中随机）
- 原理：
- 当内存达到 maxmemory 且需要删除键来腾出空间时，只会在设置了过期时间的键中随机选择一个键进行删除。和 volatile - lru 一样，它只关注设置了过期时间的键，不过选择删除的方式是随机的，而不是基于使用频率。
- 应用场景：
- 适用于对设置过期时间的键的使用频率没有明确认知，且希望以随机方式来清理这些键的场景。比如在一个数据采样系统的缓存中，带有过期时间的采样数据的重要性相对比较均衡，采用 volatile - random 策略可以在内存紧张时随机清理这些采样数据对应的键。
- 原理：
- volatile - ttl（设置过期时间的键中剩余存活时间最短）
- 原理：
- 当 Redis 内存达到 maxmemory 时，会在设置了过期时间的键中选择剩余存活时间（Time - To - Live，TTL）最短的键进行删除。Redis 会维护每个设置了过期时间的键的剩余存活时间信息，当需要腾出空间时，优先删除那些即将过期的键。
- 应用场景：
- 适用于希望尽快清理那些即将过期的键的场景。例如，在一个限时促销活动的缓存系统中，活动相关的缓存数据都设置了过期时间，采用 volatile - ttl 策略可以确保在内存紧张时，先删除那些即将过期的促销活动缓存键，使得系统能够更好地应对内存压力，同时也符合限时促销活动数据时效性的特点。
- 原理：
更多推荐
28
0- 0
已为社区贡献5条内容
所有评论(0)