一、什么是消息队列?
消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为:
当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候
二、消息队列有什么用?
1. 提高响应速度
异步处理,串行化的功能变成并行化,从而提升系统性能,缩短响应时间
常用于于秒杀、发送短信通知等,需要立即返回结果
2. 流量控制
在高并发的情况,为了避免大量的请求冲击后端服务,可以使用消息队列暂存请求,后端服务按照自己的重能力,从队列中消费,例如秒杀、埋点场景。
这样可以随时增加服务的实例数量水平扩容,而不用对系统的其他部分做修改
3.系统解耦
例如一个下单的信息需要同步多个子系统,每个子系统都需要保存订单的数据的一部分,如果光靠订单服务的团队去维护所有的子系统数据同步,代价太大
解决方法是,通过发布订阅模型,订单服务在订单变化 时发送一条消息到一个主题中,所有的下游子系统都订单主题,这样可以每个子系统都可以获得一份完整的订单数据
即使是增加、减少子系统,也不会对订单服务造成任务电话号
三、消息队列有什么缺点?
- 同步消息改成了异步,增加了系统的调用链,增加了系统的复杂度
- 降低了数据一致性,如果要保持一致性,需要高代价的补偿(如分布式事务、对账)
- 引入了消息队列带来的延迟问题
四、常见的消息队列
RabbitMQ https://www.rabbitmq.com/
优点:轻量,迅捷,容易部署和使用,拥有灵活的路由配置
缺点:性能和吞吐量较差,由于其采用的是Erlang语言不易进行二次开发
RocketMQ http://activemq.apache.org/
优点:性能好,稳定可选,有活跃的中文社区,实时性比较好,
缺点:但是兼容性较差,但随影响力的扩大,以后会有改善
Kafka http://kafka.apache.org/
优点:拥有强大的性能及吞吐量,在大数据和流计算领域,几乎所有的相关开源软件都会优先支持kafka
缺点:当消息数量没有那么多的时候,时延会比较高
五、消息队列的两种模型
1. 点对点模型
- 每个消息只有一个接收者(Consumer),一旦被消息,就不再在消息队列中
- 发送者和接收者间没有依赖性,发送者发送消息后,不管有没有接收者在运行,不会影响下一次发送
2. 发布订阅模型
- 每个消息可以有多个订阅者
- 每个订阅者都可以接收到主题的所有消息
两种模型区别
两个模型的区别:一份消息是否能被多次消费
如果只有一个订阅者,两个模型基本一样,所以发布订阅模型在功能层面是兼容队列模型的
六、消息队列如何实现分布式事务
一个严格意义的事务实现是ACID4个属性:原子性、一致性、隔离性、持久性
- 原子性:一个事务操作不可分割,要么全部成功,要么全部失败,不能一半成功一半失败
- 一致性:事务执行完成之前的时间点,读到的一定是更新前的数据,之后读到的一定是更新后的数据
- 隔离性:一个事务的执行不能被其他事务干扰(一个事务内部的操作及使用的数据对正在进行的其他事务是隔离的,并发执行的各个事务之间不能互相干扰)
- 持久性:事务一旦提交,后续的其他操作和故障都不会对事务的结果有任何影响
在分布式系统中,光是要实现数据一致性就已经非常困难了,所以一般只保证达到最终一致性。比较常见的分布式事务实现有
- 2PC(Two-phase Commit)二阶段提交
- TCC(Try-Confirm-Cancel)
- 事务消息
消息队列分布式事务实现
Kafka和RocketMQ都提供了事务相关功能,下面以订单为例看下如何如何实现的
Kafka和RocketMQ都提供了事务相关功能,核心:半消息
”半消息“:这个半消息不是指消息内容不完整,而是指在事务提交前,对于消费者来说,这个消息是不可见的(sendMessageInTransaction)
如果数据库事务提交失败怎么办
- 业务代码中反复重试提交,直到提交成功
- 删除之前创建的订单进行补偿
- 提供一个反查本地事务状态接口给MQ,告知成功或失败(RocketMQ支持)