http://www.open-open.com/lib/view/open1410485827242.html
quote
First of all, first of all, the RDB persistence of Redis is to generate a point-in-time snapshot of the data set within a specified time interval. The specific process is:
execute bgsave, the redis main process fork a child process; <br>The main process continues to process client requests;
The child process writes a memory snapshot at the current point in time to a dump.rdb file;
this process does not involve a transaction.
Secondly, there are two ways to implement transactions in Redis.
One is to use commands such as
MULTI
EXEC
DISCARD
WATCH; instead, Lua script transactions are used; for details, see the official documentation: https://link.zhihu.com/?target=http%3A //redis.io/topics/transactions
WATCH we can easily solve this kind of problem:
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
Using the above code, if after
WATCH is executed, execute Previously, if another client modified the value of mykey, the current client's transaction would fail. Usually, Lua scripts are used to encapsulate multiple basic redis commands to implement a complex transaction operation.
quote
The DISCARD command is used to roll back, and AOF can be configured to write to disk immediately for each command, so ACID is fully available. <br><br>But unlike many database systems, Redis uses optimistic locking, so in the case of concurrency, the possibility of failure is high. <br><br>Back to your first question, the process of BGSAVE does not provide external services, and the process of responding to user requests is always the same. As mentioned above, after AOF is turned on, the persistence is also satisfiable. However, in actual use, it is generally not necessary to frequently write to disk for extremely low probability of data loss. <br><br>Finally, Redis transactions are useful for more complex business needs. When I migrated data to Cassandra, because the latter only supports very lightweight transactions, transactions with slightly larger granularity must be divided into many small transactions to write (the atomicity of the entire transaction cannot be guaranteed), and in Various checks must also be done when reading.
quote
1. The Redis server is a single-threaded architecture. Although different clients seem to be able to maintain connections at the same time, the commands issued are serialized and executed, which is the highest level of isolation under the usual database theory.
2. Use MULTI/ EXEC to assemble multiple commands into a single transmission to achieve atomicity
3. Using the optimistic locking function provided by WATCH, at the moment of your EXEC, if the key of WATCH has been changed, all the instructions between MULTI and EXEC will not be executed. Execute without rollback
4. The DISCARD instruction mentioned in other answers is only used to undo the instructions that were temporarily stored before EXEC, not rollback
8 kinds of transaction processing of Jedis
http://www.open-open.com/lib/view/open1410485827242.html