Risolvi la sincronizzazione

Come per la pagina di wikipedia collegata alle code dei messaggi:

Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.

(Enfasi grassetto).

Dalla pagina di Wikipedia per il modello di abbonamento-Publish :

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead characterize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

(Di nuovo, enfasi sfacciata)

Per riassumere - in qualsiasi modello di messaggistica, esiste sempre il concetto di mittente e destinatario ; le differenze tra i modelli di messaggio riguardano il modo in cui un messaggio è consegnato a un destinatario.

Code messaggi

• Un modello di coda di messaggi è una forma di consegna di messaggi affidabile , ovvero il mittente garantisce che i dati inviati vengano ricevuti in una coda (un buffer di messaggi). Sebbene non garantisca che il destinatario lo riceverà effettivamente.
• Il buffer / coda dei messaggi mantiene il messaggio per tutto il tempo necessario, finché il destinatario non è pronto a raccogliere il suo messaggio (o la coda viene eliminata / distrutta).
• Tipicamente, una sorta di middleware o piattaforma di broker esiste una coda di messaggi (cioè un sottosistema il cui scopo è di agire come un "ufficio postale" per i messaggi, assicurando che i messaggi vengano instradati ai destinatari giusti)
• In genere, ogni destinatario avrà la propria coda.
• È responsabilità del mittente assicurarsi che le code dei destinatari siano / siano disponibili prima di inviare il messaggio.
• Un errore comune delle code di messaggi è il rischio di dati obsoleti, ad esempio messaggi che sono stati accodati e non aggiornati al momento della loro ricezione. Una soluzione comune (semplice e possibilmente ingenua) a questo potrebbe essere per un editore per garantire che tutte le code siano state appena eliminate prima di inviare il loro primo messaggio.

Publish / Subscribe

• Descrive i pattern fire-n-forget in cui un mittente invia un messaggio senza sapere o preoccuparsi se il messaggio verrà consegnato.
• Il mittente non sa o si preoccupa di nulla del destinatario; il modello potrebbe funzionare con Zero, uno o più destinatari senza alcun effetto sul mittente.
• "gli utenti in ritardo" potrebbero perdere i messaggi precedenti inviati prima di iniziare la sottoscrizione.
• Il "middleware" per pubblicare / iscriversi può essere semplice come un sistema di notifica di base (ad esempio il schema Aggregatore eventi ), oppure potrebbe essere un sistema di broker di messaggi più avanzato.
• Uno o più destinatari utilizzano alcuni metadati del messaggio (come il tipo di messaggio e / o altri descrittori) per "ascoltare" eventuali messaggi di quel tipo
• I mittenti allegano i meta-dati (ad es. tipo di messaggio, ecc.) al messaggio a cui i destinatari possono "iscriversi" per ricevere il messaggio.

Infine, può esserci qualche crossover in termini di implementazione di questi pattern; un modello di pubblicazione / sottoscrizione può essere implementato utilizzando un broker che supporta code di messaggi - questi pattern sono strettamente correlati perché entrambi raggiungono l'obiettivo di disaccoppiare i mittenti dai ricevitori, quindi ci saranno naturalmente molte sovrapposizioni nel modo in cui ognuno di questi i modelli sono implementati.

I moderni strumenti middleware di messaggistica tendono a supportare entrambi i modelli immediatamente con le differenze minime nel codice necessario per utilizzare tali modelli. (Un esempio popolare potrebbe essere RabbitMQ ).

In generale, i sistemi di messaggistica per editore / sottoscrittore funzionano su argomenti. Uno o più editori (produttori) pubblicano messaggi in un argomento e uno o più abbonati (consumatori) si iscrivono a un argomento e leggono le informazioni dall'argomento. L'implementazione sottostante di questo concetto può essere eseguita utilizzando code di messaggi, ad esempio, ciascun abbonato per ogni argomento avrà una propria coda di messaggi in cui i publisher inseriscono dati.

Per le code di messaggi, in genere 1 o più produttori spingono i messaggi in una singola coda e un singolo utente che legge dalla coda.

Quando hai bisogno di un modello di messaggistica molti-a-molti, il concetto di editore / sottoscrittore si adatta alla fattura, ma se stai cercando uno a uno o molti a uno, il modello di coda dei messaggi è più semplice da implementare .

Se hai solo bisogno di usare una coda C ++ con accesso sincronizzato agli oggetti senza dover parlare di mutex, ho avuto successo usando la coda lock-free: link