The article started with a long-winded sentence, and I have written a total of 21 trivial knowledge about redis here. There is not too much writing about the application of redis in the programming process. What is rewritten is the redis command, the client, the server and the master used in the production environment. If you can see the principles of slave, sentinel, and cluster implementation, I believe it will be helpful to you when you use redis in the future.
Up to now, redis-related content has come to an end for the time being. In the future, I may focus on introducing c#-related knowledge, including the use of IL, .net core bottom layer, and microservices.
Oops, when I wrote it, I suddenly wanted to make a few words. In recent years, c# has been declining in China and java is in full swing. Many Microsoft partners or great gods are not optimistic about c#. There are so many related posts on the Internet. Another phenomenon is From position to salary, it was dumped by languages such as java and go.
But I think that leaving these external factors aside, c# is actually very good in terms of technology or language. Although in recent years, .net core is somewhat nondescript, various borrowing (plagiarism) syntax sugars of other languages, and between major versions There are a lot of problems such as incompatibility, but this does not affect his excellence. After all, growth does have to take a lot of detours, so I hope that children who are interested in continuing to engage in .net can continue to pay attention to c#.
Redis implements transactions through MULTI, EXEC, WATCH and other commands. The transaction provides a mechanism to package multiple command requests, and then execute multiple commands at once and sequentially, and during the transaction execution, the server will not interrupt the transaction Instead of executing other client command requests, he will execute all the commands in the transaction, and then take to process the command requests of other clients.
A transaction usually goes through the following three stages from beginning to end: transaction start, command enqueue, transaction execution.
1) The transaction begins
The execution flag of the MULTI command is the start of the transaction. The MULTI command can switch the client executing the command from a non-transactional state to a transactional state. All this is done by turning on the REDIS_MULTI flag in the flags attribute of the client state.
2) Order to join the team
If the command sent by the client is one of the four commands EXEC, DISCARD, WATCH, MULTI, then the server executes the command immediately, on the contrary, the server does not execute the command immediately, but puts the command into a transaction queue , And then return a QUEUED reply to the client.
Each Redis client has its own transaction state, which is stored in the mstate attribute of the client state:
typedef struct redisClient{
//事务状态
multiState mstate;
} redisClient；
The transaction status includes a transaction queue and a counter of enqueued commands:
typedef struct multiState{
//事务队列，FIFO顺序
multiCmd *commands;
///已入队列计数
int count;
} multiState;
typedef struct multiCmd{
//参数
robj **argv;
//参数数量
int argc;
//命令指针
struct redisCommand *cmd;
} multiCmd;
The transaction queue saves incoming commands in a first-in, first-out manner.
3) Execute affairs
When a client in a transaction state sends an EXEC command to the server, the EXEC command will be executed by the server immediately. The server will traverse the client's transaction queue, execute all the commands stored in the queue, and finally return all the results of executing the commands to the client.
WATCH command
The watch command is an optimistic lock. It can monitor any number of database keys before the exec command is executed, and when the EXEC command is executed, check whether at least one of the monitored keys has been modified. If so, the server will reject Execute the transaction, and return to the client an empty reply identifying the failure of the transaction execution.
Each Redis database stores a watched_keys dictionary. This key is a data database key monitored by the watch command, and the value of the dictionary is a linked list. The linked list records all clients that are monitored with corresponding database keys.
typedef struct redisDb{
//正在被watch命令监视的键
dict *watched_keys;
} redisDb；
Triggering of the monitoring mechanism: After executing all commands to modify the database, the touchWatchKey function will be called to check the watched_keys dictionary to see if the client is monitoring the database key that has just been modified by the command. If any, then touchWatchKey function The REDIS_DIRTY_CAS flag of the client that monitors the modified key will be turned on, indicating that the transaction security of the client has been destroyed.
Determine whether the transaction is safe
When the server receives an EXEC command from a client, the server will decide whether to execute the transaction according to whether the client has turned on the REDIS_DIRTY_CAS flag: if the client's REDIS_DIRTY_CAS flag has been turned on, then it means that at least one of the keys monitored by the client A key has been modified. In this case, the transaction submitted by the client is no longer safe, so the server will refuse to execute the transaction submitted by the client; if the client REDIS_DIRTY_CAS flag is not turned on, then the client is monitoring All keys have not been modified, the transaction is still safe, and the server will execute the transaction submitted by the client.
ACID nature of the transaction
Atomicity: The biggest difference between Redis transactions and traditional relational database transactions is that Redis does not support a transaction rollback mechanism. If an error occurs during execution of a command in the transaction queue, the entire transaction will continue to be executed until the transaction All the commands in the queue have been executed.
consistency:
1. Enqueue error. If a transaction does not exist or the format of the command is incorrect during the process of enqueuing the command, Redis will refuse to execute the transaction
2. Execution errors: The errors that occur during execution are errors that are discovered by the server when they can no longer enter the team. These errors will only be triggered when the command is actually executed; even if an error occurs during the execution of the transaction, the server will The execution of the transaction will not be interrupted, he will continue to execute the remaining commands in the transaction, and the consistent command will not be affected by the wrong command.
3. Server shutdown: If the server is running in non-persistent memory mode, the database will be blank after restarting, so the data is always consistent; if the server is running in RDB mode, then the transaction will not be stopped in the middle of the transaction. Inconsistent, because the server can restore the data based on the existing RDB file, thereby restoring the database to a consistent state. If the server is running in the APF mode, the downtime of the transaction will not cause inconsistency, because the server can restore the data based on the existing APF file, thereby restoring the database to a consistent state.
Isolation: Redis uses a single thread to execute transactions, and the server guarantees that the transaction will not be interrupted during the execution of the transaction. Therefore, the redis transaction always runs in a serial manner, and the transaction is always isolated.
Durability: The durability of Redis transactions is determined by the persistence mode used by Redis. (No matter what mode Redis is running in, adding the SAVE command at the end of a transaction can always ensure the durability of the transaction.)
Learn a little every day, there will always be gains.
Note: Respect the author's intellectual property rights, refer to "Redis Design and Implementation" for the content in the article, and only learn here to share with you.
