Vous prévoyez d'utiliser Azure Cache pour Redis et vous attendez à ce que le cache atteigne fréquemment sa capacité maximale et nécessite des évictions. Les modèles d'accès montrent qu'un petit sous-ensemble d'éléments sera accédé beaucoup plus souvent que les autres. Quelles sont les deux politiques d'éviction que vous devriez choisir pour optimiser les performances pour ce modèle ?

Les politiques d'éviction allkeys-lru et volatile-lru sont les plus appropriées ici. allkeys-lru (Least Recently Used) évince les clés les moins récemment utilisées parmi toutes les clés du cache, qu'elles aient ou non un TTL défini. Ceci est efficace lorsque la plupart des données sont éligibles à l'éviction et que vous souhaitez conserver les éléments les plus fréquemment accédés. volatile-lru évince les clés les moins récemment utilisées parmi celles qui ont un TTL défini. Cette politique est utile si vous avez un mélange de données, certaines avec un TTL et d'autres que vous ne voulez pas évincer. Dans les deux cas, l'algorithme LRU est idéal pour conserver les "petits sous-ensembles d'éléments accédés beaucoup plus souvent", car ces éléments seront constamment mis à jour et ne seront donc pas les "moins récemment utilisés". noeviction empêcherait de nouvelles écritures lorsque le cache est plein, ce qui n'est pas souhaitable. Les politiques random (allkeys-random, volatile-random) ne tiendraient pas compte de la fréquence d'accès, évincant des éléments populaires. volatile-ttl évincerait les clés avec le TTL le plus court, ce qui n'est pas lié à la fréquence d'accès.