如何从业务场景看消息中间件

这篇文章主要介绍“如何从业务场景看消息中间件”，在日常操作中，相信很多人在如何从业务场景看消息中间件问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何从业务场景看消息中间件”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

MQ的三大作用

MQ的三大作用：业务解耦、异步调用、流量削峰。

在介绍消息中间件之前，我们先想一下，如果不用MQ，业务之间最常用的调用方式是什么？比较常见的是RPC和REST方式。两种简单的对比如下：

因为REST灵活度高、性能低；而RPC性能高而灵活度低，因此我们可以对外接口用REST，内部通讯用RPC。

内部采用RPC的架构如下所示：

如果是核心应用，上面架构没有问题。但如果业务逻辑被加入了有时效性的运营活动逻辑，频繁修改代码逻辑显然不靠谱。

借助于MQ，我们将运行活动业务逻辑单拎出来，放到MQ后面。客户端的发起的请求，都发到MQ一份，后面的业务逻辑根据自己的需求进行消费。这样，通过MQ，我们实现了业务解耦（运营活动与核心业务）

上面我们提到很多时候内部业务调用是RPC。在一些场景下，我们可以通过MQ替换RPC，实现业务异步调用。

那么，MQ能否完全替代RPC？理论上可以替代RPC。但是在这种情况下，整个系统的稳定性都靠MQ，存在一定的风险。而PRC是个独立的框架，业务节点有问题，对全局没有影响。所以不建议把RPC都换成MQ。

接下来，我们看一个具体的场景（电商场景），如何通过MQ实现业务异步调用。

在下图中，不使用MQ之前，交易服务向卖家推送服务、记录交易数据等都是通过RPC实现。实际上，这与核心业务逻辑无关。因此可以改造成第二张图的模式。

在介绍了MQ实现业务逻辑拆分和异步调用后，接下来我们查看MQ实现流量削峰的场景。

京东经常举办秒杀的活动。在秒杀开始那一刻，很多用户发起请求，访问量突增。此时为了保证业务逻辑层的平稳运行，需要在API网关和业务员逻辑之间增加一个MQ。客户端请求都被堆积在MQ，然后业务逻辑处理。此时，我们可以给用户开放一个秒杀结果的查询接口，通过RPC调用业务逻辑层。

MQ虽然能够实现流量削峰、业务解耦、异步调用，但引入MQ也有一切缺点，例如增加了故障诊断的复杂度、增加了架构的复杂度。因此MQ不能完全替代RPC，两者要结合使用。在微服务的场景中，MQ通常放在API网关和业务逻辑层之间，如上图所示。

几种MQ的对比

接下来，我们对比一下几种主流MQ的优劣势：

从上图中，我们可以看到，RocketMQ在功能上是有一定的优势的。Rocket目前是一个很受欢迎的MQ开源项目：

如果要对比Kafka和RocketMQ的应用场景，简单而言：Kafka做的不是业务的事情，它不保证业务的一致性，它是系统间的数据流通道；RocketMQ做的是业务相关的事情，它保证业务的一致性，它实现高性能可靠信息传输。

正常的消息会负载均衡发送。一个Topic会跨多个队列。如果想要顺序消息，就必须发到一个队列，并且只有一个线程消费消息。

RocketMQ被广泛使用的几个核心原因是：支持事务消息、支持延迟消息、支持消息重发、支持customer端tag过滤、支持消息回放。

RocketMQ的拓扑与逻辑图

RocketMQ的拓扑图如下。

RocketMQ的Name Server集群中每个节点都是相互独立的，负责MQ集群的服务注册发现。

逻辑图如下：

由于RocketMQ不能实现主从切换，因此消息生产者只连接到主上，消费者连接到主和从上。

结合RockerMQ的可靠性和可用性，我们通常的使用方式如下图所示，即多Master多Salve+异步复制。

在RockerMQ中，消息生产者在写消息是以顺序追加的方式，写在commitlog中的。commitlog是消息主体。然后dispatch线程把消息的偏移量和大小从commitlog中读出来，放到按主题、以队列的形式消费队列。也就是说，队列放的不是消息主体。而是消息的索引信息。

CommitLog以物理文件的方式存放，每台Broker上的CommitLog被本机器所有ConsumeQueue共享。为了提升消息读取的性能，RocketMQ默认会把commitlog以1G大小进行拆分。此外，对于MQ系统，尽量使用SDD或NVRAM。

RocketMQ的消息传递方式

我们知道，服务之间消息传递主要有两种模式：队列（Queue）和主题（Topic）。

• Queue 模式是一种一对一的传输模式。在这种模式下，消息的生产者（Producer）将消息传递的目的地类型是 Queue。Queue 中一条消息只能传递给一个消费者（Consumer），如果没有消费者在监听队列，消息将会一直保留在队列中，直至消息消费者连接到队列为止，消费者会从队列中请求获得消息--->消费者pull方式。

• Topic 模式是一种一对多的消息传输模式。在这种模式下，消息的生产者（Producer）将消息传递的目的地类型是 Topic。消息到达 Topic 后，消息服务器将消息发送至所有订阅此主题的消费者。--->push给消费者模式。

在RocketMQ中，Topic是个抽象的概念，每个Topic底层对应N个queue，而数据也真实存在queue上的。Queue是Topic在一个Broker上的分片等分为指定份数后的其中一份，是负载均衡过程中资源分配的基本单元。也就是说，一个topic跨多个queue，每个queue在一个broker上，因此topic可以跨多个broker。

实际上，push和pull方式都各优缺点。

push方式：消息实时性高，但没有考虑客户端的消费能力、即消息处理速度。

pull方式：消息实时性低，可能造大量无效请求。

为了取长补短，RocketMQ采用LongPoll方式，即长轮询方式。在这种方式下，消费者主动发送pull消息，然后broker hold住请求，直到有消息才返回。请求的超时时间是30s。当请求超时后，消费端再度发起请求。

RocketMQ的消费者消费方式

关于消费者消费消息的方式，主要有两种：

集群消费：单条消息只消费一次，各阶段均匀消费Topic的消息。

广播消费：各集群消费全量的消息，单条消息在每个集群都被消费一次。

到此，关于“如何从业务场景看消息中间件”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！