你了解Redis事务吗
说到事务,大家会立刻想到Mysql的事务,所谓的事务就是对数据进行一系列的操作,要么都执行成功,要么都执行失败,事务提供了原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),简称ACID。这些属性既包括了对事务执行结果的要求,也有对数据库在事务执行前后的数据状态变化的要求。那么Redis的事务能支持ACID吗?
ACID属性说明 原子性(Atomicity)事务中的全部操作在数据库中是不可分割的,要么全部完成,要么全部不执行。
一致性(Consistency)事务的执行使数据从一个状态转换为另一个状态,在事务开始之前和事务结束之后,数据库的完整性约束没有被破坏。
隔离性(Isolation)事务的隔离性要求每个读写事务的对象对其他事务的操作对象相互分离,即该事务提交前对其他事务都不可见。
持久性(Durability)数据库执行事务后,数据的修改要被持久化保存下来。当数据库重启后,数据的值需要是被修改后的值。
Redis如何实现事务Redis事务的执行包含了三个步骤,具体如下:
客户端把事务中本身要执行的具体操作(例如增删改数据)发送给服务器端。这些操作就是Redis 本身提供的数据读写命令,虽然这些命令被客户端发送到了服务器端,但是Redis实例只是把这些命令暂存到一个命令队列中,并不会立即执行。
Redis执行EXEC命令执行事务提交,服务器端收到EXEC命令后,才会实际执行命令队列中的所有命令。
EXEC:提交事务,执行命令队列中所有的操作命令。 DISCARD:放弃一个事务,清空命令队列,但是无法支持事务的回滚。 WATCH:检测一个或多个键的值在事务执行的期间是否发生变化,如果发生变化,那么当前事务放弃执行。 Redis的事务如何支持ACID Redis事务的支持原子性吗? 情况一:执行事务在入队时就报错,那么Redis会放弃事务执行,从而保证事务原子性。 情况二:命令在入队时没报错,但是实际执行时却报错,无法保证事务原子性。
情况一示例说明
127.0.0.1:6379 multiOK
127.0.0.1:6379 set t1 v1
QUEUED
127.0.0.1:6379 set t2 v2
QUEUED
127.0.0.1:6379 setget t3
(error) ERR unknown command setget
127.0.0.1:6379 set t4 v4
QUEUED
127.0.0.1:6379 exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379 get t4
(nil)
说明:在执行exec命令之前,如果发生语法错误(使用了不存在的命令),那么命令入队时,Redis就会报错并且记录错误,等到执行Exec命令之后,Redi会拒绝所有提交的命令,事务执行失败。这种情况Reids的事务是可以支持原子性。
情况二示例说明
127.0.0.1:6379 multiOK
127.0.0.1:6379 incr s2
QUEUED
127.0.0.1:6379 set a1 v1
QUEUED
127.0.0.1:6379 set a2 v2
QUEUED
127.0.0.1:6379 exec
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
127.0.0.1:6379 get a2
说明: s2的值为v2,当执行incr命令时报报错,因为incr只能新增integer的类型值,但是这种情况下我们发现Redis的事务没有进行回滚,后面的命令能够执行成功,所以这种情况下时无法保证事务的原子性。
Redis事务的支持一致性吗? 情况一:命令入队时就报错针对第一种情况,事务本身就会被放弃执行,所以可以保证事务的一致性。
情况二:命令入队时没报错,实际执行时报错针对第二种情况,有错误的命令不会被执行,正确的命令可以正常执行,也不会改变数据库的一致性。
情况三:Exec执行命令Redis实例发生故障如果Redis持久化设置为RDB,那么生成RDB快照不会在事务执行时执行,所以事务命令操作的结果不会被保存到RDB快照中,使用RDB快照进行恢复时,数据库里的数据也是一致的。
如果Reids持久化设置为AOF,而事务操作还没有被记录到AOF日志时,实例就发生了故障,那么,使用AOF日志恢复的数据库数据是一致的。如果只有部分操作被记录到了AOF日志,我们可以使用 redis-check-aof 清除事务中已经完成的操作,数据库恢复后也是一致的。
Redis事务的支持隔离性吗?
Redis实现事务的隔离性,需要通过watch命令来支持事务隔离性。Watch的原理是,在事务执行前,监控一个或者多个键的变化时,当事务调用EXEC命令执行时,WATCH机制会先检查监控的键是否被其它客户端修改了。如果修改了监听的值,就放弃事务执行,避免事务的隔离性被破坏。
示例说明
客户端1:
127.0.0.1:6379 get blance100
127.0.0.1:6379 watch blance
OK
127.0.0.1:6379 multi
OK
127.0.0.1:6379 decrby blance 10
QUEUED
127.0.0.1:6379 incrby blance 10
QUEUED
127.0.0.1:6379 exec
(nil)
客户端2:
127.0.0.1:6379 get blance100
127.0.0.1:6379 set blance 90
OK
127.0.0.1:6379 get blance
说明:客户端1使用watch检测balance,在开启事务后,在客户端2执行更改balance的值操作,模拟其他客户端在事务执行期间更改watch监控的数据,然后再执行客户端1的EXEC命令,发现事务未成功执行。
Redis事务的支持持久性吗?Redis的事务无法支持持久性,如果Redis使用了RDB模式,一个事务执行后,当下一次的RDB快照还未执行前,Redis发生了实例宕机,那么这种情况下,事务修改的数据是无法保证持久化的,如果Redis采用AOF模式,如论持久化配置为no、everysec和always都可能会存在数据丢失,所以,不管 Redis采用那种持久化模式,事务的持久性都无法支持。
本文对Redis的事务进行详细的讲解,Redis对于事务的支持还是有限制的,所以大家在使用的过程中需要注意。
到此这篇关于你了解Redis事务吗的文章就介绍到这了,更多相关Redis 事务内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
我想要获取技术服务或软件
服务范围:MySQL、ORACLE、SQLSERVER、MongoDB、PostgreSQL 、程序问题
服务方式:远程服务、电话支持、现场服务,沟通指定方式服务
技术标签:数据恢复、安装配置、数据迁移、集群容灾、异常处理、其它问题
本站部分文章参考或来源于网络,如有侵权请联系站长。
数据库远程运维 你了解Redis事务吗
相关文章
- 事务Redis不支持事务:一个潜在的风险(redis不支持)
- Redis安装之旅:编译安装篇(redis编译安装)
- Redis连接异常:解决方案(redis连接不上)
- Redis:处理值过大的挑战(redis值过大)
- 深入了解Redis集群指令,提高数据存储效率(redis集群指令)
- 深入了解Redis运行状态(redis运行状态查看)
- 一步一步了解如何获取Redis日志(获取redis日志)
- 对深入了解Redis获取所有的键值对(获取redis所有的键值)
- 离线安装Redis哨兵让你了解一个安全的过程(离线安装redis哨兵)
- 深入了解Redis查看连接IP地址(查看redis连接ip)
- 从简单百度操作Redis了解它的神奇(百度 redis操作)
- 深入了解Redis查看Redis详细日志(查看redis详细日志)
- 查看Redis日志让你快速了解系统状态的必备技能(查看redis log)
- 普罗米修斯借助Redis追求更高效率(普罗米修斯与redis)
- 利用Redis实现数据优化更新(整合redis修改数据)
- 了解云端Redis云技术实现动态优化(云redis是什么意思)
- 为何要使用Redis了解高效存储的优越性(为何会使用redis)
- 了解Redis,实现快速存取(先读redis)
- 深入了解Redis如何查看Redis目录(如何查看redis目录)
- 通过Redis提升高并发性能(处理高并发性能redis)
- 深入探索Redis的事务机制(场景redis的事务机制)
- 深入了解Redis的键值类型(redis键名是什么类型)
- 了解Redis锁,超时也不要紧(redis锁 超时)
- 重启集群,重新激活Redis之火(redis重新激活集群)
- Redis连接池耗尽谨防网络堵塞(redis连接池被耗尽)
- 深入了解Redis的连接数管理机制(redis连接数不对)
- Redis访问量了解多大的可能性(redis访问量有多大)
- Redis订阅端出现报错处理失败(redis订阅端报错)
- 深入了解Redis探究资源消耗情况(redis资源消耗查看)