table of Contents
Transaction execution based on specific conditions-distributed lock
Transaction execution based on specific conditions-distributed lock improvement
Redis transaction
Introduction
- What is a transaction
- During the execution of instructions in Redis, multiple consecutively executed instructions were disturbed, interrupted, or jumped into the queue
- A redis transaction is a command execution queue, which packs a series of predefined commands into a whole (a queue) .
- When executed, they will be executed in the order of addition at one time , without interruption or interference in the middle.
- In a queue, execute a series of commands in a one-time, sequential, and exclusive manner
Basic transaction operations
Open transaction
multi
- Function: Set the open position of the transaction. After this instruction is executed, all subsequent instructions are added to the transaction
Execute transaction
exec
- Role: Set the end position of the transaction and execute the transaction at the same time. Appear in pairs with multi, use in pairs
- Note: The command to join the transaction temporarily enters the task queue and is not executed immediately. Only the exec command is executed before execution
Cancel transaction
discard
- Role: The definition of termination of the current transaction occurs after multi and before exec
Example 1
Example 2
Transaction workflow
Matters needing attention
- What should I do if the command format is entered incorrectly during transaction definition?
- Grammatical errors
- Refers to the wrong command format
- process result
- If there is a syntax error in the commands included in the defined transaction, all commands in the overall transaction will not be executed. Include those commands with correct syntax .
- What should I do if there is an error in command execution during the process of defining a transaction?
- Run error
- Refers to the command format is correct, but cannot be executed correctly. For example, perform incr operation on list
- process result
- Commands that can run correctly will be executed, commands that run incorrectly will not be executed
- Note: The data corresponding to the executed command will not be automatically rolled back, and the programmer needs to implement the rollback in the code.
Manual transaction rollback
- Record the previous state of the data affected during the operation
- Single data: string
- Multiple data: hash, list, set, zset
- Set command to restore all modified items
- Single data: set directly (pay attention to peripheral attributes, such as timeliness)
- Multiple data: modify the corresponding value or copy the entire clone
lock
- Transaction execution based on specific conditions
Business scene
- During the hot sale on Tmall Double 11, replenishment was added to the goods that had been sold out, and the four salesmen had the authority to replenish the goods. Replenishment operation may be a series of column operation, involving a multiplicity of continuous operation, how to ensure the operation will not be repeated?
Business analysis
- Multiple clients may operate the same set of data at the same time, and once the data is modified by the operation, it will not be suitable for continued operation
- Lock the data to be operated before the operation, once the change occurs, terminate the current operation
Transaction execution based on specific conditions-lock
- Add a monitoring lock to the key, if the key changes before executing exec, terminate the transaction execution
watch key1 [key2……]
- Cancel the monitoring of all keys
unwatch
Transaction execution based on specific conditions-distributed lock
Business scene
- During the hot sale of Double 11 on Tmall, replenishment of the sold-out goods was added and the replenishment was completed. Customers to buy enthusiasm, will buy all the goods within three seconds to buy completed. This replenishment has completely emptied the inventory. How to avoid the last item not being purchased by multiple people at the same time? [Oversold problem]
Business analysis
- Using watch to monitor whether a key has changed can no longer solve the problem, here is the specific data to be monitored
- Although redis is single-threaded, when multiple clients operate on the same data at the same time, how to avoid being modified at the same time?
solution
- Use setnx to set a public lock
setnx lock-key value
- Using the return value feature of the setnx command, if there is a value, it will return the setting failure, and if there is no value, it will return the setting success.
- For those who return to the setting successfully, they have the control right to carry out the next specific business operation
- For those failing to return to the setting, do not have the right to control, queue or wait
- After the operation is completed, release the lock by del operation
- Note: The above solution is a design concept that relies on normative guarantees and is risky
Example
Transaction execution based on specific conditions-distributed lock improvement
Business scene
- Relying on the distributed lock mechanism, the corresponding client is down when a user operates, and the lock has been acquired at this time. How to solve?
Business analysis
- Since the lock operation is controlled by the user to lock and unlock, there must be a risk of not unlocking after locking
- The unlocking operation cannot only rely on user control, and the system level must provide a corresponding guarantee solution
solution
- Use expire to add a time limit to the lock key, do not release at that time, give up the lock
expire lock-key second pexpire lock-key milliseconds
- Since operations are usually microseconds or milliseconds, the lock time should not be set too large. The specific time needs to be confirmed after the business test.
- For example: the longest execution time of the operation holding the lock is 127ms, and the shortest execution time is 7ms.
- The maximum execution time of the test million times corresponds to the maximum time consumption of the command, and the average time consumption of the network delay test million times
- Recommended lock time setting: maximum time consumption*120%+average network delay*110%
- If the maximum time-consuming business << average network delay, it is usually 2 orders of magnitude, whichever is longer.
Example
- [Note]: Refer to the Dark Horse Redis tutorial: https://www.bilibili.com/video/BV1AE411j7Wq?t=5