redis中事务机制及乐观锁的实现
在MySQL等其他数据库中，事务表示的是一组动作，这组动作要么全部执行，要么全部不执行。
Redis目前对事物的支持相对简单。Redis只能保证一个client发起的事务中的命令可以连续的执行，而中间不会插入其他的client命令。当一个client在一个链接中发出multi命令时，这个链接会进入一个事务上下文，该连接后续的命令不会立即执行，而是先放到一个队列中，当执行exec命令时，redis会顺序的执行队列中的所有命令。
Multi开启事务： 127.0.0.1:6379[1]>multi#开启事务 OK 127.0.0.1:6379[1]>setage15#数据操作命令 QUEUED 127.0.0.1:6379[1]>setage20#数据操作命令 QUEUED 127.0.0.1:6379[1]>exec#执行事务 1)OK 2)OK 127.0.0.1:6379[1]>getage "20" Discard：取消事务，该命令实际是清空事务队列中的命令并退出事务上下文，也就是事务回滚。 127.0.0.1:6379[1]>getage "20" 127.0.0.1:6379[1]>multi OK 127.0.0.1:6379[1]>setage25 QUEUED 127.0.0.1:6379[1]>setage30 QUEUED 127.0.0.1:6379[1]>discard#清空事务队列 OK 127.0.0.1:6379[1]>getage "20"
注意redis事务问题：通常事务队列中如果有一个事务失败则整个事务都会回滚，但在redis中其他事务命令不会回滚。
乐观锁：redis大多数是基于数据版本(version)的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个version字段来实现。在读取数据时，将此版本号一同读出，之后更新时对此版本号加1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行对比，如果提交的数据版本号大于数据库当前版本号，则予以更新，否则认为是过期数据。
watch监控：watch命令会监控给定的key，当exec时如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key，这样就对指定事务key加乐观锁了。注意watch的key是对整个链接有效的，事务也一样。如果链接断开，监视和事务都会被自动清除。当然exex、discard、unwatch命令都会自动清除链接中的所有监视。
在redis中对乐观锁的实现：
假设有一个age的key，我们开启两个session来对age进行赋值操作。
session1：
127.0.0.1:6379>getage "10" 127.0.0.1:6379>watchage#打开对age键的监控（监控其他操作是否对age键有修改操作） OK 127.0.0.1:6379>multi#开启事务上下文 OK
session2：
127.0.0.1:6379>setage20 OK 127.0.0.1:6379>getage "20"
在session2中直接操作age
再看session1：
127.0.0.1:6379>setage30#在session2中操作age后，我们在session1中继续操作age QUEUED 127.0.0.1:6379>exec#执行事务返回nil事务执行不成功。 (nil) 127.0.0.1:6379>getage "20"
在这里我们发现事务不能执行成功，这就是因为session1中的数据版本已经小于数据库中的数据版本。这就是redis中的乐观锁。
行百里者半九十。
总结
以上就是本文关于redis中事务机制及乐观锁的实现的全部内容，希望对大家有所帮助，感兴趣的朋友可以继续参阅本站：sqlserver:查询锁住sql以及解锁方法、几个比较重要的MySQL变量、MySQL主库binlog(master-log)与从库relay-log关系代码详解等，如有不足之处，欢迎留言指出，小编会及时回复大家并进行改正，感谢朋友们对本站的支持！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。