redis watch使用场景_redis事务、并发及应用场景

事务概念

事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。

redis事务是一组命令的集合。多组命令进入到等待执行的事务队列中,执行exec命令告诉redis将等待执行的事务队列中的所有命令,按顺序执行,返回值就是这些命令组成的列表。

Redis 事务可以一次执行多个命令, 具有下列保证:

批量操作在发送 EXEC 命令前被放入队列缓存。

收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行。

在事务执行过程,其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段:

开始事务。

命令入队。

执行事务。

事务中的错误:

事务在执行 EXEC 之前,入队的命令可能会出错。比如说,命令可能会产生语法错误(参数数量错误,参数名错误,等等),或者其他更严重的错误,比如内存不足(如果服务器使用 maxmemory 设置了最大内存限制的话)。

命令可能在 EXEC 调用之后失败。举个例子,事务中的命令可能处理了错误类型的键,比如将列表命令用在了字符串键上面,诸如此类。

从 Redis 2.6.5 开始,服务器会对命令入队失败的情况进行记录,并在客户端调用 EXEC 命令时,拒绝执行并自动放弃这个事务

在 EXEC 命令执行之后所产生的错误, 并没有对它们进行特别处理: 即使事务中有某个/某些命令在执行时产生了错误, 事务中的其他命令仍然会继续执行

如:

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set a 3

QUEUED

127.0.0.1:6379> lpop a

QUEUED

127.0.0.1:6379> exec

1) OK

2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

redis 事务入队只会检查语法错误,对于exec后执行错误,没有回滚措施。而且在事务中无法在客户端做查询判断,只会得到queued,无法进行业务数据判断,也是很坑。

原子性

一个事务是一个不可分割的最小工作单位,要么都成功要么都失败。

原子操作是指你的一个业务逻辑必须是不可拆分的.比如你给别人转钱,你的账号扣钱,别人的账号增加钱。

单个 Redis 命令的执行是原子性的,但 Redis 没有在事务上增加任何维持原子性的机制,所以 Redis 事务的执行并不是原子性的。

看看下面几个原子性的命令:

HINCRBY key field increment 为哈希表 key 中的域 field 的值加上增量 increment

增量也可以为负数,相当于对给定域进行减法操作。

如果 key 不存在,一个新的哈希表被创建并执行 HINCRBY 命令。

如果域 field 不存在,那么在执行命令前,域的值被初始化为 0

SETNX key value 只在键 key 不存在的情况下, 将键 key 的值设置为 value;若键 key 已经存在, 则 SETNX 命令不做任何动作。

事务命令

包含5个命令 MULTI、EXEC、DISCARD、WATCH、UNWATCH。

DISCARD 取消事务,放弃执行事务块内的所有命令。

EXEC 执行所有事务块内的命令。

MULTI 标记一个事务块的开始。

UNWATCH 取消 WATCH 命令对所有 key 的监视。

WATCH key [key ...] 监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。

乐观锁

乐观的认为数据不会出现冲突,使用version或timestamp来记录判断。乐观锁的优点开销小,不会出现锁冲突。

可利用watch命令监听key,实现乐观锁,来保证不会出现冲突,应用场景比如秒杀来防止超卖。

秒杀伪代码如下:

WATCH 锁定量

MULTI

incr 锁定量

if 锁定量 <= 库存量

减库存

EXEC

悲观锁

了解下相关命令

SETNX(SET if Not eXists) key value 只在键 key 不存在的情况下, 将键 key 的值设置为 value,返回值:命令在设置成功时返回 1 , 设置失败时返回 0

INCR KEY 为键 key 储存的数字值加上一。

如果键 key 不存在, 那么它的值会先被初始化为 0 , 然后再执行 INCR 命令。

如果键 key 储存的值不能被解释为数字, 那么 INCR 命令将返回一个错误。

命令会返回键 key 在执行加一操作之后的值

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Redis可以通过使用事务或Lua脚本来实现高并发下的抢购/秒杀功能。 1. 使用事务:抢购/秒杀的过程可以看做是一个先检查库存是否充足,再扣减库存的过程。使用Redis事务可以保证这个过程是原子性的,即要么全部成功,要么全部失败。 具体实现方法如下: - 使用MULTI命令开启一个事务。 - 使用WATCH命令对库存进行监视(即设置监视器)。 - 使用GET命令获取当前库存。 - 判断库存是否充足,如果充足,则使用DECRBY命令扣减库存。 - 使用EXEC命令提交事务,如果提交成功,则说明扣减成功,否则说明被其他线程抢先扣减了库存。 示例代码如下: ```python def decrease_stock(redis_conn, stock_key): with redis_conn.pipeline() as pipeline: while True: try: pipeline.watch(stock_key) stock = int(pipeline.get(stock_key)) if stock > 0: pipeline.multi() pipeline.decr(stock_key) pipeline.execute() return True else: return False except WatchError: continue ``` 2. 使用Lua脚本:Lua脚本可以在Redis端原子性地执行多个命令,可以减少网络开销和锁竞争的问题。 具体实现方法如下: - 编写一个Lua脚本,该脚本首先使用GET命令获取当前库存,如果库存充足,则使用DECRBY命令扣减库存,否则返回0。 - 在Python中使用Redis的EVAL命令执行该Lua脚本。 示例代码如下: ```python def decrease_stock(redis_conn, stock_key): script = """ local stock = tonumber(redis.call('GET', KEYS[1])) if stock > 0 then redis.call('DECRBY', KEYS[1], 1) return 1 else return 0 end """ result = redis_conn.eval(script, 1, stock_key) return bool(result) ``` 以上两种方法都可以实现高并发下的抢购/秒杀功能,但是使用Lua脚本的方法效率更高,因为在Redis端执行命令可以减少网络开销和锁竞争的问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值