消息中间件的 "Style"

前情提要

​ 现如今，消息中间件已经在很多公司的业务中被广泛使用：业务解耦，消峰填谷，对接大数据，流式计算等等各种玩法层出不穷。伴随着消息中间件的使用，你一定还听过 "消息队列"，“pub-sub”这些名词，我们今天就来聊一下这些消息中间件提供给业务的可使用的 "Style"。

概述

​ 不管如何使用消息中间件，其实都可以归结到两个步骤：消息的产生和消费。消息中间件作为一种消息的暂存（当前也可以持久存储）系统，解耦消息的上下游，通过自身提供的高吞吐量，稳定可靠性，分布式可扩展性等一系列特性保证消息被业务合理正确处理。

​ 消息中间件依照消息数据如何从生产者移动到消费者可提供多种不同的“Style”，我们这里介始两种最常见的Style: 消息队列方式(Message queuing) 和 发布订阅(publish-subscribe)方式。

消息队列方式

​ 队列方式，就是Message queuing。

​ 我举个例子，我们在写同时处理大量任务的代码时，经常会使用work线程池，再搭配上一个任务队列，有任务要处理时塞进这个任务队列，然后work线程池中的空闲线程就不断地从这个任务队列里取出任务作处理。这里的每个work线程就可以看成是消息的消费者，一个任务只能被其中一个work线程处理，每个任务的处理过程有快有慢，先被work线程取走的任务不一定先被完成。

​ 有张图来形象地说明一下：

IMG_20200212_143320 (2).jpg

到这里我们可以看到对于队列方式，同一个topic的各个消息是被各消费者分摊消息的，为了防止消息被重复消费，通常在消费者获取到消息或处理完消息后对MQ中的消息作删除或标记。

如果消息队列中的消费堆积过多，我们可以通过扩容当前的消费者，来增加消息消费的吞吐量。

通过对于无状态的应用更常使用这种方式，因此它们不要求按顺序来消费消息数据，它们更多地是希望能有更好的并发消费能力和吞吐量。

很多消息系统将topic分成若干个partition, 为了增加消费的吞吐量，会一味调大partition个数，这种方式需要综合考量，成本方面不一定是最优的

发布-订阅方式

​ 发布-订阅方式，就是常说的pub-sub方式。

​ 发布者push消息到消息中间件里的某个topic上，各个订阅者都会收到这个topic上的完整的消息，即每个订阅者都能看到一样的完整的topic视图，并且收到的消息的顺序和消息被push到消息中间件时的顺序是一致的。

​ 我们举个例子，比如订阅报纸，每个订阅者的信箱里每天都会收到相同的报纸，而且报纸肯定是按时间先后收到。

​ 有张图来形象地说明一下：

IMG_20200212_145406 (2).jpg

发布-订阅方式可以保证订阅者接收到消息的顺序，这在某些场景下非常有用。比如它可以用来同步数据库的binlog, 订阅者通过这个binlog可以作数据库同步。

。

常见消息中间件

• Apache ActiveMQ, Amazon SQS, IBM Websphere MQ, RabbitMQ, 和 RocketMQ 基本上是 消息队列方式；

• Apache Kafka这个比较有意思，它两种style其实都支持。如果你用来kafka, 那你一定知道在消费时它有个consumer group的概念。

  1. 同一个 consumer group里可以包括多个consumer, 这些同属一个group的consumer消费数据属于消息队（message queuing）的方式；
  2. 如果将每一个consumer group看作是一个整体，假设不存在内部的consumer, 即把这个consumer group看作就是一个consumer ， 那不同的consumer group消费数据就可看作是发布-订阅（pub-sub）方式；

  现在各种消息中间件很多很多，又存在不同的style, 我们在选择的时候还是要根据自己业务的需求来评估选择。