Vous apprendre étape par étape comment utiliser PHP pour réaliser une transaction distribuée TCC

                                                                                                                                                                                                                                                 Qu'est-ce que TCC ? TCC est l'abréviation des trois mots Try, Confirm et Cancel. Il a été proposé pour la première fois par Pat Helland dans un article intitulé "La vie au-delà des transactions distribuées : l'opinion d'un apostat" publié en 2007.

Composition du TCCLe TCC est divisé en 3 phases

Phase d'essai : essayer d'exécuter, compléter tous les contrôles commerciaux (cohérence), réserver les ressources commerciales nécessaires (quasi-isolement)

• Phase de confirmation : si toutes les succursales Si l'essai est réussi, il passera à l'étape de confirmation. Confirm exécute réellement l'activité, n'effectue aucune vérification commerciale et utilise uniquement les ressources métier réservées lors de la phase d'essai d'annulation : si l'un des essais de toutes les branches échoue, il passe à la phase d'annulation. Annuler libère les ressources métier réservées lors de la phase Try.
• Il existe 3 rôles dans les transactions distribuées TCC, qui sont les mêmes que les transactions distribuées XA classiques :

AP/application, qui initie les transactions globales et définit les branches de transaction que la transaction globale inclut

RM/gestionnaire de ressources, responsable pour la gestion de diverses ressources de transactions de succursale

• TM/Transaction Manager, chargé de coordonner la bonne exécution des transactions globales, y compris l'exécution de Confirmer et Annuler, et de gérer les exceptions du réseau
• Si nous voulons mener une activité similaire à les transferts interbancaires, les transferts sortants (TransOut) et les transferts entrants (TransIn) se trouvent respectivement dans des microservices différents. Le diagramme de séquence typique d'une transaction TCC terminée avec succès est le suivant :

TCC Practice

Suivant. nous réaliserons un développement spécifique à la transaction TCCLe framework open source actuellement disponible pour TCC est principalement le langage Java, représenté par Seata. Notre exemple utilise nodejs, et le framework de transactions distribuées utilisé est dtm, qui prend en charge les transactions distribuées de manière très élégante. Expliquons la composition de TCC en détail

Écrivons maintenant la fonction de traitement spécifique Try/Confirm/Cancel

$vega->handleFunc('/api/TransOutTry', function (Mix\Vega\Context $ctx) {
    var_dump('TransOutTry', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'SUCCESS']);})->methods('POST');$vega->handleFunc('/api/TransOutConfirm', function (Mix\Vega\Context $ctx) {
    var_dump('TransOutConfirm', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'SUCCESS']);})->methods('POST');$vega->handleFunc('/api/TransOutCancel', function (Mix\Vega\Context $ctx) {
    var_dump('TransOutCancel', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'SUCCESS']);})->methods('POST');$vega->handleFunc('/api/TransInTry', function (Mix\Vega\Context $ctx) {
    var_dump('TransInTry', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'SUCCESS']);})->methods('POST');$vega->handleFunc('/api/TransInConfirm', function (Mix\Vega\Context $ctx) {
    var_dump('TransInConfirm', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'SUCCESS']);})->methods('POST');$vega->handleFunc('/api/TransInCancel', function (Mix\Vega\Context $ctx) {
    var_dump('TransInCancel', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'SUCCESS']);})->methods('POST');

À ce stade, les fonctions de traitement de chaque sous-transaction sont OK, puis démarrons la transaction TCC et effectuons des appels de branche

    Dtmcli\tccGlobalTransaction($dtm, function ($tcc) use ($svc) {
        /** @var Dtmcli\Tcc $tcc */
        $req = ['amount' => 30];
        $tcc->callBranch($req, $svc . '/TransOutTry', $svc . '/TransOutConfirm', $svc . '/TransOutCancel');
        $tcc->callBranch($req, $svc . '/TransInTry', $svc . '/TransInConfirm', $svc . '/TransInCancel');
    });

À ce stade, une transaction distribuée TCC complète est terminée.

Si vous souhaitez exécuter entièrement un exemple réussi, alors référez-vous à cet exemple yedf/dtmcli-php-sample, il est très simple de l'exécuter

# 部署启动dtm# 需要docker版本18以上git clone https://github.com/yedf/dtmcd dtm
docker-compose up# 另起一个命令行https://github.com/yedf/dtmcli-php-sample.gitcd dtmcli-php-sample
composer installphp demo.php start

Annulation du TCC

Si la banque se prépare à transférer le montant à l'utilisateur A 14 heures, on constate que le compte de l'utilisateur 2 est anormal et le retour échoue. Que va-t-il se passer ? Nous pouvons simuler cette situation en laissant TransIn renvoyer un échec

$vega->handleFunc('/api/TransInTry', function (Mix\Vega\Context $ctx) {
    var_dump('TransInTry', $ctx->request->getQueryParams(), $ctx->request->getParsedBody());
    $ctx->JSON(200, ['result' => 'FAILURE']);})->methods('POST');

Nous donnons un diagramme de séquence d'interaction d'échec de transaction

La différence entre cela et un TCC réussi est que lorsqu'une certaine sous-transaction renvoie un échec, le tout sera transaction annulée ultérieurement, appelez l'opération Annuler de chaque sous-transaction pour vous assurer que toutes les transactions globales sont annulées.

En mode transaction TCC, de nombreux lecteurs se demanderont : que se passera-t-il si la confirmation/annulation échoue ? C’est une bonne question car cela signifie que vous réfléchissez profondément au modèle de transaction TCC. Le premier cas est un échec temporaire, tel qu'une panne de réseau, une indisponibilité d'une application ou d'une base de données. De telles erreurs seront réessayées et le succès sera finalement renvoyé ; l'autre cas est un échec commercial. Selon l'accord TCC, les ressources sont verrouillées. première étape pour garantir que des ressources suffisantes peuvent permettre l'exécution de Confirm/Cancel. En d'autres termes, en termes de logique du programme, Confirm/Cancel n'est pas autorisé à renvoyer une défaillance commerciale. Si une défaillance commerciale se produit, il s'agit d'un bug et les développeurs doivent le faire. corrigez manuellement le bug.

Résumé

Dans cet article, nous avons présenté les connaissances théoriques de TCC et avons également donné un processus complet d'écriture d'une transaction TCC à travers un exemple, couvrant la réussite normale et l'annulation réussie. Je pense que les lecteurs ont une compréhension approfondie du TCC à travers cet article. Pour des connaissances plus complètes sur les transactions distribuées, veuillez vous référer à «

Les sept solutions les plus classiques pour les transactions distribuées

»

Les exemples utilisés dans l'article sont extraits de yedf/dtm (https://github.com/yedf/ dtm), il prend en charge plusieurs modes de transaction : TCC, SAGA, .pub/summary/code.html#go). Fournit une fonction de barrière de sous-transaction pour résoudre avec élégance des problèmes tels que l'idempotence, la suspension et la compensation nulle. Après avoir lu cet article, vous êtes invités à visiter le projet github.com/yedf/dtm et à donner une étoile pour le soutenir !

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!