Pourquoi Redis est-il monothread ?

Il y a toujours eu un malentendu dans le passé, pensant que les serveurs hautes performances doivent être implémentés avec des multi-threads

La raison est très simple. causé par un malentendu 2 : le multithreading doit être meilleur que le single threading. Les threads sont très efficaces. Pas vraiment.

redis core signifie que si toutes mes données sont en mémoire, mon opération monothread sera la plus efficace. Pourquoi, car l'essence du multi-threading est que le CPU simule plusieurs. threads Cette situation simulée a un coût, qui est le changement de contexte. Pour un système de mémoire, c'est la plus efficace sans changement de contexte.

Redis utilise un seul processeur pour lier un morceau de données de mémoire, puis lors de la lecture et de l'écriture plusieurs fois dans les données de cette mémoire, tout est fait sur un seul processeur, il s'agit donc d'un seul -processus fileté. Dans le cas de la mémoire, cette solution est la meilleure solution. (Recommandé : "tutoriel vidéo Redis")

Parce qu'un changement de contexte CPU prend environ 1 500 ns.

La lecture de 1 Mo de données continues à partir de la mémoire prend environ 250us. Supposons que 1 Mo de données soit lu 1 000 fois par plusieurs threads, puis il y a 1 000 changements de contexte temporels,

Ensuite, il y a 1 500 ns * 1 000. = 1500us. Il me faut seulement 250us pour lire 1 Mo de données dans un seul thread. Il faut 1500us juste pour changer le contexte temporel, je n'inclut pas le temps qu'il vous faut pour lire un peu de données à chaque fois

.

Quand faut-il utiliser une solution multithread ?

La réponse est : le stockage inférieur est lent. Par exemple, la mémoire disque

est un système avec des IOPS très élevées, car si je veux demander un morceau de mémoire, je demande un morceau de mémoire, et quand je détruis un morceau de mémoire, je détruis un morceau de mémoire. Il est très facile de demander et de détruire de la mémoire. Et la mémoire peut être appliquée dynamiquement en fonction de la taille.

Les caractéristiques des disques sont les suivantes : IPOS est très faible, mais le débit est très élevé. Cela signifie qu'un grand nombre d'opérations de lecture et d'écriture doivent être rassemblées puis soumises au disque pour obtenir les performances les plus élevées. Pourquoi?

Si j'ai une opération de groupe de transactions (c'est-à-dire plusieurs requêtes de transaction séparées, telles que l'écriture, la lecture, l'écriture, la lecture et l'écriture, ces cinq opérations sont ensemble), dans la mémoire, car les IOPS sont très élevé, I Cela peut être complété un par un, mais s'il y a aussi cette méthode de requête dans le disque,

Ma première opération d'écriture se termine comme ceci : j'adresse d'abord dans le disque dur, ce qui prend environ 10 ms , puis je lis Une donnée peut prendre 1 ms puis je la calcule à nouveau (ignorée), puis je la réécris sur le disque dur et cela prend encore 10 ms, un total de 21 ms

La deuxième opération La lecture prend 10 ms et la troisième opération prend 21 ms. Ensuite, je lis pendant 10 ms et j'écris pendant 21 ms. C'est toujours la situation la plus idéale. Si c'est en mémoire, ce sera le cas. moins de 1 ms.

Donc pour le disque, dont le débit est si élevé, la meilleure solution est certainement de regrouper N requêtes dans un buff, puis de les soumettre ensemble.

La méthode est à utiliser de manière asynchrone : ne liez pas la requête au thread de traitement, le thread demandeur met la requête dans un buff, puis attend que le buff soit presque plein, puis le thread de traitement traite le chamois. Ensuite, ce buff est utilisé pour écrire sur le disque ou lire le disque de manière uniforme, afin que l'efficacité soit la plus élevée. N'est-ce pas ainsi que se font les IO en Java~

Pour les appareils lents, cette méthode de traitement est la meilleure. Les appareils lents incluent les disques, les réseaux, les SSD, etc.,

plus C'est très. Il est courant de traiter ces problèmes de manière threadée et asynchrone. C'est ce que fait le célèbre netty.

Enfin, j'ai expliqué pourquoi Redis est monothread, et quand utiliser le monothreading et le multi-threading. En fait, c'est aussi une chose très simple, mais c'est vraiment embarrassant quand la fondation. n'est pas bon. . . .

Citations du Maître Biyifa : Parlons des raisons pour lesquelles un processeur monocœur est plus efficace lorsqu'il est lié à un morceau de mémoire

« Nous ne pouvons pas laisser le système d'exploitation équilibrer la charge, car nous connaissons le nôtre programmes meilleurs. , afin que nous puissions lui allouer manuellement des cœurs de processeur sans trop occuper le processeur. " Par défaut, un seul thread utilisera de manière aléatoire les cœurs de processeur lors des appels système. Afin d'optimiser Redis, nous pouvons utiliser des outils pour sélectionner un seul thread. thread Liez les cœurs de processeur fixes pour réduire les pertes de performances inutiles !

En tant que programme modèle à processus unique, Redis démarre souvent plusieurs instances sur un serveur afin d'utiliser pleinement les processeurs multicœurs. Afin de réduire le coût de commutation, il est nécessaire de préciser le CPU sur lequel s'exécute chaque instance.

Taskset sous Linux peut lier un processus à un processeur spécifique. Vous connaissez mieux votre programme que le système d'exploitation, afin d'éviter que le planificateur ne planifie bêtement votre programme, ou pour éviter la surcharge liée à l'invalidation du cache dans les programmes multi-thread.

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!