Comment dédoubler des flux d'événements parallèles

Question

Existe-t-il une approche standard pour la déduplication de flux d'événements parallèles? Avant d'essayer de réinventer la roue, je veux savoir si ce problème a des approches connues.

Mon composant client communiquera avec deux serveurs. Chacun fournit un flux d'événements en temps quasi réel (~ 1 seconde). Les événements peuvent parfois être hors service. Supposons que je puisse identifier les événements de manière unique. Je dois envoyer un seul flux d'événements au code consommateur avec les mêmes performances en temps quasi réel.

Answer 1

On a beaucoup écrit sur ce genre de problème. Voici un document fondamental, par Leslie Lamport:

http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#time-clocks

L'article de Wikipédia sur la théorie de la transformation opérationnelle est un très bon point de départ pour d'autres recherches:

http://en.wikipedia.org/wiki/Operational_transformation

En ce qui concerne votre problème, vous Il faudra choisir un poids arbitraire pour mesurer le coût du retard par rapport au coût des événements perdus. Vous pouvez gérer deux files d'attente de priorité, classées par ordre chronologique, où vont les événements entrants. Vous feriez une fusion - et sur les têtes des deux files d'attente avec un certain retard (pour permettre des événements hors d'ordre), et jetez les événements qui se sont produits "avant" l'horodatage de l'événement que vous avez envoyé. Si ce n'est pas mieux que ce que vous aviez déjà en tête, eh bien, au moins, vous aurez l'occasion de lire ce joli papier Lamport!

Answer 2

Je pense que l'optimisation pourrait être spécifique au système d'exploitation. De la tâche que vous avez décrite, je pense à deux threads qui consomment des données entrantes et les ajoutent au flux commun ayant un accès basé sur des mutex. Linux et Win32 ont tous deux des procédures de type mutex, mais ils peuvent avoir des performances lentes si vous avez un débit de données vraiment excellent. Dans ce cas, je fonctionnerais par blocs de données, ce qui permettra d'utiliser des mutex pas si souvent. Bien sûr, il y a un thread principal qui consomme les données et il y accède aussi avec un mutex.