TL;DR :Un seul thread rend redis plus simple, et redis est toujours lié aux E/S.
La mémoire est E/S. Redis est toujours lié aux E/S. Lorsque redis est soumis à une charge importante et atteint le nombre maximal de demandes par seconde, il manque généralement de bande passante réseau ou de bande passante mémoire et n'utilise généralement pas beaucoup de CPU. Il y a certaines commandes pour lesquelles cela ne sera pas vrai, mais dans la plupart des cas d'utilisation, redis sera sévèrement lié aux E/S par le réseau ou la mémoire.
À moins que les vitesses de la mémoire et du réseau ne deviennent soudainement plus rapides, être monothread n'est généralement pas un problème. Si vous avez besoin d'évoluer au-delà d'un ou de quelques threads (c'est-à-dire :configuration maître<->esclave<->esclave), vous envisagez déjà Redis Cluster. Dans ce cas, vous pouvez configurer une instance de cluster par cœur de processeur si vous êtes en quelque sorte en panne de processeur et que vous souhaitez maximiser le nombre de threads.
Je ne suis pas très familier avec la source ou les composants internes de Redis, mais je peux voir comment l'utilisation d'un seul thread facilite la mise en œuvre d'actions atomiques sans verrouillage. Les threads rendraient cela plus complexe et ne semblent pas offrir de grands avantages car redis n'est pas lié au processeur. La mise en œuvre de la simultanéité à un niveau supérieur à une instance Redis semble être une bonne solution, et c'est ce que Redis Sentinel et Redis Cluster aident.
Qu'advient-il des autres requêtes lorsque redis prend beaucoup de temps ?
Ces autres demandes seront bloquées pendant que redis termine la longue demande. Si nécessaire, vous pouvez tester cela en utilisant le client-pause commande.
