Database read-write separation and payment callback operations

I am thinking about separation of reading (A) and writing (B) in the database. If there is a payment callback, there will definitely be transactions in the middle, which requires multiple queries (A) and writes (B), and operates multiple different hosts. Library (A, B), how to maintain data integrity

For example, when the payment is called back, verify it first, then open the transaction, check in A, write B, check A, and write B, will there be no problems with the transaction?

The database used separates reading and writing. When calling back payment, it must be multiple reads and multiple writes. How to ensure that the transaction operation can be successful in one transaction

Reply content:

I am thinking about separation of reading (A) and writing (B) in the database. If there is a payment callback, there will definitely be transactions in the middle, which requires multiple queries (A) and writes (B), and operates multiple different hosts. Library (A, B), how to maintain data integrity

For example, when the payment is called back, verify it first, then open the transaction, check in A, write B, check A, and write B, will there be no problems with the transaction?

The database used separates reading and writing. When calling back payment, it must be multiple reads and multiple writes. How to ensure that the transaction operation can be successful in one transaction

First of all, it must be clear that opening a transaction is for a database, that is, for the main database. After opening a transaction, you cannot query from the database (nor can you query from the database, because the locking operation of the query is a write operation) , so in general, the entire transaction operation should be for the main database, and there is no problem of going to A to check and then writing to B as you mentioned.

If the business volume of the poster is very large, you can consider sharding the database and installing the user ID to take the remaining shards. Then the performance problem can also be solved, and the transaction problem can also be solved. My company's current business uses sharding

@junze Sub-database question, is your master-slave database data synchronization real-time? What kind of business scenarios are the master database and slave database divided into? How to ensure the data consistency of the master-slave database?