总结
| 服务 | 特性 |
|---|---|
| Redis | 轻量级，低延迟，高并发，低可靠性； |
| RabbitMQ | 重量级，高可靠，异步，不保证实时； |
应用
RabbitMQ是一个专门的AMQP协议队列，他的优势就在于提供可靠的队列服务，并且可做到异步，而redis主要是用于缓存的，Redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。
对比
| iiiiiiiiiiiiiiiiiiii | Redis | RabbitMQ |
|---|---|---|
| 可靠性 | 没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中 | 具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费 |
| 实时性 | Redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性 | |
| 消费者负载均衡 | 发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将该消息依次发送给每个订阅者 | 队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于RabbitMQ的消费确认机制，因此它能够根据消费者的消费能力而调整它的负载 |
| 持久性 | Redis的持久化是针对于整个redis缓存的内容，它有RDB和AOF两种持久化方式（Redis持久化方式，后续更新），可以将整个Redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。 | 队列消息都可以选择性持久化，持久化粒度更小，更灵活； |
| 队列监控 | Redis没有所谓的监控平台。 | RabbitMQ实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以方面我们更好的使用； |
2019.06.27
在业务的实现过程中，就算没有大量的流量，解耦和异步化几乎也是处处可用，此时MQ就显得尤为重要。但与此同时MQ也是一个蛮重的组件，例如我们如果用RabbitMQ就必须为它搭建一个服务器，同时如果要考虑可用性，就要为服务端建立一个集群，而且在生产如果有问题也需要查找功能。在中小型业务的开发过程中，可能业务的其他整个实现都没这个重。过重的组件服务会成倍增加工作量。
所幸的是，Redis提供的list数据结构非常适合做消息队列。
