在软件工程中，不存在像“银弹”这样可以解决一切问题的设计、架构或软件，每一个软件系统，它都是独一无二的，你不可能用一套方法去解决所有的问题。
我们就是那种对消息队列功能和性能都没有很高的要求，所以选择RabbitMQ。
不管选择哪种消息队列其中还有个很关键的因素，团队里面有人能hold它，最起码熟悉掌握其详细配置。
选择不熟悉的MQ会变成不定时炸弹，在生产遇到问题无法快速解决。
接下来说下 RabbitMQ 的几个问题。
2. RocketMQ
3. Kafka
当下的 Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。
Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。
Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。
Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。
我曾经使用配置比较好的服务器对 Kafka 进行过压测，在有足够的客户端并发进行异步批量发送，并且开启压缩的情况下，Kafka 的极限处理能力可以超过每秒 2000 万条消息。
但是 Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，
因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，
在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。
当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。
Pulsar 采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目。
