Redis est mono-threadé, comment fonctionne-t-il les E / S simultanées?
En essayant de comprendre quelques bases de Redis, je suis tombé sur un intéressant blog post .
L'auteur déclare:
Redis est mono-threadé avec epoll/kqueue et est redéfini indéfiniment en termes de simultanéité des E/S.
Je ne comprends sûrement pas tout le fil conducteur, car je trouve cette déclaration déconcertante. Si un programme est mono-thread, comment fait-il quelque chose en même temps? Pourquoi est-il si formidable que les opérations Redis soient atomiques, si le serveur est mono-thread de toute façon?
Quelqu'un pourrait-il s'il vous plaît éclaircir un peu la question?
Cela dépend de la façon dont vous définissez la concurrence.
Dans les logiciels côté serveur, la simultanéité et le parallélisme sont souvent considérés comme des concepts différents. Sur un serveur, la prise en charge des E/S simultanées signifie que le serveur peut servir plusieurs clients en exécutant plusieurs flux correspondant à ces clients avec une seule unité de calcul. Dans ce contexte, le parallélisme signifierait que le serveur est capable d’exécuter plusieurs tâches à la fois (avec plusieurs unités de calcul), ce qui est différent.
Par exemple, un barman peut s'occuper de plusieurs clients alors qu'il ne peut préparer qu'une boisson à la fois. Ainsi, il peut fournir une concurrence sans parallélisme.
Cette question a été débattue ici: concurrence/parallélisme - Quelle est la différence?
Voir aussi cette présentation de Rob Pike.
Un programme à un seul thread peut certainement fournir une concurrence au niveau des E/S en utilisant un mécanisme de dé/multiplexage des E/S et une boucle d'événement (comme le fait Redis).
Le parallélisme a un coût: avec les multiples sockets/cœurs que vous pouvez trouver sur du matériel moderne, la synchronisation entre les threads est extrêmement coûteuse. D'autre part, le goulot d'étranglement d'un moteur de stockage efficace comme Redis réside très souvent dans le réseau, bien avant le processeur. Les boucles d'événements isolés (qui ne nécessitent aucune synchronisation) sont donc considérées comme une bonne conception pour la construction de serveurs efficaces et évolutifs.
Le fait que les opérations Redis soient atomiques est simplement une conséquence de la boucle d'événement à un seul thread. Le point intéressant est que l'atomicité est fournie sans coût supplémentaire (elle ne nécessite pas de synchronisation). Il peut être exploité par l'utilisateur pour mettre en œuvre un verrouillage optimiste et d'autres modèles sans payer pour le temps système nécessaire à la synchronisation.
OK, Redis est mono-threadé au niveau utilisateur, OTOH. Toutes les E/S asynchrones sont prises en charge par les pools de threads du noyau et/ou les pilotes de niveau fractionné.
'Concurrent', pour certains, inclut la distribution d'événements réseau aux machines d'état de sockets. Il est mono-thread, fonctionne sur un seul noyau (au niveau utilisateur), donc je ne parlerais pas de cela comme simultané. D'autres diffèrent ..
'échelle indéfiniment en termes de simultanéité d'entrées/sorties' est simplement économique avec la vérité. Ils peuvent avoir plus confiance en eux s'ils disaient "peuvent évoluer mieux qu'un fil par client, à condition que les clients n'en demandent pas beaucoup", bien qu'ils puissent alors se sentir obligés d'ajouter "époustouflé par les lourdes charges par d'autres solutions asynchrones qui utilisent tous les cœurs au niveau utilisateur '.