一、什么是消息队列？

消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：
当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候

二、消息队列有什么用？

1. 异步处理，提高响应速度

将串行化的功能变成并行化，从而提升系统性能，缩短响应时间
常用于于秒杀、发送短信通知等，需要立即返回结果

2. 流量控制

在高并发的情况，为了避免大师的请求冲击后端服务，可以使用消息队列暂存请求，后端服务按照自己的重能力，从队列中消费，例如秒杀、埋点场景。
这样可以随时增加服务的实例数量水平扩容，而不用对系统的其他部分做修改

3.系统解耦

例如一个下单的信息需要同步多个子系统，每个子系统都需要保存订单的数据的一部分，如果光靠订单服务的团队去维护所有的子系统数据同步，代价太大
解决方法是，通过发布订阅模型，订单服务在订单变化 时发送一条消息到一个主题中，所有的下游子系统都订单主题，这样可以每个子系统都可以获得一份完整的订单数据
即使是增加、减少子系统，也不会对订单服务造成任务电话号

三、消息队列有什么缺点？

1. 同步消息改成了异步，增加了系统的调用链，增加了系统的复杂度
2. 降低了数据一致性，如果要保持一致性，需要高代价的补偿（如分布式事务、对账）
3. 引入了消息队列带来的延迟问题

四、常见的消息队列

RabbitMQ https://www.rabbitmq.com/

优点：轻量，迅捷，容易部署和使用，拥有灵活的路由配置
缺点：性能和吞吐量较差，由于其采用的是Erlang语言不易进行二次开发

RocketMQ http://activemq.apache.org/

优点：性能好，稳定可选，有活跃的中文社区，实时性比较好，
缺点：但是兼容性较差，但随影响力的扩大，以后会有改善

Kafka http://kafka.apache.org/

优点：拥有强大的性能及吞吐量，在大数据和流计算领域，几乎所有的相关开源软件都会优先支持kafka
缺点：当消息数量没有那么多的时候，时延会比较高

五、消息队列的两种模型

1. 点对点模型

• 每个消息只有一个接收者（Consumer），一旦被消息，就不再在消息队列中
• 发送者和接收者间没有依赖性，发送者发送消息后，不管有没有接收者在运行，不会影响下一次发送
  

2. 发布订阅模型

• 每个消息可以有多个订阅者
• 每个订阅者都可以接收到主题的所有消息
  

两种模型区别

两个模型的区别：一份消息是否能被多次消费
如果只有一个订阅者，两个模型基本一样，所以发布订阅模型在功能层面是兼容队列模型的

六、消息队列如何实现分布式事务

一个严格意义的事务实现是ACID4个属性：原子性、一致性、隔离性、持久性

• 原子性：一个事务操作不可分割，要么全部成功，要么全部失败，不能一半成功一半失败
• 一致性：事务执行完成之前的时间点，读到的一定是更新前的数据，之后读到的一定是更新后的数据
• 隔离性：一个事务的执行不能被其他事务干扰（一个事务内部的操作及使用的数据对正在进行的其他事务是隔离的，并发执行的各个事务之间不能互相干扰）
• 持久性：事务一旦提交，后续的其他操作和故障都不会对事务的结果有任何影响

在分布式系统中，光是要实现数据一致性就已经非常困难了，所以一般只保证达到最终一致性。比较常见的分布式事务实现有

1. 2PC（Two-phase Commit）二阶段提交
2. TCC（Try-Confirm-Cancel）
3. 事务消息

消息队列分布式事务实现

Kafka和RocketMQ都提供了事务相关功能，下面以订单为例看下如何如何实现的

Kafka和RocketMQ都提供了事务相关功能，核心：半消息
”半消息“：这个半消息不是指消息内容不完整，而是指在事务提交前，对于消费者来说，这个消息是不可见的（sendMessageInTransaction）

如果数据库事务提交失败怎么办

1. 业务代码中反复重试提交，直到提交成功
2. 删除之前创建的订单进行补偿
3. 提供一个反查本地事务状态接口给MQ，告知成功或失败（RocketMQ支持）