Parlons de la stratégie d'élimination du cache Redis

Redis Quelles sont les stratégies d'élimination du cache ? Cet article parlera avec vous de la stratégie d'élimination du cache Redis et présentera les suggestions de configuration de la stratégie de cache. J'espère qu'il vous sera utile !

Redis (Remote Dictionary Server), le service de dictionnaire distant, est une base de données de valeurs-clés de type journal open source écrite en langage ANSI C, prend en charge le réseau, peut être basée sur la mémoire et peut être conservée, et fournit une variété d’API linguistiques. [Recommandations associées : Tutoriel vidéo Redis]

Il présente les caractéristiques suivantes :

• Basé sur le fonctionnement de la mémoire et les hautes performances
• Prend en charge la distribution et peut théoriquement être étendu à l'infini
• Structure de stockage clé-valeur, requête Efficace
• Fournit plusieurs API de langage de développement et est facile à intégrer aux systèmes d'entreprise existants.

Habituellement utilisé dans les systèmes d'entreprise pour le cache distribué, le stockage de session centralisé, les verrous distribués et d'autres scénarios d'application.

Qu'il s'agisse d'un cache local ou d'un cache distribué, afin de garantir des performances plus élevées, la mémoire est utilisée pour sauvegarder les données. En raison des limitations de coût et de mémoire, lorsque les données stockées dépassent la capacité du cache, les données mises en cache doivent être expulsées. . Les stratégies d'élimination courantes incluent FIFO pour éliminer les données les plus anciennes, LRU pour éliminer les données les moins récemment utilisées et LFU pour éliminer les données les moins récemment utilisées.

Déclencheurs de la politique d'expulsion du cache Redis

Dans l'environnement de production, nous n'autorisons pas le comportement d'échange dans Redis. Par conséquent, l'utilisation maximale de la mémoire est généralement limitée. Redis fournit le paramètre de configuration maxmemory pour spécifier l'utilisation maximale de la mémoire.

Les configurations suivantes sont légales :

maxmemory 1000KB 
maxmemory 100MB 
maxmemory 1GB 
maxmemory 0  # 表示不做限制，一般不会用

redis.conf Le fichier de configuration est le suivant

8 Stratégies de cache Redis

• volatile-lru Parmi les données avec un délai d'attente défini, supprimez le moins données couramment utilisées ;

• allkeys-lru interroge les données les moins fréquemment utilisées parmi toutes les clés pour la suppression, ce qui est la stratégie la plus largement utilisée

• volatile-random supprime les données qui ont défini un délai d'attente
• allkeys- ; random interroge toutes les clés puis les supprime de manière aléatoire ;
• volatile-ttl interroge toutes les données avec un délai d'attente défini, les trie immédiatement après le suivi et supprime les données sur le point d'expirer
• noeviction (par défaut) si cet attribut est défini ; aucune opération de suppression ne sera effectuée et une erreur sera renvoyée si la mémoire déborde ;

• volatile-lfu expulse les clés les moins fréquemment utilisées de toutes les clés configurées avec un délai d'expiration ;

• allkeys-lfu expulse toutes les clés du moins ; clé fréquemment utilisée ;

Algorithmes LRU et LFU dans Redis

Algorithme LRU

