Comment régler la transaction distribuée (XA) en fonction de la performance?

mettons D'abord un vocabulaire commun. Nous avons deux ou plusieurs partis

• "Coordonnateur des transactions c'est là que réside notre logique commerciale. C'est le côté qui orchestre la transaction distribuée.
• participant à la Transaction (XAResource) il peut s'agir de N'importe quelle base de données supportant des transactions distribuées ou d'une autre entité supportant le protocole XA comme la messagerie service.

permet de mettre en évidence les principales fonctions API effectuées lors de la transaction XA. - démarrer(XID) la fin de l'(XID) - préparer (XID) - commit (XID)

Les 2 premières opérations sont visibles dans notre code source. C'est quand nous initions la transaction faire un peu de travail et puis dire commettre. Une fois que nous envoyons le message de propagation à partir du code source, le coordinateur de la Transaction et le participant à la transaction prend la relève et fait du travail.

Le paramètre

XID est utilisé comme une clé unique permettant d'identifier la transaction. Chaque coordonnateur des transactions et chaque participant peuvent à tout moment participer à plus d'une transaction, ce qui est donc nécessaire pour les identifier. Le XID comporte deux parties: la première partie identifie la transaction globale, la seconde partie identifie le participant. Cela signifie que chaque participant à la même transaction aura ses propres identificateur. Une fois que nous arrivons à la phase de préparation de la transaction , chaque participant à la transaction écrit son travail au journal des transactions et chaque participant à la Transaction(XARersource) vote si sa partie est OK ou a échoué. Une fois tous les votes reçus, la transaction est commentée. Si le pouvoir diminue, le Cooridinateur de Transaction et le participant à la Transaction gardent leurs journaux de transaction durables et peuvent présumer leur travail. Si l'un des votes du participant a échoué pendant la transaction commit alors ultérieure de restauration seront entrepris.

Implications en termes de performances

selon le théorème du CAP, chaque application (Fonctionnalité) se situe quelque part entre le triange défini par la cohérence, le partitionnement et la disponibilité. Le principal problème de la transaction XA / Distributed est qu'elle exige une extrême cohérence.

cette exigence se traduit en très haut réseau et disque IO activité.

activité sur disquette le coordonnateur des transactions et le participant doivent tenir un journal des transactions. Ce journal est tenu sur le disque dont chaque transaction a besoin pour forcer l'information avec ce disklog, cette information n'est pas de l'information tamponnée. Le fait d'avoir une grande paralysie se traduira par une grande quantité de petits messages forcés au disque dans chaque journal de transaction. Normalement si nous copions un fichier 1Go d'un disque dur à un autre disque dur ce sera très rapide. Si nous divisons le fichier en 1 000 000 parties de quelques octets chacune le transfert de fichier sera extrêmement lent.

le forçage du disque augmente avec le nombre de participants.

1 participante est la menacer comme de la transaction normale

2 participants à la la force du disque est de 5

3 égale 7

réseau Activité Pour dessiner un paralel pour xatransaction distribuée, nous devons le comparer à quelque chose. L'activité de réseau pendant la transaction normale est la suivante. 3 réseau de voyages -enslist des transactions, envoyer quelques Sql commit.

pour une transaction XA c'est une idée plus compliquée. Si nous avons 2 Participants. Nous recrutons les ressources dans une transaction 2 voyages réseau. Ensuite, nous envoyons prepare message un autre 2 voyages puis nous commettons avec un autre 2 voyages.

l'activité de réseau réelle qui se produit pour 2 ressources augmente encore plus les participants que vous enrôlez dans la transaction.

la conclusion sur la façon d'obtenir une transaction distribuée rapide

• pour ce faire, vous devez vous assurer d'avoir un réseau rapide avec une latence minimum
• assurez-vous d'avoir des disques durs avec un minimum de latence et un maximum de vitesse d'écriture aléatoire. Un un bon SSD peut faire des miracles. - Essayer d'enrôler le moins possible de ressources distribuées dans la transaction
• essayer de diviser vos données en données qui ont une forte exigence de cohérence et de disponibilité (données réelles) et des données qui ont de faibles exigences de cohérence. Les données en direct utilisent la transaction distribuée. Pour les données hors ligne utiliser la transaction normale, ou aucune transaction si vos données ne l'exige pas.

Ma réponse est basée sur ce que j'ai lu dans " XA exposé " (et expérience personnelle) qui semble ne plus être disponible sur internet qui m'a incité à écrire ceci.