聊聊消息中间件

消息中间件，广泛应用于分布式系统的架构设计之中。一提到业务解耦、流量削峰的技术选型，很容易就想到，是时候该消息中间件上场了。

我想聊聊两个问题。

消息中间件从设计来讲，应该有哪些组件？

消息中间件的使用中，常碰到的问题有哪些？又该如何解决？

消息中间件的设计架构

消息中间件的架构，在我看来，应该分解为三个方面：功能模块、高可用、极致性能。

从功能模块的角度讲，目前主流有两种模式：队列模式、订阅模式。

比如rabbitMq，就只支持队列模式；而RocketMq、Kafka，则支持订阅模式。我重点以订阅模式来聊聊。

消息中间件的职责，就是收消息、发消息，这个过程中，有两个难点。

一是多消费者时，如何保证每个消费者都能收到消息？

二是单消费者如果是集群节点，如何让集群的优势得以最大发挥？

以RocketMq为例，就有  Broker、Topic、Queue、Consumer Group  四个角色。

Broker，顾名思义，就是中间件的角色。

Topic，则是一个订阅主题。

Consumer Group：表示消费组，不同消费组，可以消费同一个Topic。同一个消费组，对同一个Topic则是互斥的关系。

Queue：队列，主要目的是保证能并发发送消息给消费者集群。如果没有Queue，由于要保证消息的顺序以及确认消息发送成功，就必须

每发一个消息，并等待消费者返回成功后，才能再发送下一个消息。这就会导致消费者集群形同虚设。

再从高可用的角度来讲，首先最容易想到的方案，就是集群。

对，当然要做集群，但是数据如何治理？是每个节点都保存全量数据，还是做数据切片呢？

目前主流的消息中间件，都没有采用数据切片的方案。主要原因便是实现难度过大。要知道，实现一个好的分布式原生数据系统，难度是

很大的。

极致性能：具体中间件都做了很多性能上的优化。比如Kafka的零拷贝等。

常见问题及解决思路

在使用消息中间件的过程中，我相信你一定碰到过下面这些问题。

消息积压：

这个问题，一般有如下原因。

1. 消费者端消费能力下降。  比如消费端操作的数据库出了问题，比如消费端系统CPU彪高或者内存溢出。只需要对症下药解决即可。

2. 生产者端消息突然增多。  比如突然某个原因发了大量消息，比如业务高峰期出现流量洪峰。 针对这类问题，要么紧急削减消息量，

                                             要么水平扩展消费者集群的数量。

消息丢失：

生产者端消息丢失：  生产者可以通过确保消息发送成功来避免。

中间件消息丢失：      通过配置集群，以及数据持久化，可以避免这个问题。

消费者端消息丢失：  保证业务做完后，再返回中间件成功，可以避免这个问题。

中间件消息事务：

Kafka提供了接口，需要写实现代码。RocketMq有现成的机制，能保证消息的事务性。