1. MQ 核心架构
MQ核心架构，它是由发送端、服务端、固话存储、接收端四大部分组成。
2. MQ如何保证消息必达?
- 消息落地
- 超时，重传，确认
mq为保证消息的可达性，超时，重传，确认机制可能导致MQ，或者业务方收到重复的消息，从而对业务产生消息。怎么解决慢慢往下看。
3. MQ 如何做到，消息幂等?
什么是幂等性？
使用同样的条件，一次请求和重复多次请求对系统资源的影响是一致的。
MQ消息发送上半场，即上图中的1-3：
（1）发送端MQ-client将消息发送给服务端MQ-server
(2) 服务端MQ-server将消息落地
（3）服务端MQ-server回ACK响应给发送端MQ-client
如果图上3丢失，发送端MQ-client超时后会重发消息，可能会导致MQ-server收到重复的消息。为了避免步骤2落地重复消息，对每条消息，MQ系统内部必须生成一个inner-msg-id，作为去重和幂等的依据，inner-msg-id的特性是：
（1）全局唯一
（2）MQ生成，具备业务无关性，对消息发送方和消息接收方屏蔽
（3）重复的消息为一样的inner-msg-id
（4）能保证上半场重发，也只有1条消息落到MQ-sercer的DB中，实现上半场幂等
MQ消息接收下半场，如何保证幂等性，即图中的4-6：
（4）MQ-server将消息发给接收端MQ-client
(5) MQ-client回ACK给服务端
(6) MQ-server将落地消息删除
需要注意的是：MQ-client回ACK给MQ-server，是消息消费业务方的主动调用行为，不能由MQ-client自动发起，因为MQ系统不知道消费方什么时候真正消费成功。
如果5丢失，MQ-server超时后会重发消息，可能会导致MQ-client收到重复消息。这样势必导致业务方重复消费。为了保证业务幂等性，业务消息中，必须有一个unique-biz-id，作为去重和幂等的依据。这个业务ID特性是：
（1）对于同一个业务数据，全局唯一
（2）由业务消息发送方生成，业务相关
（3）由业务消息消费方负责判断是否重复，以保证幂等
（4）业务ID可以是：贴子ID,订单ID等
（5）保证了下半场消息消费业务方即使收到重复消息，也只有1条消息被消息，保证了幂等。
综上：
上半场幂等的关键：MQ-client生成inner-msg-id，核心是消息去重
下半场幂等的关键：业务方带入unique-biz-id，业务方通过全局唯一的业务 id 去自行保证
业务幂等性，需要 MQ 和消息接收方配合完成！
4. 有人会问: 开发中我们只需要关心unique-biz-id就行了么？
答：如果MQ实现了相关重试功能等，那么“YES”
5.相关知识
Pub-Sub 消息传递的工作流程
在 Apache Kafka 中，Pub-Sub 消息传递的逐步工作流程是：
（1）Kafka 生产者将消息发送到主题。
（2）Kafka Brokers 将所有消息存储在为该特定主题配置的分区中，确保分区之间消息的平等分布。例如，如果生产者发送两条消息并且有两个分区，Kafka 将在第一个分区中存储一条消息，在第二个分区中存储第二条消息。此外， Kafka Consumer 订阅特定主题。
（3）一旦消费者订阅了一个主题，Kafka 就会将该主题的当前偏移量提供给消费者，并将该偏移量保存在 Zookeeper ensemble 中。此外，消费者将定期向 Kafka 请求新消息（如 100 毫秒）。或者 kafka push 新消息
(4) Kafka 将在收到来自生产者的消息后立即将消息push给消费者。
(5)消费者将收到消息并进行处理。
(6)然后 Kafka 代理收到已处理消息的确认。
(7)此外，一旦 Kafka 收到确认，偏移量就会更改并更新为新值。即使在服务器异常期间，消费者也可以正确读取下一条消息，因为 ZooKeeper 会维护偏移量。
(8)但是，直到消费者停止请求，流程才会重复。
(9)作为一个好处，消费者可以在任何时候回退/跳过主题的任何偏移量，并且还可以读取所有后续消息，作为一个标准的愿望。
