Expérience Redis que vous devez connaître pour le fonctionnement et la maintenance de Linux

Redis est très populaire dans la communauté technologique actuelle. Redis a parcouru un long chemin depuis un petit projet personnel d'Antirez jusqu'à devenir la norme industrielle en matière de stockage de données en mémoire. L’ensemble de bonnes pratiques qui en résulte permet à la plupart des gens d’utiliser correctement Redis.

Ci-dessous, nous explorerons 10 expériences d'utilisation correcte de Redis.

1. Arrêtez d'utiliser KEYS *

D'accord, commencer cet article en contestant cette commande n'est peut-être pas un bon moyen, mais c'est peut-être en effet le point le plus important. Souvent, lorsque nous prêtons attention aux statistiques d'une instance Redis, nous entrerons rapidement la commande "KEYS *" afin que les informations clés soient clairement affichées. Pour être honnête, du point de vue de la programmation, nous avons tendance à écrire un pseudocode comme celui-ci :

for key in'keys *':
doAllTheThings()　

Mais lorsque vous disposez de 13 millions de clés, la vitesse d'exécution va ralentir. Étant donné que la complexité temporelle de la commande KEYS est O(n), où n est le nombre de clés à renvoyer, la complexité de cette commande dépend de la taille de la base de données. Et lors de l’exécution de cette opération, aucune autre commande ne pourra être exécutée dans votre instance.

Comme commande alternative, jetez un œil à SCAN, qui vous permet de le faire de manière plus conviviale... SCAN analyse la base de données dans une itération incrémentielle. Cette opération est effectuée en fonction de l'itérateur du curseur, vous pouvez donc arrêter ou continuer à tout moment comme bon vous semble.

2. Découvrez le coupable qui ralentit Redis

Étant donné que Redis ne dispose pas de journaux très détaillés, il est très difficile de savoir ce qui se fait dans l'instance Redis. Heureusement, Redis fournit un outil de statistiques de commandes comme le suivant :

127.0.0.1:6379> INFO commandstats

# Commandstats

cmdstat_get:calls=78,usec=608,usec_per_call=7.79

cmdstat_setex:calls=5,usec=71,usec_per_call=14.20

cmdstat_keys:calls=2,usec=42,usec_per_call=21.00

cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

Grâce à cet outil, vous pouvez afficher un instantané de toutes les statistiques de commandes, telles que le nombre de fois que la commande a été exécutée et le nombre de millisecondes nécessaires à l'exécution de la commande. (le temps total de chaque commande et le temps moyen), exécutez simplement la commande CONFIG RESETSTAT pour la réinitialiser afin que vous puissiez obtenir un tout nouveau résultat statistique.

3、将 Redis-Benchmark 结果作为参考，而不要一概而论

Redis 之父 Salvatore 就说过：“通过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。很多时候人们跑到我这里，他们想知道为什么自己的Redis-Benchmark统计的结果低于最优结果 。但我们必须要把各种不同的真实情况考虑进来，例如：

• 可能受到哪些客户端运行环境的限制？
• 是同一个版本号吗？
• 测试环境中的表现与应用将要运行的环境是否一致？

Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点，但是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方式，并且需要一个尽可能的和生产相似的环境。

4、Hashes 是你的最佳选择

以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构：

foo:first_name

foo:last_name

foo:address

上面的例子中，foo 可能是一个用户的用户名，其中的每一项都是一个单独的 key。这就增加了 犯错的空间，和一些不必要的 key。使用 hash 代替吧，你会惊奇地发现竟然只需要一个 key ：

127.0.0.1:6379> HSET foo first_name 'Joe'

(integer) 1

127.0.0.1:6379> HSET foo last_name 'Engel'

(integer) 1

127.0.0.1:6379> HSET foo address '1 Fanatical Pl'

(integer) 1

127.0.0.1:6379> HGETALL foo

1) 'first_name'

2) 'Joe'

3) 'last_name'

4) 'Engel'

5) 'address'

6) '1 Fanatical Pl'

127.0.0.1:6379> HGET foo first_name

'Joe'

5、设置 key 值的存活时间

无论什么时候，只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。当你去查找一个授权key时——以OAUTH为例——通常会得到一个超时时间。这样在设置key的时候，设成同样的超时时间，Redis就会自动为你清除！而不再需要使用KEYS *来遍历所有的key了，怎么样很方便吧？

6. Choisissez la stratégie de recyclage appropriée

Maintenant que nous avons abordé le sujet du nettoyage des clés, parlons de la stratégie de recyclage. Lorsque l'espace de l'instance Redis est rempli, il tentera de récupérer certaines clés. En fonction de votre utilisation, je vous recommande fortement d'utiliser la stratégie volatile-lru - à condition d'avoir défini un délai d'attente sur la clé. Mais si vous exécutez quelque chose de similaire à un cache et que vous ne définissez pas de mécanisme de délai d'attente pour les clés, vous pouvez envisager d'utiliser le mécanisme de recyclage allkeys-lru. Ma suggestion est de vérifier d'abord ce qui est possible ici.

7. Si vos données sont importantes, veuillez utiliser Try/Except

Si vous devez vous assurer que les données critiques peuvent être placées dans une instance Redis, je vous recommande fortement de les mettre dans un bloc try/sauf. Presque tous les clients Redis adoptent la stratégie « envoyer et oublier », il est donc souvent nécessaire de se demander si une clé est réellement placée dans la base de données Redis. La complexité de l'insertion de try/expect dans les commandes Redis n'est pas le sujet de cet article. Vous devez simplement savoir que cela garantit que les données importantes sont placées là où elles devraient être.

8. N'épuisez pas une instance

Dans la mesure du possible, répartissez la charge de travail de plusieurs instances Redis. À partir de la version 3.0.0, Redis prend en charge les clusters. Redis Cluster vous permet de séparer certaines clés contenant des modes maître/esclave en fonction de plages de clés. La « magie » complète derrière le clustering peut être trouvée ici. Mais si vous cherchez des tutoriels, c'est l'endroit idéal. Si le clustering n'est pas une option, envisagez les espaces de noms et répartissez vos clés sur plusieurs instances. Concernant la façon de distribuer les données, il y a cette excellente revue sur le site redis.io.

9. Est-ce que plus il y a de cœurs, mieux c'est ? !

Bien sûr, c’est faux. Redis est un processus monothread et ne consomme qu'un maximum de deux cœurs, même avec la persistance activée. À moins que vous n'envisagiez d'exécuter plusieurs instances sur un seul hôte - espérons-le uniquement dans un environnement de développement et de test ! ——Sinon, il n'est pas nécessaire de disposer de plus de 2 cœurs pour une instance Redis.

10. Haute disponibilité

Jusqu'à présent, Redis Sentinel a été minutieusement testé et de nombreux utilisateurs l'ont appliqué à des environnements de production (y compris ObjectRocket). Si votre application s'appuie fortement sur Redis, vous devez proposer une solution haute disponibilité pour vous assurer qu'elle ne se déconnecte pas. Bien sûr, si vous ne souhaitez pas gérer ces choses vous-même, ObjectRocket fournit une plate-forme haute disponibilité et un support technique 7 x 24 heures. Si vous êtes intéressé, vous pouvez l'envisager.