05. redis Affairs

Redis Affairs

Redis support services operation. Atomic transaction having atomic, included in the transaction operations are executed either succeed or all fail. But redis Rollback is not supported, but you can avoid erroneous operation in test development sectors. It can be said is half the atoms of support, look at the reasons behind.
Many times we need to be transactional operations.
Translator file: https://redis.io/topics/transactions
practice: python version Reference
https://github.com/7Edge/redis-demo/blob/master/redis_pipeline.py

Affairs

MULTI, EXEC, DISCARD and WATCH operations are the underlying operating redis affairs. These operations allow a set of operations as a atomic operation execution. Been able to do, because what two important safeguards:

1. Command ordered

All the commands in a transaction is orderly, and execution is the execution order. When another client connection error occurs, it is not likely to affect the transaction currently being executed. This ensures that the command execution is isolated operating. Because it is a single-threaded, and redisserver use i / o multiplexing process concurrent connections.

2. Always atom

In a transaction either in whole command execution, or a command did not execute, redis transactions are atomic. EXEC command turns all executed transactions in order, if not before calling the multi command, client to server-side connection is disconnected, no action will be executed; if the EXEC command is executed, all operations will be performed . Using append-only file if the configuration, redis make a single write (2) syscall written into aof file. However, if the redis server crashes or is forced to kill off the administrator, then only part of the operation may be registered, in this case, redis when restart will find that this case failed to start and quit, reported an error. Then we should use redis-check-aof tool , the tool will repair the aof file, delete only part of the transaction, and then restart the redis can.

Open using transactions

1. 执行MULTI  # 开启事务， 返回OK或者其它
2. 执行多个命令  # 事务中的操作， 返回QUEUED，表明加入事务命令队列
3. EXEC  # 执行，返回每个事务中命令的返回结果列表

4. DISCARD 如果在EMULTI之后EXEC之前要关闭事务，再EXEC之前执行即可flush所有事务命令队列中的命令并关闭事务

Redis transaction error occurs

In the transaction, some operations may encounter or execution error, command execution errors are basically two:

1. EXEC wrong before

There is a mistake in front of the EXEC command, that command is not successfully added to the queue. Such as: command Wrong number of parameters, such as using the wrong command name.

For this error, client can be perceived, because while executing the command, in fact, added to the command queue, if successful return QUEUED instructions to join the other returns are wrong. This error, most client will automatically interrupt the transaction and DISCARD affairs. (Python was redis module, due to pipeline and multi / exec combined, redis.exceptions.ResponseError abnormal, but no abnormal command will still have to perform, that is due to a combination of pipeline)
However, after Redis 2.6.5, server will record cumulative error command to the command queue, then execution EXEC, server will refuse to execute the transaction and returns an error, automatically discard.

But before Redis2.6.5, for this error, server behavior is only executed successfully added to the command queue, the equivalent of a subset of the command set is executed once, despite the error occurred. Redis 2.6.5 server does not deal with this logic, but the logic is added to the new command is a command pipeline pipeline, the pipeline before the behavior can be achieved, the pipeline returns a list of results returned command.

After the error 2. EXEC

EXEC After execution error, such as the key conflict. For this error, the method does not handle all of the other commands will be executed, even if a new command error during the transaction.

Why is wrong does not support roll backs?

Like relational database, the transaction is rolled back support, and even support for mistakes in the redis affairs. redis reason why there is such behavior because it is two things:

1. redis command syntax error or failure will only be present in key modified into the wrong data type. These errors are very easy to find in the development or testing phase.
2. redis This should be simple and fast, you do not need to roll back capacity.

Redis firm refers only atomic only for the execution of the command to join the queue, Redis transaction does not support the rollback error during the execution of the command.

Redis optimistic locks for check-and-set

Concurrent transactions, will have to modify the same data time, although transaction because redis read threads isolated, but sometimes we need to lock data, exclusive use, only to lock our data using optimistic locking redis provided, this optimistic locking only with transactions use, check the behavior at the time of transaction execution EXEC, if there is a change, it performs back-EXEC failed. WATCH is used to provide CAS behavior for redis affairs. CAS that is, we often say optimistic locking.

Optimistic locking transaction fails, you must test results, failure would try again.

We know that 4 characteristics of the transaction ACID:

Atomic原子性： 事务中操作集，要么都成功，要么都失败回滚。
Redis事务所指的原子性仅仅只针对将命令加入执行队列的过程，Redis事务不支持在命令执行过程中的错误回滚。

Consistency 一致性： 事务前后，数据库是从一个一致性状态到另一个一致性状态。如转账前后总数是一致的。

Isolation 隔离性： 并发事务时，事务之间都不会由于访问同一数据而被干扰。在这个隔离层面讲，就有多种隔离级别，因为隔离级别时影响并发事务效率和数据安全性的，要在效率和安全间平衡是关键。隔离级别太严格，并发效率低，数据安全；隔离级别太低，又怕数据不安全。

Durability 持久性：事务一旦被提交，改变时永久的，即要持久化。很多都会将事务操作完后追加到操作日志文件中，数据者写入磁盘文件系统持久化。

WATCH command is used to monitor the change of key, key when the monitor if the modification occurred before the execution EXEC, then the transaction aborts, and returns a Null, indicating that the transaction failed. To lock the data available before the transaction. WATCH MULTI and with EXEC

Use UNWATCH can flush out all WATCHED keys.

summary

1. Redis atomic firm refers only to process only added to the command execution queue, Redis transaction does not support the rollback error during the execution of command
2. Data can watch using the optimistic locking. Optimistic cas, pessimistic for others and so on.