1. Redis实现消息队列有两种方式
Redis能做消息队列得益于他list对象blpop/brpop接口以及Pub/Sub(发布/订阅)的某些接口。他们都是阻塞版的，所以Redis实现消息队列有两种方式：
- 通过数据结构list来实现
- 通过pub/sub来实现
另外redis存放的数据都只能是string类型，所以在任务传递的时候只能是传递字符串。我们可以将消息在发布者序列化成json格式的字符串，然后消费者那边再转换一下即可。
2. 通过数据结构list来实现
2.1 实现机制
消息接收：
redis> brpop tasklist 0
“im task 01”
这个例子使用blpop命令会阻塞方式地从tasklist列表中取头一个数据，最后一个参数就是等待超时的时间。如果设置为0则表示无限等待。
消息发送：
redis> lpush tasklist ‘im task 01’
redis> lpush tasklist ‘im task 02’
2.2 优点
- 能够实现持久化
采用 Master－Slave 数据复制模式。队列操作都是写操作，Master任务繁重，能让Slave分担的持久化工作，就不要Master做。RDB和AOF两种方法都用上，多重保险。 - 支持集群
- 接口使用简单
2.3 不足
- Redis上消息只会被一个消费者消费，不会有多个订阅者消费同一个消息，简单一对一
- 生产者或者消费者崩溃后的处理机制，需要自己实现
- 生产者写入太快，消费者消费太慢，导致Redis的内存问题，处理机制需要自己实现
2.4 应用场景
3. 通过pub/sub来实现
3.1 实现机制
订阅，取消订阅和发布实现了发布/订阅消息范式，发布者不是计划发送消息给特定的订阅者。而是发布的消息分到不同的频道，不需要知道什么样的订阅者订阅。订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道什么样的发布者发布的。
这是一种基于非持久化的消息机制，消息发布者和订阅者必须同时在线，否则一旦消息订阅者由于各种异常情况而*断开连接，在其重新连接后，其离线期间的消息是无法被重新通知的（即发即弃）。
Redis中的消息可以提供两种不同的功能。一类是基于Channel的消息，这一类消息和Redis中存储的Keys没有太多关联，也就是说即使不在Redis中存储任何Keys信息，这类消息也可以独立使用。另一类消息可以对（也可以不对）Redis中存储的Keys信息的变化事件进行通知，可以用来向订阅者通知Redis中符合订阅条件的Keys的各种事件。
3.2 优点
- 一个生产者能够对应多个消费者
- 支持集群
- 接口使用简单
3.3 不足
Redis提供的订阅/发布功能并不完美，更不能和ActiveMQ/RabbitMQ提供的订阅/发布功能相提并论。
首先这些消息并没有持久化机制，属于即发即弃模式。也就是说它们不能像ActiveMQ中的消息那样保证持久化消息订阅者不会错过任何消息，无论这些消息订阅者是否随时在线。
- 由于本来就是即发即弃的消息模式，所以Redis也不需要专门制定消息的备份和恢复机制。
- 也是由于即发即弃的消息模式，所以Redis也没有必要专门对使用订阅/发布功能的客户端连接进行识别，用来明确该客户端连接的ID是否在之前已经连接过Redis服务了。ActiveMQ中保持持续通知的功能的前提，就是能够识别客户端连接ID的历史连接情况，以便确定哪些订阅消息这个客户端还没有处理。
- Redis也没有为发布者和订阅者准备保证消息性能的任何方案，例如在大量消息同时到达Redis服务是，如果消息订阅者来不及完成消费，就可能导致消息堆积。而ActiveMQ中有专门针对这种情况的慢消息机制。
3.4 应用场景：未知
参考资料
Redis官网
架构设计：系统存储（16）——Redis事件订阅和持久化存储
Java中使用Jedis操作Redis
Redis笔记（七）Java实现Redis消息队列
Redis编程实践【pub/sub】
用redis实现支持优先级的消息队列
java redis使用之利用jedis实现redis消息队列
基于Redis实现分布式消息队列