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.消费失败
解决方案
- 消息的唯一标识存入redis中并进行判断
- 数据库的存储判断
MQ丢消息
- producter：发送消息状态超时或者失败，则会触发默认的2次重试（支持日志的索引查找）
- broker：是一主多从的节点，同时支持同步和异步刷盘的策略，保证消息落到本地内存中，消息也支持持久化到commitlog里面，即使宕机，未消费的消息也可以加载出来
- 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消息的顺序
避开这种使用场景