消息队列的用途、优缺点、技术选型

1. 为什么使用消息队列

1. 解耦：可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用 MQ 进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用 MQ 进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在 MQ 里面没人进行消费而已，不会对其他的系统产生影响。

   不使用 MQ 的情况：

   

   使用 MQ 进行解耦之后：

   

2. 异步：加入一个操作设计到好几个步骤，这些步骤之间不需要同步完成，比如客户去创建了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等。这样如果这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是无法接收的；并且像添加客户轨迹这种操作是不需要去同步操作的，如果使用 MQ 将客户创建订单时，将后面的轨迹、库存、状态等信息的更新全都放到 MQ 里面然后去异步操作，这样就可加快系统的访问速度，提供更好的客户体验。

   不使用 MQ 的情况：

   

   使用 MQ 进行异步之后：

   

3. 削峰：一个系统访问流量有高峰时期，也有低峰时期，比如说，中午整点有一个抢购活动等等。比如系统平时流量并不高，一秒钟只有 100 多个并发请求，系统处理没有任何压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，比如达到了每秒 5000 个并发请求，而我们的系统每秒只能处理 2000 个请求，那么由于流量太大，我们的系统、数据库可能就会崩溃。这时如果使用 MQ 进行流量削峰，将用户的大量消息直接放到 MQ 里面，然后我们的系统去按自己的最大消费能力去消费这些消息，就可以保证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后通过其他方式通知其结果。

   使用 MQ 进行削峰：

   

2. 消息队列优缺点

2.1. 优点

1. 对结构复杂、设计系统多的操作进行解耦操作，降低系统的操作复杂度、降低系统的维护成本；
2. 对一个可以进行异步操作的一些系统操作进行异步，减小操作的响应时间，提供更好的用户体验；
3. 可对高流量进行削峰，保证系统的平稳运行；

2.2. 缺点

1、系统可用性降低。比如在系统中引入 MQ，那么万一 MQ 挂了怎么办呢？一般而言，引入的外部依赖越多，系统越脆弱，每一个依赖出问题都会导致整个系统的崩溃； 2、系统复杂度提高。需要考虑 MQ 的各种情况，比如：消息的重复消费、消息丢失、保证消费顺序等等… 3、数据一致性问题。比如 A 系统已经给客户返回操作成功，这时候操作 B、C 都成功了，操作 D 却失败了，导致数据不一致；

3. Kafka、ActiveMQ、RabbitMQ、RocketMQ 优缺点对比

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，吞吐量比 RocketMQ 和 Kafka 要低一个数量级	万级，吞吐量比 RocketMQ 和 Kafka 要低一个数量级	10 万级，RocketMQ 也是可以支撑高吞吐的一种 MQ	10 万级别，Kafka 最大优点就是吞吐量大，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百、几千个的级别，吞吐量会有小幅度的下降。这是 RocketMQ 的一大优势，可在同等数量机器下支撑大量的 topic	topic 从几十个到几百个的时候，吞吐量会大幅下降。所以在同等机器数量下，Kafka 尽量保证 topic 数量不要过多。如果支撑大规模 topic 需要增加更多的机器
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟是最低的	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现可用性	高，基于主从架构实现可用性	非常高，分布式架构	非常高，Kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据		经过参数优化配置，可以做到 0 丢失	经过参数配置，消息可以做到零丢失
功能支持	MQ 领域的功能及其完备	基于 erlang 开发，所以并发性能极强，性能极好，延时低	MQ 功能较为完备，分布式扩展性好	功能较为简单，主要支持加单 MQ 功能
优势	非常成熟，功能强大，在业内大量公司和项目中都有应用	erlang 语言开发，性能极好、延时很低，吞吐量万级、MQ 功能完备，管理界面非常好，社区活跃；互联网公司使用较多	接口简单易用，阿里出品有保障，吞吐量大，分布式扩展方便、社区比较活跃，支持大规模的 topic、支持复杂的业务场景，可以基于源码进行定制开发	超高吞吐量，ms 级的时延，极高的可用性和可靠性，分布式扩展方便
劣势	偶尔有较低概率丢失消息，社区活跃度不高	吞吐量较低，erlang 语音开发不容易进行定制开发，集群动态扩展麻烦	接口不是按照标准 JMS 规范走的，有的系统迁移要修改大量的代码，技术有被抛弃的风险	有可能进行消息的重复消费
应用	主要用于解耦和异步，较少用在大规模吞吐的场景中	都有使用	用于大规模吞吐、复杂业务中	在大数据的实时计算和日志采集中被大规模使用，是业界的标准

综上所述，总结如下：

一般业务系统要引入 MQ，最早大家都用 ActiveMQ，但现在用的不多了。没有经过大规模吞吐场景的验证，社区也不活跃，不推荐再使用。

后来大家开始用 RabbitMQ，但是它是使用 erlang 语言开发的，如果不精通 erlang，对公司而言，几乎处于不可控的状态，但其是开源的，社区活跃度高，拥有比较稳定的支持。

现在越来越多的公司开始使用 RocketMQ，但是要小心被抛弃的风险。如果公司有实力自己去维护开发，推荐使用。否则还是选择 RabbitMQ。

如果实在大数据的实时计算、日志采集等领域，用 Kafka 是业界标准。

---

原文链接

关于 MQ 的几件小事（一）消息队列的用途、优缺点、技术选型