在多个客户端同时处理相同的数据时，不谨慎的操作很容易导致数据出错。一般的关系型数据库中有事务保证了数据操作的原子性，同样Redis中也设置了事务，可以理解为“将多个命令打包，然后一次性、按顺序执行”，防止数据出错，同时提升性能。
Redis事务
关系型数据库中，要使用事务，首先向数据库服务器发送BEGIN，然后执行各个相互一致的写操作和读操作，最后，用户可以选择发送COMMIT来确认之前所做的修改，或者发送ROLLBACK来放弃那些修改。
同样，Redis中也有简单的方法处理一连串相互一致的读操作和写操作。首先是以MULTI命令开始事务，后续跟着一连串命令，最后以EXEC结束事务或者以DISCARD命令撤销所有命令并结束事务。Redis官方文档中对于事务以及事务常用命令做了详细介绍。
事务原子性
Redis事务中的所有命令能够保证被顺序执行(FIFO)，中间不会被其他客户端打断。它本身应对外部请求是单任务的，也是多线程安全的。关系型数据库的事务具有原子性特点，而Redis事务就没法确定说是原子性的。看一下官方文档中Errors inside a transaction一节，事务中有两种command errors：
- 一种是在
MULTI之后，EXEC执行之前，由于命令的语法错误或者服务器内存不够等原因，命令根本不会被放入暂存队列，Redis会拒绝执行接下来的EXEC操作，这和我们理解的原子性原理是一致的； - 另外一种是在
EXEC之后，当队列中的某条命令执行失败，Redis也会继续执行完其他命令，且不支持回滚，最关键的地方反而还不支持原子性！
Redis官方文档中对其不支持回滚的特性也做了说明，Redis命令只会在语法错误或者对某个Key执行了不属于该类型的相应操作，而这些错误应该是在开发过程中就避免的 = =；Reids也正是因为不支持回滚所以才能更简单快速（好傲娇~）
所以我们在使用Redis事务过程中一定要注意：Redis事务所指的原子性仅仅只针对将命令加入执行队列的过程，Redis事务不支持在命令执行过程中的错误回滚。《Redis设计与实现》中对Redis事务的ACID特性做了全面的讲解。
Redis事务锁Watch
Watch是Redis提供的事务锁，是一种乐观锁。在MULTI命令之前执行WATCH命令，当EXEC提交之后，在实际执行任何命令之前，如果发现被Watched的key值发生了改变，整个事务被丢弃，返回为空。
个人理解，使用Redis事务结合Watch命令，只是能保证在事务内被watched的key不会被重复错误修改，一定程度上能够保证原子性，但也只是针对被watched的key。
Python Redis事务
python中通过管道Pipeline实现Redis事务。当我们要使用事务时，首先实例化一个Pipeline类，可以先实例化StrictRedis类，然后调用实例的pipeline()方法；也可以直接实例化Pipeline类。两种方法都会创建BasePipeLine实例。Redis事务中对应的MULTI， EXEC, DISCARD, WATCH操作都对应到BasePipeLine中的相应方法。
# 1
redis = Redis(host='127.0.0.1', port=6379)
pipe = redis.pipeline()
# 2
pipe = Pipeline(host='127.0.0.1', port=6379)
在python中使用事务的流程也基本不变，建立Pipeline以后，调用multi()方法，表示事务开始，然后依次执行所有redis命令，然后调用execute()方法提交事务。同样在事务开始之前，可以调用watch()方法监控keys。
try:
pipe.watch('key1')
pipe.multi()
pipe.set('key2', 2)
pipe.incr('key1')
pipe.set('key3', 3)
pipe.execute()
except redis.exceptions.WatchError:
# 发生watcherror时业务应该怎样处理，丢弃事务或者重试
pass
看一下python中execute()方法的源码：
def execute(self, raise_on_error=True):
"Execute all the commands in the current pipeline"
stack = self.command_stack
if not stack:
return []
if self.scripts:
self.load_scripts()
if self.transaction or self.explicit_transaction:
execute = self._execute_transaction
else:
execute = self._execute_pipeline
conn = self.connection
if not conn:
conn = self.connection_pool.get_connection('MULTI',
self.shard_hint)
# assign to self.connection so reset() releases the connection
# back to the pool after we're done
self.connection = conn
try:
return execute(conn, stack, raise_on_error)
except (ConnectionError, TimeoutError) as e:
conn.disconnect()
if self.watching:
raise WatchError("A ConnectionError occured on while watching "
"one or more keys")
return execute(conn, stack, raise_on_error)
finally:
self.reset()
命令执行后，程序会捕获ConnectionError和TimeoutError，当连接超时并且没有设置重试retry_on_timeout参数，异常直接抛出，否则会进行一次重试。最终调用reset()重置所有参数。
redis-benchmark
Pipeline能够将一堆命令先收集起来，再一起发送给Redis服务器处理，减少了和Redis的连接通信次数。但当Pipeline中命令的数量过大，管道中所有命令和执行结果会被缓存到Redis内存，同时也会造成网络通信变慢，得不偿失。那么，Pipeline每次接收的命令数量是多少才能达到最优的执行效率(How many commands could redis-py pipeline have?)？
Redis提供了redis-benchmark命令，模拟N个客户端同时发送M条命令，并返回执行统计结果。我们可以通过参数设置模拟客户端数量，请求总数，是否使用Pipeline以及Pipeline中命令数量，指定命令类型等。
首先模拟无Pipeline情况下执行情况，假设给定100000条请求，模拟get和set请求，执行结果如下。普通情况下，平均每秒执行102145.05条SET请求，平均每秒执行98716.68条GET请求。
$ redis-benchmark -n 100000 -t set,get -q
SET: 102145.05 requests per second
GET: 98716.68 requests per second
加入Pipeline，每个Pipeline执行100条命令，执行结果如下。执行效率显著提高了，尤其是对于GET请求。
$ redis28-benchmark -n 100000 -t set,get -P 100 -q
SET: 552486.19 requests per second
GET: 800000.00 requests per second
如果把Pipeline的最大执行命令数设置到10000，执行结果如下。这种情况下，对效率没有显著提升了，而且如果每条命令数据所占的字节数变大，执行效率更低。
$ redis-benchmark -n 100000 -t set,get -P 10000 -q
SET: 118764.84 requests per second
GET: 150602.42 requests per second
到底应该把Pipeline的命令数设置为多大才合适，没有确定的答案，有的人给的建议是100-1000，具体设置为多大需要在当前Redis连接状况，Redis内存大小等基础上不断测试找到那个sweet spot。
