Redis6 transaction and locking mechanism

Catalog

Business

Basic operation

Error mechanism

Pessimistic locking

Optimism lock

Redis Three characteristics of transaction

Second kill case

Oversold problem

Connection timeout problem

Inventory remaining problems

---

Business

        Redis A transaction is a separate isolation operation ： All commands in the transaction are serialized 、 To execute in order . Transaction is in the process of execution , Will not be interrupted by command requests from other clients .

        Redis The main function of a transaction is to concatenate multiple commands to prevent other commands from queuing .

Basic operation

        multi Command to form a team , The next input instructions will enter the command queue in turn , But will not execute , Until input exec after ,Redis The previous commands in the command queue will be executed successively .

As shown below ：

 

  If you want to give up forming a team , Just input discard that will do .

Error mechanism

An error occurred while forming a team , All tasks will be canceled during execution .

As shown below ：

An error occurred while executing , Only commands that report errors will not be executed , Other commands will be executed , No rollback . 

As shown below ：

Pessimistic locking

         Every time Lock the data every time you get it , In this way, when others take the data, it will block until it is unlocked . There are many lock mechanisms used in traditional relational databases , For example, line locks. , Table lock, etc. , Read the lock , Write locks, etc. , It's all locked before the operation .

Optimism lock

        It will not be locked every time you take data , But when updating, we will judge whether others have updated this data during this period , You can use mechanisms such as version numbers to control . Optimistic lock is suitable for multi read applications , This can improve throughput .Redis It's using this check-and-set The mechanism implements the .

monitor  key

In execution multi Before , Execute first watch key1 [key2], You can watch one ( Or more ) key , If you're in business This before execution ( Or these ) key Altered by other orders , Then the business will be interrupted .

watch <key>

Cancel surveillance  

Cancel watch  Command to all key Surveillance .

If in execution watch After the command ,exec Order or  discard If the order is executed first , Then there's no need to execute unwatch 了 .

unwatch

Example ：

We are connecting number one and number two at the same time k1 To monitor , And all open transactions . In connection 1, add 100 The operation of , You can find , Connection 1 was successfully executed , Return results ：200, Then add... In the second connection 200 The operation of , The result is nil, The reason is because k1 The data of has been modified , Cause the transaction to be interrupted .

 

Redis Three characteristics of transaction

Separate isolation operation ： All commands in the transaction are serialized 、 To execute in order . Transaction is in the process of execution , Will not be interrupted by command requests from other clients .

There is no concept of isolation level ： Commands in the queue will not be executed until they are submitted , Because no instruction is actually executed before the transaction is committed .

There is no guarantee of atomicity ： If a command fails in a transaction , Subsequent orders will still be executed , No rollback .

Second kill case

Oversold problem

When shopping websites conduct commodity spike activities , In the case of concurrency , Locks need to be set to avoid oversold . for instance , A commodity has 1000 Pieces of , Yes 10000 A person is doing a second kill ,10000 Requests without lock , There will be oversold problems , The inventory of final goods is negative .

Solution

Use optimistic locks to limit , When the inventory of goods changes , Transaction execution failed .

Connection timeout problem

Many users send seckill requests at the same time , There will be a request timeout problem , You need to set the timeout .

Solution

Use connection pool to solve .

Inventory remaining problems

The optimistic lock is used to eliminate the oversold problem , But when a user succeeds in seckill , Someone who kills at the same time as this user , And the people who have succeeded in the second kill in the program due to the change of inventory information , Transactions do not execute . Although this part of people occupy the quota of second kill , But in fact, I didn't buy any goods , Inventory of goods has not decreased , But it took up the number of seconds .

Solution

Use LUA Script , Will be complex or multi-step redis The operation is written as a script , Submit to redis perform , Reduce repeated connections redis The number of times , Lifting performance . also LUA Scripts have a certain atomicity , Will not be interrupted by other orders . Use LUA Scripts solve problems , It's actually redis Take advantage of its single threaded feature , The problem of multi task concurrency is solved by using task queue .