Data operations are performed on multiple data. Based on performance considerations, distributed transactions are first excluded,
Later I referred to eBay'sDelete distributed transactions using the message queue and Message application status table.Http://rdc.taobao.com/blog/cs? P = 671
The process is roughly like this:
Begin ;
Insert Into Transaction Values (Xid, $ seller_id, $ buyer_id, $ amount );
Put_to_queue" Update User ("Seller", $ seller_id, amount );
Put_to_queue" Update User ("Buyer", $ buyer_id, amount );
Commit ;
For Each message In Queue
Begin ;
Select Count ( * ) As CNT From Message_applied Where Msg_id = Message. ID;
If CNT = 0 Then
If Message. Type = "Seller" Then
Update User Set Amt_sold = Amt_sold + Message. Amount Where ID = Message. User_id ;
Else
Update User Set Amt_bought = Amt_bought + Message. Amount Where ID = Message. User_id ;
End
Insert Into Message_applied Values (Message. ID );
End
Commit ;
If The transaction is successful.
Dequeue message
Delete From Message_applied Where Msg_id = Message. ID;
End
End
However, if the operation on database a succeeds and database B fails, I can try again in a short time. If the retry fails, I have to perform manual rollback on the data in database A, but another comment I put forward later is not as good as a structure like this.
BooleanFlag =False;
Try {
Begin;
// Dosomething a library
Commit;
Flag = True ;
} Catch (Exception e ){
Rollback;
}
If (FLAG ){
Try {
Begin;
// Dosomething database B
Commit;
} Catch (Exception e ){
// Roll back database a manually
Rollback;
}
}
The latter seems simpler and more convenient. Although the former can make the data eventually consistent, it is inevitable that the former does not seem to have achieved the expected results because the data must be rolled back by other factors.
The system will discuss the advantages and disadvantages of the two methods, as well as whether there is a better way to boast database transactions.