Redis事务、pub/sub、PipeLine-管道、benchmark性能测试详解

本文详细介绍了Redis的事务特性,包括其非原子性、流程和命令,以及不支持回滚的原因。此外,还探讨了发布订阅(pub/sub)功能,解释了相关指令和实操示例。同时,阐述了Redis的PipeLine技术,讨论了其在网络传输上的优势。最后,通过benchmark工具展示了不同环境下Redis的性能测试结果。
摘要由CSDN通过智能技术生成

一. 事务

1. 概念补充

(1). 原子性

一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被恢复(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。

2. redis事务说明

 Redis的事务并不是我们传统意义上理解的事务,我们都知道 单个 Redis 命令的执行是原子性的,但 Redis 没有在事务上增加任何维持原子性的机制,所以 Redis 事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本,但批量指令并非原子化的操作,中间某条指令的失败不会导致前面已做指令的回滚,也不会造成后续的指令不做。

总结:

 (1). Redis事务中如果有某一条命令执行失败,之前的命令不会回滚,其后的命令仍然会被继续执行→ →鉴于这个原因,所以说redis的事务严格意义上来说是不具备原子性的。

 (2). Redis事务中所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。

 (3). 在事务开启之前,如果客户端与服务器之间出现通讯故障并导致网络断开,其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后,那么该事务中的所有命令都会被服务器执行。

 (4). 当使用Append-Only模式时,Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃,如电源故障导致的宕机,那么此时也许只有部分数据被写入到磁盘,而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测,一旦发现类似问题,就会立即退出并给出相应的错误提示。此时,我们就要充分利用Redis工具包中提供的redis-check-aof工具,该工具可以帮助我们定位到数据不一致的错误,并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

3. 流程/指令

(1)multi 开启事务

(2)大量指令入队

(3)exec执行事务块内命令,截止此处一个事务已经结束。

(4)discard 取消事务

(5)watch 监视一个或多个key,如果事务执行前key被改动,事务将打断。unwatch 取消监视。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值