消息中间件如何对接大数据

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

概述

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

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

消息队列方式

消息队列方式，就是 Message queuing。

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

用张图来形象地说明一下：

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

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

发布-订阅方式

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

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

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

用张图来形象地说明一下：

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

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

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

常见的消息中间件

• 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）方式；

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

本文转载自 360 云计算公众号。

原文链接：https://mp.weixin.qq.com/s/oiaXjFxNcwJenkGuJBPm5Q