Distributed transaction framework learning and practical experience

 

 

    Recently, I studied the scenario of using distributed transactions on our side, and by the way, I learned the source code of the distributed framework.

 

    Scenes:

      Points are exchanged for coupons. Two-step operation. The first step is to call the points service to deduct points, and the second step is to issue coupons.

 

    Distributed Framework Support Scenarios

       1. Replenishment operation, a simplified two-stage model, the real deduction is done in the first stage, the second stage is not processed if the first stage is successful, and the replenishment operation is performed if the first stage fails. For example, if the points are successfully deducted and the coupons fail to be issued, then the interface for redeeming points will be called for compensation.

       2. The second stage, try conform cancel, the first stage will be frozen, and the second stage will be deducted or cancelled.

 

    Distributed transaction framework call process
    
     
 
   

    Flow Description:

      1. Status is divided into business status and transaction status. Status process: business status init, business status success or failure. Initialize the transaction status process_wating, and process the transaction status in two stages. Each action is processed in two stages and the status of each action is updated at the same time. According to the comprehensive result of each action, the processing result of the entire transaction is set as success or failure.

      2. Only one of the last steps will be executed. If the business status is successful and it is a reclamation operation, you don’t need to do anything. If the business status fails and it is a reclamation operation, the reclamation participant will be executed. If it is the second stage, cancel or confirm the participants and initiators according to the business status.

 

     db script:

   

tx_info | CREATE TABLE `tx_info` (
  `id` bigint(64) NOT NULL COMMENT 'id',
  `tx_id` varchar(256) NOT NULL COMMENT 'transaction id',
  `business_type` varchar(32) NOT NULL COMMENT 'business type',
  `business_id` varchar(128) NOT NULL COMMENT 'business id',
  `status` varchar(32) NOT NULL COMMENT 'transaction status',
  `retry_count` int(11) DEFAULT NULL COMMENT 'Number of retries, only meaningful for some states',
  `check_back_info` text COMMENT 'Transaction checkback information',
  `participants_info` text COMMENT 'Participants basic information',
  `ext_properties` text COMMENT 'Extra property fields',
  `version` int(11) DEFAULT NULL COMMENT 'version control',
  `create_time` datetime NOT NULL COMMENT 'create time',
  `db_update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `biz_status` varchar(32) NOT NULL DEFAULT 'UNKOWN' COMMENT 'Business execution status',
  PRIMARY KEY (`id`,`create_time`),
  KEY `idx_tx_id` (`tx_id`(255)),
  KEY `idx_business_id` (`business_id`),
  KEY `idx_create_time` (`create_time`),
  KEY `idx_update_time` (`db_update_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Transaction information table'
/*!50100 PARTITION BY RANGE (to_days(create_time))
(PARTITION p20161101 VALUES LESS THAN (736634) ENGINE = InnoDB,
 PARTITION p20161201 VALUES LESS THAN (736664) ENGINE = InnoDB,
 PARTITION p20170101 VALUES LESS THAN (736695) ENGINE = InnoDB,
 PARTITION p20170201 VALUES LESS THAN (736726) ENGINE = InnoDB,
 PARTITION p20170301 VALUES LESS THAN (736754) ENGINE = InnoDB,
 PARTITION p20170401 VALUES LESS THAN (736785) ENGINE = InnoDB,
 PARTITION p20170501 VALUES LESS THAN (736815) ENGINE = InnoDB,
 PARTITION p20170601 VALUES LESS THAN (736846) ENGINE = InnoDB,
 PARTITION p20170701 VALUES LESS THAN (736876) ENGINE = InnoDB)


 action_info | CREATE TABLE `action_info` (
  `id` bigint(20) NOT NULL COMMENT '主键id',
  `tx_id` varchar(256) NOT NULL COMMENT 'transaction id',
  `business_type` varchar(32) NOT NULL COMMENT 'business type',
  `business_id` varchar(128) NOT NULL COMMENT 'business id',
  `action_type` varchar(32) NOT NULL COMMENT 'action type',
  `action_name` varchar(64) DEFAULT NULL COMMENT 'action name',
  `status` varchar(32) NOT NULL COMMENT 'Operation status',
  `ext_properties` text COMMENT 'Extra property fields',
  `version` int(11) NOT NULL COMMENT 'version information',
  `create_time` datetime NOT NULL COMMENT 'create time',
  `db_update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`,`create_time`),
  UNIQUE KEY `idx_txid_aname` (`tx_id`(255),`action_name`,`create_time`),
  KEY `idx_business_id` (`business_id`),
  KEY `idx_create_time` (`create_time`),
  KEY `idx_update_time` (`db_update_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Participant operation information table'
/*!50100 PARTITION BY RANGE (to_days(create_time))
(PARTITION p20161101 VALUES LESS THAN (736634) ENGINE = InnoDB,
 PARTITION p20161201 VALUES LESS THAN (736664) ENGINE = InnoDB,
 PARTITION p20170101 VALUES LESS THAN (736695) ENGINE = InnoDB,
 PARTITION p20170201 VALUES LESS THAN (736726) ENGINE = InnoDB,
 PARTITION p20170301 VALUES LESS THAN (736754) ENGINE = InnoDB,
 PARTITION p20170401 VALUES LESS THAN (736785) ENGINE = InnoDB,
 PARTITION p20170501 VALUES LESS THAN (736815) ENGINE = InnoDB,
 PARTITION p20170601 VALUES LESS THAN (736846) ENGINE = InnoDB,
 PARTITION p20170701 VALUES LESS THAN (736876) ENGINE = InnoDB)

        

 

     Technical principle:

     1. Dubbo generalization call , refer to the previous blog.