为什么要使用消息队列（MQ）？可以列举一些MQ的优点吗？

使用消息队列（MQ）有几个主要的优点：

1. 解耦：通过使用消息队列，系统之间可以实现解耦。一个系统产生的数据可以通过消息队列发布，其他系统可以订阅该消息并消费，而无需直接与数据产生系统进行交互。这种解耦方式降低了系统之间的依赖性，减少了代码维护成本。

2. 异步：消息队列支持异步通信模式，可以提高系统的响应速度。当一个系统调用其他系统的API时，同步调用需要等待每个依赖系统逐一完成调用才能返回结果，耗时较长。通过使用消息队列进行异步化，系统可以将调用请求发送到队列中，然后继续处理其他任务，从而大幅缩短调用时间，提高高延时接口的速度。

3. 削峰：在高峰期，大量请求涌入系统时，如果直接将请求发送到数据库等后端存储，可能会导致系统崩溃。通过使用消息队列，系统可以将请求先写入队列中，在低谷时逐个消费请求，从而避免系统崩溃。尽管消息队列中会积压大量请求，但在低谷期可以逐渐消费掉这些请求。

4. 分布式一致性：消息队列可以支持分布式系统中的一致性需求。通过使用合适的消息队列，系统可以保证各个模块执行的结果一致性，避免不同模块之间的数据不一致问题。

5. 点对点消费：消息队列支持点对点的消息消费模式，可以确保消息只被一个消费者接收和处理。这对于一些需要确保消息只被一个接收者处理的场景非常有用。

然而，引入消息队列也可能带来一些问题：

1.可用性降低：如果消息队列出现问题，可能导致生产者无法发送消息，消费者无法消费消息，从而导致整个系统不可用。

2.复杂性增加：使用消息队列需要解决一些复杂性问题，例如消息的幂等性、可靠性、顺序性等。如果不正确处理这些问题，可能会导致数据重复、丢失或顺序错乱等一致性问题。

综上所述，根据不同的业务需求和技术实力，选择适合的消息队列是非常重要的。常见的消息队列包括 ActiveMQ、RabbitMQ、RocketMQ和Kafka。每种消息队列都有其优缺点，如单机吞吐量、时效性、可用性、消息可靠性和功能支持等方面有所差异。因此，在选择消息队列时，需要根据实际情况综合考虑这些因素。 对于中小型公司来说，技术实力一般，业务挑战不高的情况下，使用RabbitMQ是一个不错的选择。RabbitMQ是一个稳定且活跃的开源项目，有活跃的开源社区支持。 对于大型公司来说，如果具备较强的基础架构研发实力，可以考虑使用RocketMQ。RocketMQ是阿里巴巴出品的消息队列系统，具有较高的可用性和消息可靠性。 如果涉及大数据领域的实时计算、日志采集等场景，Kafka是业内标准的选择，具有高吞吐量和强大的功能支持，拥有活跃的开源社区。

介绍一下不同MQ的优缺点呢？

ActiveMQ： 优点：MQ领域的功能非常完备，具备高可用性的主从架构支持。

缺点：单机吞吐量较低，没有经过大规模吞吐量场景验证，社区活跃度也相对较低。

RabbitMQ： 优点：基于Erlang开发，具备并发能力很强、性能很好、延迟很低的特点。MQ功能较为完善，是分布式系统且扩展性较好。拥有稳定的支持和活跃的开源社区。 缺点：Erlang语言限制了Java工程师深入研究和掌控RabbitMQ，对公司而言可能存在不可控的状态。 RocketMQ： 优点：由阿里巴巴出品，具备较高的可用性和分布式架构，支持高吞吐量和消息可靠性。常用于大数据领域的实时数据计算和日志采集等场景。 缺点：尽管已捐赠给Apache，但GitHub上的活跃度相对较低，社区可能存在突然不活跃的风险。

Kafka： 优点：具备高吞吐量和消息可靠性，常用于大数据领域的实时计算和日志采集。Kafka延迟低，支持微秒级的时效性，并具有非常高的可用性和分布式架构。 缺点：相对而言，功能较为简单，主要支持基本MQ功能。

综上所述，对于中小型公司而言，如果技术实力一般且不需要处理高吞吐量场景，推荐使用RabbitMQ。对于大型公司而言，如果具备较强的基础架构研发实力，可以考虑使用RocketMQ。而在大数据领域的实时计算和日志采集等场景中，Kafka是业内的首选，因为它具备高可用性和活跃的开源社区支持