Let me talk about the problem first: When
RedissonMultiLock distributed lock is in use, you can specify two values: waiting time and timeout time
Problems in the system: When the upstream system called the order creation interface, the network caused the interface response timeout, and the upstream automatically retryed. As a result: my system generated two simultaneous transactions based on the upstream order number. Active order
In the previous notes, redis distributed locks and AOP use attention issues have said that the interface is idempotent. And the priority of distributed lock is also lower than transaction, then this problem is strange
Later, according to the online log analysis, the transaction and distributed lock priority is also normal, and the system interface processing time exceeds the redisson lock time;
when the redisson lock is locked, I specify the timeout by default Time, but when the interface is called, due to network reasons, the system on my side timed out when calling the downstream system, so the redisson lock was automatically released. By the way, to solve this problem, I also looked at the redisson part. Source code, record the source code in the next note
The redisson lock time set in my own system is 5S. After 5S, redisson automatically releases the lock, so when the response times out, problems will occur:
- The A system calls my B system. We think thread1 is used to create the order. When my B system creates an order, it also calls other systems to obtain some data for verification. Due to network reasons, it takes time for me to respond. More than 5S;
- So the problem comes at this time: the distributed lock I added is released after 5S, but the code of thread1 is still executing at this time, and the transaction is not committed.
- At this time, the system A initiates a retry again. At this time, we think that thread2 is to add the lock. The situation at this time is: the lock added last time has been released, but the transaction has not yet been committed.
- The thread2 of system A tried to lock, the lock was successful, and then the idempotent check was performed. Since the last transaction of thread1 was not committed at this time, there is no record in the database, so the idempotent check passed. At this time, the second The thread that locked the second time began to create the order. During the creation process, the thread that locked the first time submitted the transaction. . .
So embarrassingly, the corresponding table field in the database does not add a unique index, so multiple records that are valid at the same time are inserted.
Solution:
1. Add fields in the database and make a unique index based on the business order number + order status.
2. When redisson locks, do not specify the timeout period, let redisson automatically renew the lock
3. Set the redisson lock time Longer
The third method is a relatively quick temporary solution, but in the long run, the first and second methods may be better