关于消息队列（笔记）
分享一个高手的解释，化抽象为具体，化繁为简，牛逼牛逼
[消息队列的使用场景是怎样的？ - 祁达方的回答 - 知乎]
(https://www.zhihu.com/question/34243607/answer/140732170)
Why MQ
1. 降低代码的耦合性
作为消息的生产者，只需要关心消息如何被生产，而不必关心这个消息如何被消费，被谁消费。消费者与生产者各自实现各自的接口。（这里有个词很有意思：fire and forget，这个词是从导弹行业引进来的，直译为“射后不管”，是不是很污，用在这里，代表生产者生产完数据之后就不用管了）
2. 易扩展
因为降低了耦合性，所以易扩展，很容易调整消息的入队和处理的频率
3. 消息安全传输
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
4. 异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
消息队列中的数据需要在多个系统间共享数据才能发挥价值。这点对分布式系统异常重要。
RabbitMQ VS Redis
RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
Redis
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
