消息队列：将数据以先入先出的形式存储到队列里面。
常见的框架有 Redis，微软自带的 MSMQ，RabbitMQ，kafka 等。
消息队列优点：
消息的可靠传递，确保不丢失；
异步处理，响应快；
解耦，服务器宕机了，还是能够正常的响应请求；
削峰，处理高并发的情况。
消息队列缺点：
架构复杂、处理等待、依赖中间件（独立的进程）……
几款中间件的对比：
RabbitMQ，生产者/消费者
优点：轻量级，容易部署和使用，支持可视化界面，适合中大型项目架构。
缺点：对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降；性能差，每秒钟处理几万到十几万条消息。
RocketMQ
优点：性能比 RabbitMQ 要高一个数量级，每秒钟处理几十万条消息。
缺点：与周边生态系统的集成和兼容程度不够。
kafka，发布者/订阅者
优点：与周边生态系统的兼容性是最好的没有之一；性能高效、可扩展良好并且可持久化。
缺点：同步收发消息的响应时延比较高，不太适合在线业务场景。
使用场景：
· 对消息队列功能和性能没有很高的要求，只需要一个快速上手易于维护的消息队列，建议使用 RabbitMQ。
· 如果系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，需要低延迟和高稳定性，建议使用 RocketMQ。
· 如果需要处理海量的消息，像收集日志、监控信息或是埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合的消息队列。
· 如何保障消息队列不被重复消费？
略 ……
· RabbitMQ 如何保证全链路数据100%不丢失 ？
事务消息机制：严重降低性能。
confirm消息确认机制：让生产端感知到消息是否投递到RabbitMQ中。
消息持久化：相关的数据应该持久化到硬盘中，这样就算RabbitMQ重启后也可以到硬盘中取数据恢复。
message消息到达RabbitMQ后先是到exchange交换机中，然后路由给queue队列，最后发送给消费端。
除了RabbitMQ提供的一些机制外，我们自己也要做一些消息补偿机制，以应对一些极端情况。如消息入库。
消息入库：将要发送的消息保存到数据库中。
上述是让生产端100%可靠性投递到RabbitMQ，如何让消费端不丢失消息？
将自动ack机制改为手动ack机制，避免RabbitMQ在消息发出后就立即将这条消息删除，这样对于RabbitMQ服务端而言，队列中的消息分成了两个部分：
一部分是等待投递给消费端的消息；
一部分是已经投递给消费端，但是还没有收到消费端确认信号的消息。
如果RabbitMQ一直没有收到消费端的确认信号，并且消费此消息的消费端已经断开连接或宕机（RabbitMQ会自己感知到），
则RabbitMQ会安排该消息重新进入队列（放在队列头部），等待投递给下一个消费者，当然也有能还是原来的那个消费端。