L'algorithme Redis LRU n'est pas une implémentation exacte. Cela signifie que Redis ne peut pas sélectionner le meilleurcandidat à l'expulsion, c'est-à-dire celui qui a reçu le plus de visites dans le passé. Au lieu de cela, il tente d'exécuter une approximation de l'algorithme LRU en échantillonnant un petit nombre de clés, puis en expulsant la meilleure (avec le temps d'accès le plus précoce) des clés échantillonnées.

Cependant, à partir de Redis 3.0, l'algorithme a été amélioré et peut également sélectionner de bons candidats à l'expulsion. Cela améliore les performances de l'algorithme, lui permettant de ressembler davantage au comportement du véritable algorithme LRU.

La chose importante à propos de l'algorithme Redis LRU est que vous

pouvez ajuster la précision de l'algorithme en modifiant le nombre d'échantillons pour vérifier chaque expulsion. Ce paramètre est contrôlé par la directive de configuration suivante :

maxmemory-samples 5

La raison pour laquelle Redis n'utilise pas de véritable implémentation LRU est qu'elle nécessite plus de mémoire. Cependant, pour les applications utilisant Redis, l’approximation est en réalité équivalente. Ce qui suit est un tableau comparatif entre l'approximation LRU utilisée par Redis et le LRU réel.

Le test qui a généré le graphique ci-dessus a rempli un serveur Redis avec le nombre de clés donné. Les clés sont accessibles de la première à la dernière, la première clé est donc la meilleure candidate pour l'expulsion à l'aide de l'algorithme LRU. Par la suite, 50 % des clés supplémentaires ont été ajoutées pour forcer l’expulsion de la moitié des anciennes clés.

Vous pouvez voir trois types de points sur l'image, formant trois bandes différentes.

La bande gris clair est l'objet expulsé.
• La bande grise correspond aux objets qui n'ont pas été expulsés.

La bande verte est l'objet ajouté.

Dans une implémentation théorique de LRU, nous nous attendons à ce que dans l'ancienne clé, la première moitié expire. L'algorithme Redis LRU n'expirera les anciennes clés qu'avec

probabilité.

LRU n'est qu'un modèle qui prédit la probabilité qu'une clé donnée soit accédée dans le futur. De plus, si votre modèle d'accès aux données ressemble beaucoup à une loi de puissance, la plupart des accès se feront dans des ensembles de clés que l'algorithme d'approximation LRU peut bien gérer.

Inconvénients : une grande quantité de données froides peut être consultée dans un certain laps de temps pour générer une grande quantité de données chaudes

LFU 算法

从 Redis 4.0 开始，可以使用新的最不常用驱逐模式。这种模式在某些情况下可能会更好（提供更好的命中率/未命中率），因为使用 LFU Redis 会尝试跟踪项目的访问频率，因此很少使用的项目会被驱逐，而经常使用的项目有更高的机会留在记忆中。

如果您认为在 LRU，最近访问过但实际上几乎从未被请求过的项目不会过期，因此风险是驱逐将来有更高机会被请求的密钥。LFU 没有这个问题，一般应该更好地适应不同的访问模式。

配置LFU模式，可以使用以下策略：

• volatile-lfu 在具有过期集的键中使用近似 LFU 驱逐。
• allkeys-lfu 使用近似 LFU 驱逐任何密钥。

LFU 类似于 LRU：它使用一个概率计数器，称为莫里斯计数器，以便仅使用每个对象的几位来估计对象访问频率，并结合衰减周期，以便计数器随着时间的推移而减少：在某些时候，我们不再希望将密钥视为经常访问的密钥，即使它们过去是这样，以便算法可以适应访问模式的转变。

这些信息的采样与 LRU 发生的情况类似（如本文档的前一部分所述），以便选择驱逐的候选人。

然而，与 LRU 不同的是，LFU 具有某些可调参数：例如，如果不再访问频繁项，它的排名应该以多快的速度降低？还可以调整 Morris 计数器范围，以便更好地使算法适应特定用例。

默认情况下，Redis 4.0 配置为：

• 在大约一百万个请求时使计数器饱和。
• 每一分钟衰减一次计数器。

这些应该是合理的值并经过实验测试，但用户可能希望使用这些配置设置以选择最佳值。

有关如何调整这些参数的说明可以redis.conf在源代码分发的示例文件中找到，但简单地说，它们是：

lfu-log-factor 10 
lfu-decay-time 1

衰减时间是显而易见的，它是计数器应该衰减的分钟数，当采样并发现它比该值更旧时。一个特殊值0意味着：每次扫描时总是衰减计数器，很少有用。

计数器对数因子会改变需要多少次命中才能使频率计数器饱和，这恰好在 0-255 的范围内。系数越高，需要越多的访问以达到最大值。根据下表，系数越低，低访问计数器的分辨率越好：

+--------+------------+------------+------------+------------+------------+
| factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |
+--------+------------+------------+------------+------------+------------+
| 0      | 104        | 255        | 255        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 1      | 18         | 49         | 255        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 10     | 10         | 18         | 142        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 100    | 8          | 11         | 49         | 143        | 255        |
+--------+------------+------------+------------+------------+------------+

淘汰最近一段时间被访问次数最少的数据，以次数作为参考。

缺点：

1. 最近加入的数据常常容易被剔除，因为其起始方法次数比较少，

2. 如果频率时间度量为 1 个小时，则平均一天每个小时内访问频率 1000 的热点数据可能会被 2个小时的一段时间访问的频率为 1001 的数据剔除掉。可能会出现一些临界值的数据。

缓存策略设置建议

建议：了解Redis 的淘汰策略之后，在平时使用尽量主动设置/更新 key 的 expire 时间主动剔除不活跃的旧数据， 有助于提升查询性能

更多编程相关知识，请访问：编程入门！！

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!