Redis:订阅与发布功能对比RabbitMQ消息队列

【注：部分引用其余博客内容，原做者不详】

总结

服务	特性
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数据结构也很是适合作消息队列。