开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第14天，点击查看活动详情 我们在业务进行到一定阶段的时候，经常会用到消息队列，对于消息队列如何选择，我们经常会思考如何选择一个合适的MQ呢？
这个如何选择的话我认为主要是以下几点进行综合考虑
1. 社区的活跃程度
市面上的消息队列产品很多，我们在使用的时候主难免会遇到一些问题，这些问题如何解决，一方面是我们从官方的社区文档获得解决方案，一方面是靠我们一点点死磕去解决，后者显然是十分浪费时间以及精力的，所以一些社区活跃的产品，相比里边遇到问题的人也会很多，大多数BUG应该是都解决过的，并且提出完整的技术解决方案的，如果选一个冷门的产品，更新频率看开发者心情的，那我们遇到问题肯定是比较麻烦的。例如我们常用的Kafka、RocketMQ的社区就是十分活跃的。
2.良好的性能、稳定性、上手容易
我们选用的消息队列首先是一定要满足高性能的，一般用到MQ的场景都是解藕、异步、销峰的场景，这些场景一般数据量都是很大的，MQ要承载大量的任务，在大量消息存取方面是要十份优秀的，要支持大多数的业务场景。还有个是要支持集群分布式模式。学习改造成本要低，比如一个技术团队所使用的MQ是基于GO写的，但是团队里边的人对GO不熟悉，我们要对MQ做一些定制化的开发，那我们还得重新学习GO，那整个的一个投入成本就太高了。
3.生态圈的完善程度
我们还要考虑的一个东西就是生态圈的完善程度，比如客户端所支持的语言、监控运维、与一些开源框架的集成方面。比如说，在大数据生态圈，Kafka跟Spark的兼容性就很好。
4.活跃度较高的消息队列
4.1 RabbitMQ
算是比较老牌的消息队列，之前公司一些历史比较悠久的业务，用的这个队列，采用Erlang语言开发，在扩展性方面不是很好，Erlang算是小众语言，如果要对其进行扩展，需要投入大量的学习成本，在性能方面，当数据量比较大的时候，会产生大量的数据积压，造成性能急剧下降。
4.2 Kafka
算是大数据领域最常用的MQ了，Aache的顶级项目，在消息存储方面也是十分优秀，最初的设计是为了用于处理海量日志，性能的话很强，但是为了保证性能在消息的完整性方面做了一定的牺牲，所以一般不用在在线业务方面，一般主要用于日志收集等场景。
4.3 RocketMQ
阿里开源的，也算是现在使用最广泛的一个MQ，经历过阿里双十一大促流量高峰的考验，采用JAVA开发，才社区的活跃度，周边生态的完善程度方面，都是顶呱呱的，在消息存储、消息处理方面是十分优秀的，官方有提供大量的Demo供使用者去参考。
接下来简单对三个MQ做个对比
| 标题 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 出品方 | RabbitMQ Technologies Ltd | Apache | 阿里巴巴 |
| 开发语言 | Erlang | Scala | Java |
| 性能 | 良好（十几万/s） | 优秀（数十万/s） | 极好（百万/s） |
| 社区活跃度 | 一般 | 活跃 | 活跃 |
| 扩展性 | 差 | 好 | 好 |
| 数据可靠性 | 低 | 高 | 高 |
| 生态 | 一般 | 好 | 好 |
