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