消息队列学习笔记

《消息队列必知必会》是极客时间上一门课程，总共5讲，以下为学习笔记。

第一讲，为什么需要消息队列

消息队列是古老的中间件，从系统之间有通信需求开始，就自然产生了消息队列。消息队列像传送带一样把上下游的工序连接起来。可应用于需要异步处理、流量控制、服务解耦的场景中。消息队列也有它自身的一些问题和局限性，包括：引入消息队列带来的延迟问题；增加了系统的复杂度；可能产生数据不一致的问题。

第二讲，如何选择消息队列

这讲是关于消息队列的技术选型，软件工程里没有银弹，也就是说没有一个选型是包治百病的。常用的消息队列各有优劣，要根据情况选择适合的。

1.评判的标准：

基本分：消息传递可靠，支持集群，性能足够

加分：开源，活跃度高，生态兼容性好

2.常用消息队列产品

RabbitMQ，老牌消息队列，小众语言开发，轻量级，支持语言多，对消息堆积支持不好，性能不佳。如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

RocketMQ，阿里开源的消息队列，Java开发，经历了双十一考验，性能优良，中文社区活跃，但国际化水平不高，生态兼容性不佳。如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。

Kafka，LinkedIn开发，Apache顶级项目，生态兼容性最好，尤其在大数据、流计算领域首选，异步收发性能卓越，但同步收发性能不佳，不适合在线业务。如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。

第三讲，如何确保消息不丢失

主流的消息队列产品都提供了完善的可靠性保障。消息丢失绝大多数情况是没有正确使用和配置。

监测消息是否丢失，最简单的方式是给每个消息一个序号，如果监测到序号不连续，就说明丢失了。

如何保障消息不丢失的呢？

1.生产阶段

编写发送消息代码时，需要注意，正确处理返回值或者捕获异常，就可以保证这个阶段的消息不会丢失。

2.存储阶段

在存储阶段正常情况下，只要 Broker 在正常运行，就不会出现丢失消息的问题。如果对消息的可靠性要求非常高，可以通过配置 Broker 参数来避免因为宕机丢消息。

3.消费阶段

不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。

第四讲，如何处理消息重复

消息可能出现重复，对于一些场合很敏感，比如交易中，同一笔交易发了两次，收到的款可能翻倍。

为了处理消息重复，可以利用操作的幂等性原理。也就是说操作多次和一次效果一样。比如，A给B转账100元，业务代码中不要写B加100元，而是把B账户金额设为100元。无论执行多少次操作，B账户都是100元。

利用幂等性解决重复消息问题，需要在业务代码中将操作变换为幂等操作。有些技巧:

1.利用数据库唯一约束

2.为更新数据加前置条件

3.记录并检查操作

第五讲，消息积压了怎么办

消息积压一般是某部分性能出了问题，消费不过来数据。

优化性能避免积压中，一般不考虑消息队列的优化，因为相比于业务逻辑，消息队列处理能力远大于业务处理。一般考虑在消息的收发两端，业务代码怎么和消息队列配合，达到一个最佳的性能。

发送端的发信速率优化的办法有选择合适并发和批量。

消费端的消费速度直接影响消息队列积压，一定要保证消费端的消费性能要高于生产端的发送性能，这样的系统才能健康的持续运行。消费端的性能优化除了优化消费业务逻辑以外，也可以通过水平扩容，增加消费端的并发数来提升总体的消费性能。