python redis事务源码及应用分析

在多个客户端同时处理相同的数据时，不谨慎的操作很容易导致数据出错。一般的关系型数据库中有事务保证了数据操作的原子性，同样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中的相应方法。

# 1redis = Redis(host='127.0.0.1', port=6379)
pipe = redis.pipeline()# 2pipe = 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。

作者：rainybowe
链接：https://www.jianshu.com/p/32bf08e885b0