Redis design and Implementation (VIII) | transaction

Business

• summary

Redis adopt MULTI、EXEC、WATCH Wait for the command to implement the transaction （transaction) function . Transactions provide a way to package multiple command requests , then Disposable 、 A mechanism for executing multiple commands sequentially and during transaction execution , The server will not interrupt the transaction and execute the command requests of other clients , It will execute all the commands in the transaction , Then I will process the command requests of other clients .

But everything needs to be met ACID, namely Atomicity , Uniformity , Isolation and persistence

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set "name" "lhj"
QUEUED
127.0.0.1:6379> get "name"
QUEUED
127.0.0.1:6379> set "py" "sb"
QUEUED
127.0.0.1:6379> get "py"
QUEUED
127.0.0.1:6379> exec
1) OK
2) "lhj"
3) OK
4) "sb"

1. Implementation of transactions

• Three stages of transaction

1. The transaction start ：MULTI, The transaction ID will be added
2. Order to join the team
3. Transaction execution ：EXIT、EXEC, Remove the identification of the transaction

1.1 Order to join the team

• summary

During the transaction phase , There will be different responses to different commands sent

• If the command sent by the client is EXEC、DISCARD、WATCH、MULTI One of the four orders , Then the server executes the command immediately .
• On the contrary , If the command sent by the client is EXEC、DISCARD、WATCH、MULTI Commands other than four , Then the server doesn't execute the command immediately , Instead, the command is placed in a transaction queue , And back to the client QUEUED reply .

1.2 Transaction queue

• summary

Each client in its own redisClient There are transaction states in the structure , Transaction status , There are transaction queues and queued command counts , Transaction queue with FIFO The way to keep the order to join the team

typedef struet multiState {
    
	// Transaction queue ,FIFO The order 
	multiCmd *commands;
	// Has entered the queue to order the count 
	int count;
}multistate;

// The structure of the queue 
typedef struct multiCmd {
    
	// Parameters 
	robj **argv;
	// The number of arguments 
	int argc;
	// Command pointer 
	struct redisCommand *cmd;
}multiCmd;

1.3 Perform transactions

• summary

When a client in a transactional state sends EXEC On command , This EXEC The command will be executed immediately by the server . The server will traverse the transaction queue of this client , Execute all commands saved in the queue , Finally, all the results of executing the command are returned to the client .

• Execution process

Create a blank reply queue 、 Read the parameters and the number of parameters and the command to execute , Execute and add the result to the reply queue , Remove the transaction id , Clear client transaction status （ Counters and release queues ）

2.WATCH Implementation of commands

• summary

WATCH The order is a Optimism lock （optimistic locking ), It can be EXEC Before the order is executed , Monitor any number of database keys , And in EXEC When the order is executed , Check if at least one of the monitored keys has been modified , If so , The server will refuse to execute the transaction , And return a null reply to the client that represents the failure of transaction execution .

watch "xx" "xx" "xx"

• Example

You can see in the T4 After the execution , stay T5 Will refuse to execute the transaction

2.1 Use WATCH Command monitor database key

• summary

16 In a database redisDb There is one in the structure watch_keys Dictionary , The key is the monitored key , The value is a linked list , All clients monitoring the corresponding database key are recorded in the linked list

As you can see from the diagram ,name Key quilt c1 and c2 monitor , Others in the same way

• Be careful

Only when the client uses watch, Will appear in the linked list corresponding to the key

2.2 Trigger of monitoring mechanism

• summary

All commands to modify the database , such as SET、LPUSH、SADD、ZREM、DEL、FLUSHDB wait , It will call after execution multi.c/touchWatchRey Function pair watched keys Dictionary check , Check if any client is monitoring the database key just modified by the command , If any , that touchwatchKey Function will monitor the modified key All Client's REDIS_DIRTY_CAS Logo on , Indicates that the transaction security of the client has been compromised .

2.3 Determine whether the transaction is safe

