页面好看的教育类网站模板,wordpress zend,wap网站用什么开发,网站建设文章官网目录
1.1 发布订阅
1.1.1 什么是发布订阅
1.1.2 常用命令
1.1.3 示例演示
1.2 事务管理
1.2.1 事务定义
1.2.2 Multi、Exec、discard
1.2.3 示例
1.2.4 事务的错误处理
1.2.5 事务的冲突问题
1.2.5.1 事务场景
1.2.5.2 悲观锁
1.2.5.3 乐观锁
1.2.5.4 事务解决冲…目录
1.1 发布订阅
1.1.1 什么是发布订阅
1.1.2 常用命令
1.1.3 示例演示
1.2 事务管理
1.2.1 事务定义
1.2.2 Multi、Exec、discard
1.2.3 示例
1.2.4 事务的错误处理
1.2.5 事务的冲突问题
1.2.5.1 事务场景
1.2.5.2 悲观锁
1.2.5.3 乐观锁
1.2.5.4 事务解决冲突WATCH
1.2.5.5 unwatch
1.2.6 Redis事务的三个特征 1.1 发布订阅
1.1.1 什么是发布订阅 Redis发布订阅pub/sub是一种消息通信模式发送者pub发送消息订阅者sub接收消息。Redis客户端可以订阅任意数量的频道 当有新的消息通过 PUBLISH 命令发送给频道 channel1 时这个消息就会被发送给订阅的三个客户端 1.1.2 常用命令
命令语法描述PSUBSCRIBE pattern [pattern......]订阅一个或多个符合给定模式的频道PUBSUB subcommand [argument [argument...]]查看订阅与发布系统的状态PUBLISH channel message将信息发送到指定的频道PUNSUBSCRIBE [pattern [pattern......]]退订所有给定模式的频道SUBSCRIBE channel [channel......]订阅给定的一个或者多个频道信息UNSUBSCRIBE [channel [channel......]]退订给定的频道
1.1.3 示例演示
创建四个客户端Cli_1~Cli4
#cli1 创建订阅的频道redisChat
127.0.0.1:6379 SUBSCRIBE redisChat
Reading messages... (press Ctrl-C to quit)
1) subscribe
2) redisChat
3) (integer) 1#cli2 在同一频道redisChat 发布消息
127.0.0.1:6379 PUBLISH redisChat SendMessage_1
(integer) 1
#此处可切换到 cli1内查看是否读取到cli2发布的消息#cli3 在同一频道redisChat 发布消息
127.0.0.1:6379 PUBLISH redisChat SendMessage_2
(integer) 1
#此处可切换到 cli1内查看是否读取到cli3发布的消息#cli4 创建订阅的频道redisChat
127.0.0.1:6379 SUBSCRIBE redisChat
Reading messages... (press Ctrl-C to quit)
1) subscribe
2) redisChat
3) (integer) 1#cli3 在同一频道redisChat 发布消息
127.0.0.1:6379 PUBLISH redisChat SendMessage_2
(integer) 1
#此处可切换到 cli1及cli4内查看是否读取到cli3发布的消息
cli1收到3条信息 分别来自于 cli2一次 以及 cli3两次
cli4收到1条信息 cli3一次
1.2 事务管理
1.2.1 事务定义 Redis事务是一个单独的隔离操作事务中的所有命令都会序列化、按顺序地执行行。事务在执行的过程中不会被其他客户端发送来的命令请求所打断 Redis 事务的主要作用就是串联多个命令防止别的命令插队
1.2.2 Multi、Exec、discard 从输入Multi命令开始后面输入的数量命令都会一次进入到命令队列当中但是不会执行直到输入Exec后Redis会将之前的命令队列中的命令依次执行 组队过程中可以通过 discard 来放弃组队 Redis的事务可以一次执行多条命令 批量操作在发送 Exec 命令前被放入队列缓存 收到 Exec 命令后进入事务执行如果事务中有任意命令执行失败其余的命令依旧会执行 在事务的执行过程中会按照顺序串行化执行队列中的命令其他客户端提交的命令请求不会插入到事务执行的命令序列中
1.2.3 示例
#组队阶段成功、提交成功的情况
127.0.0.1:6379 multi
OK
127.0.0.1:6379(TX) set k1 v1
QUEUED
127.0.0.1:6379(TX) set k2 v2
QUEUED
127.0.0.1:6379(TX) exec
1) OK
2) OK#组队阶段报错、提交必然报错(所有数据全部回滚)
127.0.0.1:6379 multi
OK
127.0.0.1:6379(TX) set k3 v3
QUEUED
127.0.0.1:6379(TX) set k4
(error) ERR wrong number of arguments for set command
127.0.0.1:6379(TX) set k5 v5
QUEUED
127.0.0.1:6379(TX) exec
(error) EXECABORT Transaction discarded because of previous errors.#组队阶段成功、提交时发现组队命令有异常
127.0.0.1:6379 multi
OK
127.0.0.1:6379(TX) set k3 v3
QUEUED
127.0.0.1:6379(TX) incr k3
QUEUED
127.0.0.1:6379(TX) set k4 v4
QUEUED
127.0.0.1:6379(TX) get k3
QUEUED
127.0.0.1:6379(TX) exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
4) v3
1.2.4 事务的错误处理 组队时某个命令出现了错误报告执行时整个的队列都会被取消 执行时某个命令报错则只有报错的命令不会被执行而其他命令都会执行不会回滚 1.2.5 事务的冲突问题
1.2.5.1 事务场景 有一账户余额为10000元现在出现三个请求第一个请求想给金额-8000元第二个请求想给金额-5000元第三个请求想给金额-1000元 如果没有事务管理则有可能出现如下场景 1.2.5.2 悲观锁 悲观锁(Pessimistic Lock)顾名思义就是很悲观。每次去拿数据时都认为别人会修改所以在每次拿数据时都会上锁这样别人想拿到这个数据就会停顿直到它拿到锁为止。在传统的关系型数据库内就会用到这种锁机制比如 行锁 表锁 读锁 写锁都是在操作之前先进行上锁处理 1.2.5.3 乐观锁 乐观锁(Optimistic Lock)顾名思义就是很乐观。每次去拿数据的时候都认为别人不会修改所以不会上锁但是在更新的时候会判断一下在此期间别人有没有去更新这个数据可以使用版本号等机制。乐观锁适用于多读的应用类型这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的 1.2.5.4 事务解决冲突WATCH 在执行multi之前先执行 watch key1 [key2 ....] 用于指定key的监视如果在事务执行前这些key被其他命令锁改动那么事务将被打断
#cli1
set money 10000
#cli2
127.0.0.1:6379 watch money
OK
127.0.0.1:6379 multi
OK
127.0.0.1:6379 decrby money 8000
QUEUED
#cli3
127.0.0.1:6379 watch money
OK
127.0.0.1:6379 multi
OK
127.0.0.1:6379 decrby money 3000
QUEUED#cli2
exec
#cli3
exec
1.2.5.5 unwatch 用于取消命令对所有key的监视 如果在执行 watch 命令之后Exec 或 DisCard 命令先被执行的话那么就不需要再次执行 unwatch
1.2.6 Redis事务的三个特征
单独的隔离操作事务中所有命令都会序列化按顺序执行。事务在执行过程中不会被其他客户端发来的请求所打断没有隔离级别的概念队列中的命令没有提交前都不会被实际执行因为事务提交前所有指令都是处于等待状态不保证原子性事务中如果有一条命令执行失败其后命令以及会执行并且不会回滚
