A simple cross-region cross-Database Transaction processing architecture

 

It turned out to be a bit of this idea. How can we do this? This time, we made a new architecture demonstration for the company and added it with the help of the new architecture. It was like this:

My practice is very simple: I wrote a transaction processing class and provided a static start transaction method, then the commit and rollback methods, and then the guid was used as the transaction ID. The transaction management class manages the local database links and remote cross-domain service information, uses this information to submit or roll back when commit or rollback, and executes commands concurrently at the database level, for remote cross-origin commit or rollback, a remote transaction pool, Remote Transaction Service class, and Remote Transaction Service call proxy class (both commit and rollback methods are required) must be combined for processing, the transaction ID is used throughout the process. Of course, all data access layers and database access layers are based on a transaction parameter. If there is no transaction, it is null. The logic processing layer determines whether to use transaction processing. This is simple, and the result is still acceptable. Of course, this mode has a fatal weakness, that is, it cannot solve the commit consistency problem, that is, if multiple databases are involved, if the previous N-1 of database services are committed successfully, the nth database cannot be committed. Cross-region transactions have a big problem, but it is still possible if it is a LAN. This method is suitable for data distribution and storage (non-image). Of course, most operations need to be concentrated in one center during data splitting. After all, cross-region access is still slow.

This time, the entire architecture can be queried in a distributed manner, multiple databases can be updated at the same time (can be controlled to the table level), and transparent to the business logic layer. The speed and ease of use are both good, the service layer supports building blocks for transaction processing.

This architecture is appealing to the cloud application architecture. It can store data by business and users. The application can also support multiple centers and multiple load modes. In theory, the scalability is unlimited. Of course, because the main purpose is not to support image synchronization, I did not add the database command queue processing method to ensure reliability. In terms of database nodes, I simply used three updates at the same time, the query method selects one of them randomly. For enterprise-level businesses, especially applications with high real-time performance and consistency, it is really difficult to ensure transaction processing and reliability together across databases. Therefore, I gave up my own reliability (that is, I wrote three copies at the same time and read one copy at random) and asked the database to do it myself. After all, they were more professional.

Main technical points of this architecture: multithreading (asynchronous query of different target databases), odpnet, WCF (cross-origin access), transactions, synchronization (simple use of lock), reflection mechanism, generic.

Is it easy? But it is indeed available!

1) Why is transaction processing of business (enterprise) application business systems very difficult, because the business logic in these applications is complex and the relationship between businesses is very close, in addition, it is time-ordered, that is, the execution of business logic is ordered, and the SQL statements reflected in the database can only be executed in the incoming order, and cannot be processed in parallel, therefore, the so-called latency consistency (that is, only the final result pair is guaranteed and the consistency in the intermediate process is not guaranteed) is not allowed here in principle, but generally Internet applications can, for example, in csdn, the number of clicks and blog rankings, users do not care about the ranking accuracy at a certain point. As long as the incremental update principle is used, although the real-time accuracy cannot be ensured, however, the final accuracy can be ensured. At the transaction isolation level, in order to ensure that the business logic is correct, the higher the isolation level, the better. However, if the isolation level is too high, the database pressure will be very high, but at least do not read the stolen data. This problem occurs when the database locks at least the row level for the row (including the result row of the query statement in the transaction) of the dataset in the transaction, this will lead to the execution of many other SQL statements. If it involves the data in the previous transaction processing, it can only wait. In addition, due to the timing requirements of business logic execution, the submission of many operation results is irreversible, which is the most obvious in the material demand analysis of ERP. Therefore, to ensure the performance of the business database, transactions must be used less. As a database, multiple databases or cross-domain applications are more troublesome and difficult.

The best way for the train ticket ticketing system is to segment and process the application and split data, which is also very difficult because it also involves the compatibility of the old system. As some netizens have said, thinking about business application systems based on internet applications can only be used for reference at most.

Supplement 2)

 

For example, if it is a transaction, if it is a local access, you only need to create a connection when you execute the transaction command for the first time and start the transaction on the connection, add the connection and transaction to the connection list of the transaction instance. During the second local execution, you do not need to create a connection or transaction, you can directly use existing connections and transactions to execute SQL commands. If cross-origin access is required, you also need to write down the access logs in the transaction so that you can submit and roll back the logs based on the local connection pool and remote access logs. Of course, there will also be remote transaction commit and rollback services. Maintains a remote transaction pool in the system and provides the remote commit and rollback services. Similarly, if a remote call comes over, if the transaction parameter is valid, similarly, when creating a transaction instance for the first time and placing it in a remote transaction pool, the subsequent execution will directly call the corresponding data access interface layer to execute the command (you must pay attention to prevent endless cross-origin Invocation ); if you receive a remote commit or rollback request, you only need to call the transaction instance in the Remote Transaction pool and call the commit or rollback method.

PS: whether a transaction is committed in one or two stages depends on the specific application. Generally, the distributed program tries its best to simplify the transaction.