rabbitMQ和redis区别

消息队列是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保消息的可靠传递。消息发布者只管把消息发布到MQ中而不用管谁来取，消息使用者只管从MQ中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。
Redis
Redis就是一个内存数据库，具有丰富的数据类型，当然也支持队列queue，redis支持数据持久化，主从集群。
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list,set,zset,hash等数据结构的存储。
Redis支持数据的备份，即master-slave模式的数据备份。
rabbitMQ
是一个专门做队列的框架，在队列方面要比redis队列性能要好，支持的功能会更多，消息的可靠性更强，可以根据路由规则去选择进入哪一个队列，做到更加细致的消息分发
所有MQ产品从模型抽象上来说都是一样的过程：
消费者订阅某个队列。生产者创建消息，然后发布到队列中，最后将消息发送到监听的消费者。

RabbitMQ架构

组件:
Message(消息):RabbitMQ转发的二进制对象，包括Headers(头)、Properties(属性)和Data(数据),其中数据部分不是必要的；
Producer(生产者):消息的生产者，负责产生消息并把消息发到交换机Exhange的应用；
Consumer(消费者)：使用队列Queue从Exchange中获取消息的应用；
Exchange(交换机)：负责接收生产者的消息并把它转到合适的 队列；
Queue(队列):一个存储Exchange发来的消息的缓存，并将消息主动发送给Consumer，或者Consumer主动来获取消息。
Binding(绑定)：队列和交换机之间的关系。Exchange根据消息的属性和Binding的属性来转发消息。绑定的一个重要属性是binding_key。
Connection （连接）和 Channel （通道）：生产者和消费者需要和 RabbitMQ 建立 TCP 连接。一些应用需要多个connection，为了节省TCP 连接，可以使用 Channel，它可以被认为是一种轻型的共享 TCP 连接的连接。连接需要用户认证，并且支持 TLS (SSL)。连接需要显式关闭
Redis和rabbitMQ消息队列的区别
可靠性：
Redis：没有相应的机制保证消息的可靠消费，如果发布者发布一个消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中;
rabbitMQ:具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费，
使用一些机制来保证可靠性，如持久化、传输确认、发布确认。灵活的路由
实时性
Redis：实时性高，redis作为高效的缓存服务器，所有数据都存在内存中，所以它具有更高的实时性，Redis能读110000次/s,写的速度是81000次/s
Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也是支持事务，即原子性，通过MULTI和EXEC指令包起来。
消费者负载均衡：
首先Redis的设计是用来做缓存的，但是由于它自身的某种特性使得他可以用来做消息队列(Redis的List数据结构比较适合做MQ)。它有几个阻塞式的API可以使用，正是这些阻塞式的API让他有做消息队列的能力。 另外做消息队列的其他特性，例如FIFO也很容易实现，只需要一个list对象从头取数据，从尾部塞数据即可实现。 Redis能做消息队列得益于它的list对象blpop brpop接口以及Pub/Sub(发布/订阅)的某些接口。他们都是阻塞版的，所以可以用来做消息队列
rabbitMQ队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于rabbitMQ的消费确认机制，因此它能够根据消费者的消费能力而调整它的负载；
redis发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将消息依次发送给每个订阅者，她是一种消息的广播形式，redis本身不做消费者的负载均衡，因此消费效率存在瓶颈；
持久性
Redis：redis的持久化是针对于整个redis缓存的内容，它有RDB和AOP两种持久化方式(redis持久化方式，后续更新)，可以将整个redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。
rabbitMQ:队列，每条消息都可以选择性持久化，持久化粒度更小，更灵活；
队列监控
rabbitMQ实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以方面我们更好的使用；
redis没有所谓的监控平台。
RabbitMQ和Redis都可以做队列，但是他们还是有区别的。比如，Redis的消息队列，如果在从队列pop出去的时候，worker处理失败的话，数据不会回到队列中，需要从业务中手动把失败的处理数据push到队列中；而RabbitMQ可以自动处理失败的worker使数据不丢失；RabbitMQ还可以保证数据在传输过程中持久化，在通道和队列中的数据可以设置为持久化。首先Redis严格来说并不是消息队列，它是一个内存数据库，不过因为其某些特性适合用来充当队列，所以也多被用于做简单的mq, Redis之父倒是开发了个真正的消息队列disque，有兴趣可以看看。
相比起Redis，RabbitMQ有更加完善的MQ机制，这里我们仅讨论消息的durable（持久性）
RabbitMQ有一个消息确认机制来保证消息的不丢失：客户端从队列中取出消息之后，可能需要一段时间才能处理完成，如果在这个过程中，客户端出错了，异常退出了，而数据还没有处理完成，那么非常不幸，这段数据就丢失了，因为RabbitMQ默认会把此消息标记为已完成，然后从队列中移除，消息确认是客户端从RabbitMQ中取出消息，并处理完成之后，会发送一个ack告诉RabbitMQ，消息处理完成，当RabbitMQ收到客户端的获取消息请求之后，或标记为处理中，当再次收到ack之后，才会标记为已完成，然后从队列中删除。当RabbitMQ检测到客户端和自己断开链接之后，还没收到ack，则会重新将消息放回消息队列，交给下一个客户端处理，保证消息不丢失，也就是说，RabbitMQ给了客户端足够长的时间来做数据处理。

总结
Redis：遵守BSD协议是一个高性能的key-value数据库，轻量级，低延迟，高并发，低可靠性；
rabbitMQ:重量级，高可靠，异步，不保证实时；
rabbitMQ是一个专门的AMQP协议队列，他的优越性就在于提供可靠的队列服务，并且可做到异步，而redis主要用于缓存的，redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。