根据实际业务场景的不同，选择消息中间件通常需要考虑以下几个方面
- 性能：消息中间件的性能是选择的重要因素之一。性能包括消息传输的吞吐量、延迟、可靠性等指标。不同的业务场景对性能的需求不同，需要根据实际情况进行选择。
- 可靠性：消息中间件需要保证消息的可靠性，即消息不丢失、不重复传输、按照顺序传输等。消息中间件的可靠性包括消息存储机制、消息传输机制、消息确认机制等。
- 扩展性：随着业务的发展，消息中间件需要具备良好的扩展性，能够支持水平扩展和动态负载均衡等机制。
- 功能特性：不同的消息中间件提供的功能特性不同，例如支持点对点和发布/订阅两种消息模型、支持事务消息、定时消息、批量发送等特性。根据业务需求进行选择。
- 社区支持：开源的消息中间件通常有较为活跃的社区支持，能够提供技术支持和解决问题。选择时需要考虑社区的活跃程度和支持情况。
常见的消息中间件包括：
- Apache Kafka：高吞吐量、高可靠性、低延迟的分布式消息系统，支持发布/订阅模式和批量处理等特性。
- Scala开发， 面向日志功能丰富，性能最高。
- 当业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。
- 所以，Kafka 不太适合在线业务场景。
- RabbitMQ：基于AMQP协议的高可靠性、高可用性的消息中间件，支持多种消息模型和功能特性。
- erlang开发，对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。
- 每秒钟可以处理几万到十几万条消息。
- RocketMQ：阿里巴巴开源的分布式消息中间件，具有高可用性、高吞吐量、低延迟等特点。
- Java开发，面向互联网集群化功能丰富
- 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，每秒钟大概能处理几十万条消息。
- ActiveMQ：基于JMS规范的开源消息中间件，具有高可靠性、高可用性等特点。
- java开发，简单，稳定，性能不如前面三个。
- 小型系统用也ok，但是不推荐。推荐用互联网主流的。
- Redis Pub/Sub：Redis提供的发布/订阅模式，具有高吞吐量、低延迟等特点。
选择合适的消息中间件需要根据实际业务需求进行综合考虑，同时也需要结合自身技术栈和团队经验进行选择。
