redis--Transactions & Persistence

first, transaction processing

Redis's support for transactions is simple, or its transactions are flawed. It can only guarantee that a command in a client-initiated transaction can be executed consecutively, without inserting commands from other client side. The flaw is that if a client puts two commands into a transaction, the second command sends an error when executing, but the Redis transaction does not roll back the first command. Such as:

　　

The operation of Redis transactions is as follows: When the client initiates the Multi command, the connection enters a transaction context, and the subsequent command of the connection is not executed immediately, but is placed first in a buffer queue, and Redis executes all commands in the queue sequentially when the EXEC command is executed.

1.1 Open/Execute Transaction (multi/exec)　　
　　

1.2 Canceling a transaction (discard)　　
　　

1.3 Optimistic Lock　　

Most are implemented based on the recording mechanism of the version of the teaching data. That is, to add a version of the data identity, in a database table-based version of the solution, typically by adding a "version" field for the database table to read out the data, the version number is read together, and then updated, the version number is added 1. At this point, the version number of the submitted data is compared to the current version number of the corresponding record in the database table, and if the submitted data version number is greater than the current version number of the database, it is updated, otherwise it is considered to be outdated data.

Example:

Suppose there is an age key, we open two sessions to the age assignment, and then look at the results.

　　

　　

　　

The watch command monitors the given key, and when exec does, the entire transaction fails if the monitored key has changed since the call to watch. You can also call watch to monitor multiple keys more than once. This allows you to add optimistic locks to the specified key. Note that watch key is valid for the entire connection, and the transaction is the same. If the connection is broken, both the monitoring and the transaction are automatically purged. Of course. The Exec,discard,unwatch command clears all monitoring in the connection.

Ii. The mechanism of persistence

Redis is an in-memory database that supports persistence, which means that Redis often needs to synchronize the in-memory data to the hard disk to ensure persistence. Redis supports two types of persistence scenarios:

2.1 snapshotting (snapshot-Save data -default mode)　　

Snapshots are the default persistence mode. In this way, the in-memory data is written to a binary file in a snapshot, with the default file name Dump.rdb. You can automatically make snapshot persistence by configuring settings. We can configure Redis to take snapshots automatically if more than M key is modified within n seconds. Such as:

　　

2.2 aof (storage operation )　　

Because the snapshot is done at a certain interval, if Redis is accidentally dropped, all modifications after the last snapshot are lost. AoF mode is more persistent than snapshot, because Redis appends each received write command to a file by using the Write function, and when Redis restarts, it rebuilds the contents of the entire database in memory by re-executing the Write command saved in the file.

Of course, because the OS caches write modifications in the kernel, it may not be written to disk immediately. It is also possible to lose some of the modifications to aof-like persistence. We can tell Redis through the configuration file that we want to force the OS to write to disk by Fsync. Such as:

　　

We can see from the appendonly.aof file that the Redis operation is stored:

　　

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

redis--Transactions & Persistence