MQ 选型以及使用中的问题和解决方案

MQ(Message Queue)消息队列

MQ:是一种应用程序对应用程序传递消息的中间件，是通过读写出入队列来通信。

三种通讯模式 1.点对点，2.多点广播，3.发布和订阅（一般用这个）

优点：

1.异步：执行失败重试，提高接口的性能（失效策略；数据回补）

2.解耦：利用MQ降低系统的耦合性（系统重构）

3.削峰：将一些无需及时返回且耗时的操作提取出来，进行异步处理，从而节省服务器的响应时间来提高系统的吞吐量（秒杀，公司的活动:抢金币）

缺点：

1.MQ一旦挂了，整个系统就奔溃了（高可用）

2.系统的复杂度提高（消息堆积）

3.数据不一致（消息重复，消息顺序，消息丢了）

如何选型：RabbitMQ,RocketMQ,Kafka

Kafka是主要用于配合大数据类的系统来进行实时数据计算、日志采集等场景（主要支持简单的MQ功能）

我们一般在RabbitMQ和RocketMQ中间来选择

选择RocketMQ的理由（阿里出品）：

1.topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降（RabbitMQ会大幅下降）

2.分布式集群，每个部分都可以水平扩展（RabbitMQ主从集群）

3.java开发（RabbitMQ用erlang语言开发）

4.吞吐量是10万级（RabbitMQ是万级）

缺点：

1.延时毫秒级（RabbitMQ是微秒级）

2.社区活跃度一般（RabbitMQ比较好版本迭代特别快）

 

MQ的高可用

RabbitMQ是镜像集群模式（主从）

Kafka是分布式集群（副本集，HA），每个节点都有一个replicate备份。读写都在leader节点

RocketMQ是分布式集群如下

Name Server：主要提供轻量级查找和路由服务（保存了其它三部分的信息）(各个节点之间不通信)

Broker Cluster:轻量的topic和queue机制（消息的存储，支持push和pull）

Product Cluster：分布式的producers通过负载均衡模型向broker发送消息

Consumer Cluster：支持push,pull,支持集群消费与消息广播同时提供实时订阅

 

MQ的消息幂等性（不重复）

造成的原因：1.系统重启  2.网络异常  3.消费失败

解决方案

1. 消息的唯一标识存入redis中并进行判断
2. 数据库的存储判断

MQ丢消息

1. producter：发送消息状态超时或者失败，则会触发默认的2次重试（支持日志的索引查找）
2. broker：是一主多从的节点，同时支持同步和异步刷盘的策略，保证消息落到本地内存中，消息也支持持久化到commitlog里面，即使宕机，未消费的消息也可以加载出来
3. consumer：确保拉取到的消息成功消费，consumer自身维护了一个持久化的offset，消费成功后才会更新自己的offset，offset会持久化到本地，即使consumer挂掉重启之后可以继续拉取offset之前的消息到本地

MQ消息的积压

策略：超出了buffer，也可以丢弃，然后再从CommitLog中补数据

打开rocketmq的控制台查看是历史消费记录，如果是消息写入速度大于消息的消费速度，调整业务代码或对消费者进行扩容

Consumer消费消息出现问题，只能操作临时紧急扩容了，具体操作步骤和思路如下：

1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉

2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量

3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue

4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据

5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据

6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

MQ消息的顺序

避开这种使用场景