Analysis of the order submission business in the Grain Mall

Business analysis of order submission

Idea: The entire process of verifying tokens, creating orders, verifying prices, remotely locking inventory, and remotely deducting points is a transactional operation. (Transactions cannot control remote business, and each transaction needs to be added)

Note:
1. The "Submit Order" button page is the order settlement page. At this time, an anti-weight token is set to avoid multiple submissions. The token will change every time the page is refreshed.
2. To submit the order, first use redis' String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";Script
[token comparison and deletion must ensure atomicity] verification token, atomic verification token and deletion token
3, after saving the order, it is necessary to lock the inventory to avoid insufficient inventory when the user pays; And if the inventory fails, the logic of saving the order must be revoked.

Question 1: If the inventory lock is successful, but due to a network timeout, a timeout exception is returned, causing other programs to mistakenly believe that an exception will trigger the previous step "Create Order", order rollback, and inventory deduction.
Question 2: If the business "remote deduction of points service" after the inventory lock is abnormal, the inventory above will not be rolled back. The simple understanding is that the execution of the remote service is completed, and the following other methods have problems, resulting in: the executed remote request must not be rolled back, because the transaction cannot be controlled if it is not in a connection.

Check the "Local Transaction and Distributed Transaction" document.
Solution 1: seatea @GlobalTransactional //There will be problems when there is high concurrency, and the efficiency is extremely low

Seata controls distributed transactions
 * 1), each microservice must first create undo_log;
 * 2), install transaction coordinator; seata-server: https://github.com/seata/seata/releases
 * 3), integration
 * 1. Import dependency spring-cloud-starter-alibaba-seata seata-all-0.7.1
 * 2. Unzip and start seata-server;
 * registry.conf: registry configuration; modify registry type=nacos
 * file.conf:
 * 3. All microservices that want to use distributed transactions use seata DataSourceProxy to proxy their own data sources
 * 4. Each   microservice must import
 * registry.conf
* file.conf vgroup_mapping.{application.name}-fescar- service-group = "default"
 * 5. Start testing distributed transactions
 * 6. Mark the entry of distributed large transactions @GlobalTransactional
 * 7. Use @Transactional for each remote small transaction


Inventory unlocking scenario
1). The order is placed successfully, and the order expires and no payment is automatically cancelled by the system or manually by the user. Inventory must be unlocked
2), the order is placed successfully, the inventory lock is successful, and the next business call fails, causing the order to roll back. The efficiency of seata is too slow, do not consider. The
previously locked inventory will be automatically unlocked.

Solution: RabbitMQ  
first understand the basic knowledge points, and the specific code will be released later.

1. Local affairs 1. The basic nature of the transaction Several characteristics of database transactions:  Atomicity  ,  Consistency  , Isolation or  Isolation And durability  (Durabilily)  , abbreviated as  ACID  ; Atomicity: A series of operations cannot be split as a whole, and either succeed or fail at the same time Consistency: The data is consistent with the business as a whole before and after the transaction. Transfer.  A:1000  ;  B:1000  ; turn  200 The transaction is successful  ; A  :  800 B  :  1200 Isolation: The transactions are isolated from each other. Persistence: Once the transaction is successful, the data will definitely be placed in the database. In the past single application, our multiple business operations use the same connection to operate different data tables. Once there is an abnormality, We can easily roll back as a whole;

Business  : Our specific business code Storage  : inventory business code; deduction of inventory Order  : order business code; save the order Account  : account business code; minus account balance For example, the business of buying things, deducting inventory, placing orders, and debiting accounts are a whole; they must succeed or fail at the same time A transaction starts, which means that all the following operations are in the same connection; 2. The isolation level of the transaction READ UNCOMMITTED  (read uncommitted) The transaction of this isolation level will read the data of other uncommitted transactions. This phenomenon is also called dirty read.    READ COMMITTED  (read commit) One transaction can read another committed transaction, and multiple reads will cause different results. This phenomenon is called non-reproducible Repeat the question,  the default isolation level of Oracle  and  SQL Server  .   REPEATABLE READ  (repeatable read) The isolation level is the  MySQL  default isolation level. In the same transaction,  the result of select  is the time when the transaction started Point status, so the same  The results read by the  select operation will be consistent, but there will be phantom reading. MySQL of InnoDB  engine can pass The next-key locks  mechanism (refer to the  "  row lock algorithm  "  section below) to avoid phantom reading. SERIALIZABLE  (serialization) Under this isolation level, transactions are executed serially, and  the InnoDB engine of the MySQL  database  will implicitly give read operations Add a read sharing lock to avoid dirty read, non-repeatable replay and phantom read problems. 3. Dissemination of affairs 1 , PROPAGATION_REQUIRED :  If no transaction creates a new transaction, if the current transaction exists, Just join the transaction, this setting is the most commonly used setting. 2 , PROPAGATION_SUPPORTS :  support for the current transaction, if the current transaction exists, joined the transaction, if and when If there is no transaction before, it is executed as a non-transaction. 3 , PROPAGATION_MANDATORY :  support for the current transaction, if the current transaction exists, joined the transaction, if If there is no transaction currently, an exception is thrown. 4 , PROPAGATION_REQUIRES_NEW :  create a new transaction, regardless of the current deposit transaction does not exist, creates a new business. . 5 , PROPAGATION_NOT_SUPPORTED :  performing an operation to a non-transactional manner, if a current transaction is present, when put The previous transaction is pending. 6 , PROPAGATION_NEVER :  to perform non-transactional way, if the current transaction exists, an exception is thrown. 7 , PROPAGATION_NESTED :  If the current transaction exists, it is executed within nested transactions. If there is no current transaction, Perform  an operation similar to PROPAGATION_REQUIRED  .