业务方对消息中间件的需求

在大型互联网中，主要采用消息中间件来进行业务的解耦和操作的异步化，这也是消息中间件最基础的特点，也是业务系统对消息中间件的最基本需求。

在这个基础之上，本篇来谈一下业务系统从功能、性能等各个方面对消息中间件的需求。

功能

功能需求核心的其实就发送消息和消费消息，细化下去，发送需求会有同步发送、异步发送，会有实时消息、定时消息等；消费需求会有各种模式，比如业务方主动Pull、或者消息中间件Push的模式等等。

消息发送

消息发送功能从编程接口的角度出发就只有两个需求：同步发送接口和异步发送接口。

从消息类型的角度出发，会有以下几点需求：

1. 实时消息
2. 定时消息
3. 事务消息

实时消息最简单了，Producer发送一条消息，这条消息对Consumer是立即可见的，会尽快被消费掉的。

定时消息则是Producer发出一条消息后，这条消息不是立即可见，可以被消费的，它需要等待一个固定时间之后才能被Consumer进行消息。

事务消息的含义是说它是和业务操作绑定在一起的，要么业务操作成功且消息发送成功，如果业务操作失败，消息是需要回滚的。这里的事务其实就是表明了业务操作是消息是在一个事务内的，要么都成功，要么都失败。

对事务消息多说一点。事务消息是个非常有趣的东西，因为业务操作和发送消息是两个完全独立的事情，是一个分布式事务，保证他们的一致性就变得非常困难。操作中如果先发消息再做业务，那么可能出现消息发送成功而业务做失败了，此时就需要撤销消息（这样理解其实事务消息称为可撤销的消息，即如果业务执行失败了，将发送的消息撤销）；如果是先做业务再发消息，那么可能出现业务做成功了消息发送失败了，此时就需要撤销业务（先做业务有明显的问题是消息发送的结果除了成功和失败，还会有超时的状态，是无法确认是否发送成功的）。

这里会引申出两阶段提交，第一阶段发送消息，之后等业务完成后执行第二阶段对消息进行提交。对事务消息，之后会专门出一篇文章描述场景和实现方案的。

另外消息发送还会有顺序性的要求，消息的消费顺序需要和发送顺序保持一致。

消息消费

消费方式上需要提供集群消费和广播消费（这两个概念再上一篇都讲过了）。另外对消息获取的方式也会有特定的需求，比如一些业务方是期望由他们自己主动去获取消息的，另一些会要求以监听的模式，即提供Listener当有新消息时触发Listener（对使用Pull还是Push模式也是非常有意思的一点，在之后会写一篇专门的文章讨论我们我们是怎么选择Pull和Push的）。

和发送一样，消费端也需要保证消息顺序（废话，如果只保证发送的顺序，打这个顺序在消费的时候错乱了，那顺序又有什么意义）。

除了这些基础需求，消费时还会有位点重置的需求，即可以主动去修改消费位点来重新消费消息。

另外从功能上还会有消息跟踪、消息堆积之类的需求。业务方需要知道一条消息的运行轨迹，定位一条消息从产生到经过MQ，再到被消费的完整轨迹。在高峰期，消息需要先堆积在MQ中之后进行消费（就是削峰的作用）。

性能

性能就两点：延迟和吞吐。

对业务系统而言，它本身不会容忍在执行消息发送时消耗过多的时间，因为过长的耗时将直接影响它系统的吞吐，所以一般对消息的发送延迟要求都是毫秒级的，平均需要在2ms左右吧。对消费也是一样，对实时性要求比较高的系统响应的会期望消息从发送出来到被消费到的这个时间尽可能的短。

吞吐也是一样，因为直接影响到使用MQ的业务系统的性能，所以也是需要一个超过业务系统吞吐上限的能力。RocketMQ给出的性能指标是10字节的消息单机TPS在7w左右，但是没有给机器指标给出消息延迟之类的指标，笔者也没有测试验证过。

可用性

互联网产品我们会经常听到高可用的概念，会要求7*24小时运行，可用性达到99.99%之类的描述。可用性是指系统可以提供服务的正常运行时间和总运行时间的比值。

对业务系统而言，中间件是他们依赖的服务，当然是希望可用性越高越好，但是现实中网络是会故障的，机器是会宕机的，磁盘是会损坏的。所以对消息中间件而言，一般会要求99.99%的可用性之类的，即365天内不可用的时间不允许超过1个小时。

为了满足可用性的要求，系统需要做备份等等，这些在之后的文章中也会展开去讨论。

可靠性

在消息中间件中，业务方对可靠性的要求主要集中在消息会不会丢失。消息不丢失也是对消息中间件最最基础的要求。

以上内容参考了部分RocketMQ的文档和阿里云上MQ的文档。

结语

这篇文章简单的概述了一下消息中间件的一些需求，部分需求并非核心需求，比如消息轨迹这样的需求可能是在你的消息中间件已经完成的基础下再去谈的。