Redis 事务 & 消息队列

Redis 消息队列介绍

什么是消息队列

消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠传递，消息生产者只管把消息发布到消息队列中而不管谁来取，消息消费者只管从消息队列中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。

为什么使用消息队列

首先，我们可以知道，消息队列是一种异步的工作机制，比如说日志收集系统，为了避免数据在传输过程中丢失，还有订单系统，下单后，会生成对应的单据，库存的扣减，消费信息的发送，一个下单，产生这么多的消息，都是通过一个操作的触发，然后将其他的消息放入消息队列中，依次产生。再就是很多网站的，秒杀活动之类的，前多少名用户会便宜，都是通过消息队列来实现的。

这些例子，都是通过消息队列，来实现，业务的解耦，最终数据的一致性，广播，错峰流控等等，从而完成业务的逻辑。

其他消息队列软件产品

1）Rabbit-MQ（最初起源于金融系统，用于分布式系统中存储转发消息，OpenStack）

2）Zero-MQ（SaltStack）

3）Kafka（Java）

4）Redis（Key：value 数据库，缓存，消息队列）

Redis 消息队列模式

消息队列主要分为两种，这两种模式 Redis 都支持

生产者/消费者模式：生产者生产消息放到队列里，多个消费者同时监听队列，谁先抢到消息谁就会从队列中取走消息；即对于每个消息只能被最多一个消费者拥有；
发布者/订阅者模式：发布者生产消息放到队列里，多个监听队列的消费者都会收到同一份消息；即正常情况下每个消费者收到的消息应该都是一样的。

生产者 / 消费者模式

使用 LPUSH ， RPOP 可以模拟生产者消费者队列，一个消息只能读取一次。

发布者 / 订阅者模式

Runoob 发布 / 订阅模式，一个消息可以被多个订阅者接收。

Redis 事务

MySQL 事务处理

# 成功的事务

begin;

sql1;

sql2;

...

commit;

# 失败的事务

begin;

sql1;

sql2;

...

rollback;

Redis 事务处理

# 开启事务

MULTI

# 结束事务（执行所有事务块内的命令）

EXEC

# 取消事务（放弃执行事务块内的所有命令）

DISCARD

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

WATCH

# 取消监控

UNWATCH

Redis 事务的示例

# 使用事务执行

127.0.0.1:6379> MULTI

OK

127.0.0.1:6379> set k100 v100

QUEUED

127.0.0.1:6379> set k200 v200

QUEUED

127.0.0.1:6379> get k200

QUEUED

127.0.0.1:6379> EXEC

1) OK

2) OK

3) "v200"

# 事务取消

127.0.0.1:6379> MULTI

OK

127.0.0.1:6379> set k1 v1

QUEUED

127.0.0.1:6379> set k2 v2

QUEUED

127.0.0.1:6379> get k1

QUEUED

127.0.0.1:6379> DISCARD

OK

127.0.0.1:6379> keys *

(empty list or set)

# 监控一个key

127.0.0.1:6379> WATCH k1

OK

127.0.0.1:6379> MULTI

OK

127.0.0.1:6379> set k1 v1000000

QUEUED

# 另一个窗口修改k1

127.0.0.1:6379> set k1 00000

OK

# 回到第一个窗口提交事务

127.0.0.1:6379> EXEC

(nil)

127.0.0.1:6379> get k1

"00000"

Redis 事务的特性

原子性：不支持，不会回滚且（中间出错也会）继续执行

隔离性：支持，事务中的命令顺序，不会被打断，先 EXEC 先执行，单机 Redis 读写操作使用单进程单线程

持久性：不支持，Redis 数据容易丢失

一致性：不支持，要求通过乐观锁 Watch 来实现

Redis 事务一致性（乐观锁）

Redis 只支持乐观锁（依靠 Watch 实现）

事务（一个键或多个键）在不使用 Watch 监控时，谁后提交谁为准

事务（一个键或多个键）在使用 Watch 监控时，谁先提交谁为准

Watch 只监控一次事务并且是当前连接的事务