Explorez la mise en œuvre de services de messagerie fiables

.

Présentation

Les transactions distribuées sont souvent le problème des transactions orientées service. De nombreux scénarios évitent les transactions distribuées via les entreprises, mais il existe encore certains scénarios qui doivent s'appuyer sur des transactions distribuées. Parlons de la façon de gérer les transactions distribuées

Une solution commune

Il existe de nombreuses façons de résoudre les problèmes de transactions distribuées, et il existe de nombreux blogs sur Internet qui proposent diverses solutions. En résumé, elle peut généralement être divisée selon les deux méthodes suivantes : 1. Engagement en deux phases (2PC en abrégé) : il s'agit d'une solution de transaction distribuée courante. Dans cette méthode, le nœud coordinateur est chargé de coordonner les opérations des nœuds participants et de garantir que tous les nœuds parviennent à un accord lors de la validation ou de l'annulation.

Les transactions distribuées rigides et la validation en deux phases sont un mécanisme permettant d'obtenir une forte cohérence. Les transactions distribuées rigides font référence à une série d'opérations effectuées par plusieurs nœuds participants dans un système distribué qui doivent garantir l'atomicité, c'est-à-dire qu'elles réussissent toutes ou échouent toutes. Ce mécanisme nécessite que tous les nœuds participants suivent le même protocole pendant l'exécution de la transaction et mettent en œuvre la transaction sous la direction du nœud coordinateur

Une transaction distribuée flexible est une méthode de traitement des transactions dans un système distribué. Il adopte la stratégie de validation au mieux, c'est-à-dire qu'il fait de son mieux pour terminer la soumission de la transaction, mais permet également à certaines opérations d'échouer. Dans les transactions distribuées flexibles, le mode TCC (Try-Confirm-Cancel) est généralement utilisé pour mettre en œuvre la gestion des transactions. Le modèle TCC décompose les transactions en trois étapes : Essayer, Confirmer et Annuler

Résolvez d'abord le prérequis de garantie pour les transactions distribuées : l'interface doit être idempotente pour éviter que l'envoi répété de messages n'affecte l'activité

2 Conception d'un système de messagerie fiable (cela semble bien et relativement simple, donc je vais le partager)

Comme indiqué ci-dessus

Démarrez l'exécution. Par exemple :

essayez{
if(prepare()) { //Phase de pré-envoi doService(); //Exécuter la logique métier
updateMsgStatus();//Mettre à jour le message pour confirmer le statut
}
}

1 Pré-envoi du message, phase d'essai, si le message de pré-envoi échoue, l'affaire n'a pas encore été exécutée, donc les systèmes A et B sont toujours cohérents et n'ont pas besoin d'être traités

C'est facile à comprendre

2 Le message pré-envoyé réussit et la logique métier commence à être exécutée. Si l'exécution réussit, le statut du message pré-envoyé mis à jour sera modifié en envoi confirmé. Si l'exécution de la logique métier échoue à ce moment, le message pré-envoyé ne sera pas mis à jour avec le nouveau statut. À ce moment, le système de confirmation de message commencera à fonctionner et retournera au système métier 1 pour vérifier l'état du message. S'il s'avère que l'exécution commerciale a échoué, le statut de pré-envoi sera mis à jour en statut d'échec.

3 Si à ce moment-là, l'exécution de l'affaire est réussie et que le message est mis à jour pour confirmer l'envoi, alors tout va bien et parfait. Si la mise à jour du message échoue, le système de confirmation du message vérifiera toujours l'état et mettra à jour si le message est supprimé ou dont l'envoi est confirmé.

4 Messagers commencent à consommer

1> Par exemple, si la consommation échoue et qu'une incohérence se produit, le système de récupération des messages détecte l'état du message et renvoie le message

2>Si l'exécution de l'affaire échoue, le message ne sera pas confirmé. Le système de récupération des messages détectera toujours l'état du message et renverra le message

.

3> Si la demande échoue, la logique ci-dessus doit être utilisée pour renvoyer l'appel. Bien sûr, il y a une limite au nombre de renvois. Il ne peut pas être envoyé tout le temps. S'il dépasse le nombre maximum de fois. entrera dans la file d'attente des lettres mortes et attendra une intervention manuelle

.

4> Si la demande aboutit, le message sera consommé avec succès, ce qui est parfait et résout le problème d'un service de messagerie fiable

Troisièmement, travaillez dur pour soumettre

C'est relativement simple. Soumettez les messages ayant échoué à plusieurs reprises pour garantir une transmission réussie des messages dans certains scénarios avec de faibles performances en temps réel.

Par exemple, envoyez un message tiers lorsqu'une transaction est terminée. Vous pouvez utiliser la soumission dure pour le moment

L'article est réimprimé de la communauté Open Source Chine [http://www.oschina.net]

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!