消息中间件一些基本知识

RocketMq 基本组成

Producer

消息生产者，生产者的作用就是将消息发送到MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到MQ。

Producer Group

生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。在这里可以不用关心，只要知道有这么一个概念即可。

Consumer

消息消费者，简单来说，消费MQ上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，还是直接存储到数据库等取决于业务需要。

Consumer Group

消费者组，和生产者类似，消费同一类消息的多个 consume实例组成一个消费者组。

Topic

是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单Topc存放订单相关的消息，一个是库存 Topic存储库存相关信息

Message

Message是消息的载体。一个 Message必须指定 topIc，相当于寄信的地址。 Message还有一个可选的tag设置，以便消费端可以基于tag进行过滤消息。也可以添加额外的键值对，例如你需要一个业务key来查找boke上的消息，方便在开发过程中诊断问题

Tag

标签可以被认为是对Topc进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。

Broker

Broker是 RocketMQ系统的主要角色，其实就是前面一直说的MQ. Broker接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。

Name Server

Name server为 producer和 consumer提供路由信息。

MQ的一些常见问题

消息顺序问题

解决方案：
保证生产者 - MQServer - 消费者是一对一的关系
缺点：

• 并行度降低（吞吐不够）
• 更多的异常处理，比如：只要消费端岀现问题，就会导致整个处理流程阻塞，我们不得不花费更多的精力来解决阻塞的问题。
• 不关注顺序的业务更多

建议从业务逻辑出发保证顺序

消息重复发送

造成消息重复的根本原因是：网络不可达。
所以解决这个问题的办法就是绕过这个问题。那么问题就变成了：如果消费端收到两条一样的消息，应该怎样处理？
消费端处理消息的业务逻辑保持幂等性。只要保持幂等性，不管来多少条重复消息，最后处理的结果都一样。保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息，或者用数据库联合唯一索引等保证。

如何解决消息队列延时以及过期失效问题？消息队列满了以后该如何解决？有几百万消息持续积压几小时，说说怎么解决？

目前找到的比较妥当的处理方案：紧急扩容
一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下：

• 先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉
• 新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
• 然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
• 接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
• 这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据来消费数据
• 等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息