• summary

When a client executes EXEC On command , Will check and monitor the client corresponding to the command execution , His REDIS_DIRTY_CAS Identify whether to open , Whether it is opened or not will determine whether it is executed

• If it's opened , So at least one key has been modified , Refuse to enforce
• If not, commit the transaction , perform
  

3. The transaction ACID nature

• summary

In traditional relational databases , Often use ACID Property to test the transaction function Reliability and safety . stay Redis in , Transactions always have Atomicity （Atomicity)、 Uniformity （Consistency） And isolation ( Isolation ), And when the Redis When running in a particular persistence mode , Transactions also have persistence （Durability ).

• Why rollback is not supported

Because to guarantee Redis Simple and efficient

3.1 Atomicity （Atomicity)

• summary

Atomicity means , All commands in a transaction are executed as a whole , Either none of them or all of them
stay Redis in , All the commands in the transaction queue are executed , Or none of them

• Execution failure

Execution failure is a command error and the server refuses to execute , As a result, the entire transaction will not be executed

• An error is reported only after the execution （ Rollback is not supported ）

Redis The biggest difference between a transaction of and a transaction of a traditional relational database is ,Redis Transaction rollback mechanism is not supported ( rollback ), Even if a command in the transaction queue has an error during execution , The whole business will continue , Until all commands in the transaction queue are executed .

3.2 Uniformity （Consistency）

• summary

A consistent transaction means , If the database is consistent before the transaction is executed , So after the transaction is executed , Whether or not the transaction is executed successfully , The database should still be consistent .“ Agreement ” It means that the data conforms to the definition and requirements of the database itself , Does not contain illegal or invalid error data .Redis Ensure transaction consistency through careful error detection and simple design ,

3.2.1 Team entry mistake

• summary

If a transaction queue command is in progress , The command does not exist or the command format is incorrect Redis Refuse to execute this transaction ; Older versions do not execute wrong commands , The correct one will execute

3.2.2 Perform error

• summary

This kind of mistake can not be found in the team joining mistake , For example, the command format is correct but not standard , It can only be checked during execution ; And executing the wrong command does not interrupt the transaction , Will continue with the rest of the order , And what has been executed will not be affected by the error

3.2.3 Server down

• summary

Anyway, you remember , Whether it is running in memory without persistence or RDB or AOF Will not cause data inconsistency , If you don't have a persistence scheme, the database will become empty after restart, so the data is always consistent

3.3 Isolation, ( Isolation )

• summary

Transaction isolation refers to , Even if there are multiple transactions executing concurrently in the database , Each transaction will not affect each other , And the result of the transaction executed in the concurrent state is exactly the same as that of the transaction executed in the serial state .

because Redis Use a single threaded way to execute transactions （ And the commands in the transaction queue ), And the server guarantees , The transaction will not be interrupted during transaction execution , therefore ,Redis The transactions of are always running in a serial way , And transactions are always isolated .

3.4 persistence

• summary

The durability of a transaction means , When a transaction is completed , The result of executing this transaction has been saved to the permanent storage medium （ For example, hard disk ） Inside the , Even if the server is down after the transaction completes , The results of the execution will not be lost .

because Redis The transactions of are simply wrapped in queues Redis command ,Redis Does not provide any additional persistence capabilities for transactions , therefore Redis The durability of transactions is determined by Redis The persistence pattern used determines :

• If you don't start persistence, then naturally there will be no persistence
• RDB In mode , There's no guarantee , because BGSAVE It is usually set at a time and executed in a child process with asynchrony , There is no guarantee that it will be saved in the hard disk for the first time , So I don't have
• AOF In the pattern , Data loss may occur even if it is synchronized every second , If you return the frequency to the operating system, that is appendfsync The value of the option is no when , Even less persistent

• There is only one case

Regardless of Redis In what mode , Add... At the end of a transaction SAVE Commands always guarantee the durability of transactions :