消息队列概念

什么是Redis的消息订阅

进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。特别的说一句，一般的企业中消息中间件(e.g Active queue肯定是不会用Redis的消息订阅来做的，至于Redis为什么会推出这样一个功能点，可能有潜在的意义比如会优化完善这部分的功能以使之晋升为消息中间件的一个选择，也有可能只是意思意思做这么一个功能已配合Redis的其他功能。不过通过对Redis迭代的版本上看，个人认为Redisa的消息定于只是为了配合其他Redis的功能。)

-Subscript / publish Model(订阅发布模型图)

• Subscript

• Publish

- Redis 消息的订阅和发布

我们将真实的模拟Redis的消息订阅和发布。

• 消息订阅发布的常用命令解读

PSUBSCRIBE pattern [pattern …] 订阅一个或多个符合给定模式的频道。

PUBSUB subcommand [argument [argument …]] 查看订阅与发布系统状态。

PUBLISH channel message 将信息发送到指定的频道。

PUNSUBSCRIBE [pattern [pattern …]] 退订所有给定模式的频道。

SUBSCRIBE channel [channel …] 订阅给定的一个或多个频道的信息。

UNSUBSCRIBE [channel [channel …]] 退订给定的频道。

• Subscript / Publish

A客户端订阅3个Channel(c1,c2,c3)

B客户端在c1上发布一侧消息：Hi-Redis

A客户端收到B客户端发布的消息

小结

任何时候若使用Redis的消息订阅请记住一个原则，先订阅在发布，其次就是要清楚地定位Redis的消息订阅/发布在自己应用中的定位。

消息订阅/发布的一般流程

1 可以一次性订阅多个，SUBSCRIBE c1 c2 c3

2 消息发布，PUBLISH c2 hello-redis

3 订阅多个，通配符， PSUBSCRIBE new

4 收取消息， PUBLISH new1 redis2015

Redis事务概念

作为一个应用场景为缓存的Nosql，Redis 包含了事务的概念，可实际上Redis提供的事务不论从概念和实现程度上而言与一些 RDBMS 如Oracle、Mysql(Default as Innor DB Engine)的事务有着概念部分交叉，实现程度截然不同的区别。下面我们就来看看Redis的事务。

RDBMS Transaction(传统关系型数据库的事务)

传统关系型数据一般包含事务特性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

原子性（Atomicity）

整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性（Consistency）

指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。

隔离性（Isolation，又称独立性）

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。(关于事务的隔离级别我们将在Mysql 高级本分详细讲解)。

持久性（Durability）

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

Redis Transaction

Redis Txn. 是什么？

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。

Redis Txn. 能干嘛？

一个队列中，一次性、顺序性、排他性的执行一系列命令。

Redis Txn. Core Conception.

Redis Txn.常用命令

MULTI

标记一个事务块的开始。

EXEC

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

DISCARD

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

WATCH key [key …]

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

UNWATCH

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

Redis Txn. 常遇到的4种Case。

下面我总结一下我们在使用Redis时常遇到的几种情况。

• 正常执行

正常使用Redisa Txn.即Redis 命令没有错误，能够将命令加入队列。

• 放弃事务

在开启事务，且命令入队了以后需要取消或者放弃事务。(常用于业务逻辑中)。

• 全体连坐

开启事务，当队列中出现命令执行错误时，Redis将放弃整个事务。示例如下：

• 冤头债主

开启事务，队列中无命令错误，在执行Redis Txn.出现错误，此时无法执行成功的命令将会回滚，其他的命令依旧执行，如下图所示。

Watch 监控(Redis的‘锁’的概念)

在传统的RDBMS 中有表锁行锁的概念，已Mysql 两种 Engie为例子：

MyISM：表所，不支持高并发，不支持事务…

Innor DB：行锁，支持高并发，支持事务….

Redis 的 Watch

WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，所以在MULTI命令后可以修改WATCH监控的键值）。

悲观锁/乐观锁/CAS(Check And Set)

悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁

乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，乐观锁策略:提交版本必须大于记录当前版本才能执行更新。

CAS

CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。

CAS顶多算是乐观锁写那一步操作的一种实现方式罢了，不用CAS自己加锁也是可以的。

Redis Watch 执行过程以及例子

以 初始化信用卡可用余额和欠额为例子

无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内

有加塞篡改，监控了key，如果key被修改了，后面一个事务的执行失效

unwatch

一旦执行了exec之前加的监控锁都会被取消掉了

Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行。

例子

小结

通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

• Redis Txn. 的三个阶段

1. 开启：以MULTI开始一个事务。
2. 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面。
3. 执行：由EXEC命令触发事务。

• Redis Txn. 的三个特性

1. 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
3. 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。