消息队列mq
参考资料：https://www.jianshu.com/p/824066d70da8
一、消息中间件的主要作用和功能：
1）异步解耦和分流；
2）挡住前端的数据洪峰，保证后端系统的稳定性(这就要求消息中间件具有一定的消息堆积能力)。
二、消息队列基础：
1）什么是消息中间件？
参照：https://blog.csdn.net/winter_chen001/article/details/78409125
关注于数据的发送和接收，利用高效可靠的异步消息传递机制集成的分布式系统。
2）java消息中间件的特点？
有两种模式：p2p(点对点模式)，pub/sub(发布/订阅模式)。
3）消息队列包括哪些部分？
producer--消息生产者
consumer--消息消费者
producer group--
consumer group--
broker--消息中转者，负责存储消息，转发消息，一般也称为server.
topic--topic 是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，
一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。
tag--标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
广播消费--一条消息被多个consumer消息，即使consumer属于同一个group，也会被group中的每个consumer消费。
集群消费--一个consumer group 中的consumer实例平均分摊消费消息。
基础：
producer向一些队列轮流发送消息，队列集合称为topic,consumer如果做广播消费，则一个consumer实例消费这个topic对应的所有队列。
如果做集群消费，则多个consumer实例平均消费这个topic对应的队列集合。
producer group--用来表示一个发送消息应用，一个group下可以包含一个或多个producer实例。一个group可以发送多个topic消息。
consumer group--用来表示一个消费消息应用，一个group下可以包含一个或多个consumer实例。
集群模式下，group下的多个consumer均摊消费消息。广播模式下，group下的多个consumer消费全部消息。
4）消息发送的方式
A、同步发送：同步发送就是指 producer 发送消息后，会在接收到 broker 响应后才继续发下一条消息的通信方式。响应速度最慢，使用在重要的消息场景。
B、异步发送：异步发送是指 producer 发出一条消息后，不需要等待 broker 响应，就接着发送下一条消息的通信方式。响应速度一般。
C、单向发送：producer 只发送请求不等待响应结果。响应速度最快，使用场景(日志收集);
发送方式 发送TPS 发送结果响应 可靠性
同步发送 小 有 不丢失
异步发送 中 有 不丢失
单向发送 大 没有 可能丢失
5）消息消费方式
A、集群消费：当 consumer 使用集群消费时，每条消息只会被 consumer 集群内的任意一个 consumer 实例消费一次。会进行消息失败重投。
B、广播消费：当 consumer 使用广播消费时，每条消息都会被 consumer 集群内所有的 consumer 实例消费一次，
也就是说每条消息至少被每一个 consumer 实例消费一次。不会进行消费失败重投。
推荐使用集群的方式进行广播，实现方式如下：
如果业务上确实需要使用广播消费，那么我们可以通过创建多个 consumer 实例，每个 consumer 实例属于不同的 consumer group，但是它们都订阅同一个 topic。
6）订阅关系一致性
这里所说的其实就是订阅关系一致性。在 RocketMQ 中，订阅关系由 Topic和 Tag 组成，因此要保证订阅关系一致性，就必须同时保证这两点：
A、订阅的 Topic 必须一致
B、订阅的 Topic 中的 tag 必须一致
7）消息重试(消息重试只针对集群消费模式)
A、什么是消息重试？
就是当消费者消费消息失败后，broker 会重新投递该消息，直到消费成功。
在 RocketMQ 中，当消费者使用集群消费模式时，消费者接收到消息并进行相应的逻辑处理之后，最后都要返回一个状态值给 broker。
这样 broker 才知道是否消费成功，需不需要重新投递消息。也就是说，我们可以通过设置返回的状态值来告诉 broker 是否重新投递消息。
B、其实 RocketMQ 并不会无限制地重试下去，默认每条消息最多重试 16 次。
C、失败16次之后，消息就不会再投递给消费者，而是将消息放到相对应的死信队列中。这时候我们就需要对死信队列的消息做一些人工补偿处理，
因为这些消息可能本身就有问题，也有可能和消费逻辑调用的服务有关等，所以需要人工判断之后再进行处理。
8）消息幂等
A、消息出现重复的两种情况：
1.发送时消息重复；
2.投递时消息重复；
B、处理方法
处理建议就是通过业务上的唯一标识来作为幂等处理的依据。
存在的问题：
1.消息队列用过哪几种，为什么用，熟悉消息队列的哪些方面？---[消息队列]
2.消息队列：重试/补尝机制，如何防止消息重复消费/消息漏发/消息丢失/怎样保证消息的顺序消费
2.1 答案如上：(二/7)
2.2 如何防止消息重复消费--消费端去重？
消费消息过程要在应用层做到幂等(幂等：在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。)
例：将消息的唯一键，也可以是消息内容中的唯一标识字段，例如订单消费之前判断是否在 等，消费之前判断是否在 Db 或Tair( 全局 KV 存储 )中存在，如果不则插入并消费否则跳过。
2.3 消息漏发/消息丢失如何解决？
参考：https://www.cnblogs.com/520playboy/p/6750023.html
https://www.jianshu.com/p/11e875074a8f
http://www.sohu.com/a/129521820_487514
https://blog.csdn.net/u010634288/article/details/56049305
2.4 如何顺序消费消息？
最佳实践方案：
1. Producer
1) Topic
一个应用尽可能用一个Topic，消息子类型用tags来标识，tags可以由应用自由设置。只有发送消息设置了tags，消费方在订阅消息时，才可以利用tags 在broker做消息过滤。
2) key
每个消息在业务层面的唯一标识码，要设置到 keys 字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引(哈希索引)，应用可以通过 topic，key来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证key 尽可能唯一，这样可以避免潜在的哈希冲突。
//订单Id
String orderId="20034568923546";
message.setKeys(orderId);
3) 日志
消息发送成功或者失败，要打印消息日志，务必要打印 send result 和key 字段。
4) send
send消息方法，只要不抛异常，就代表发送成功。但是发送成功会有多个状态，在sendResult里定义。
SEND_OK：消息发送成功
FLUSH_DISK_TIMEOUT：消息发送成功，但是服务器刷盘超时，消息已经进入服务器队列，只有此时服务器宕机，消息才会丢失
FLUSH_SLAVE_TIMEOUT：消息发送成功，但是服务器同步到Slave时超时，消息已经进入服务器队列，只有此时服务器宕机，消息才会丢失
SLAVE_NOT_AVAILABLE：消息发送成功，但是此时slave不可用，消息已经进入服务器队列，只有此时服务器宕机，消息才会丢失
2. Consumer
1) 幂等
RocketMQ使用的消息原语是At Least Once，所以consumer可能多次收到同一个消息，此时务必做好幂等。
2) 日志
消费时记录日志，以便后续定位问题。
3) 批量消费
尽量使用批量方式消费方式，可以很大程度上提高消费吞吐量。