消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: 当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候
异步处理,串行化的功能变成并行化,从而提升系统性能,缩短响应时间 常用于于秒杀、发送短信通知等,需要立即返回结果
在高并发的情况,为了避免大量的请求冲击后端服务,可以使用消息队列暂存请求,后端服务按照自己的重能力,从队列中消费,例如秒杀、埋点场景。 这样可以随时增加服务的实例数量水平扩容,而不用对系统的其他部分做修改
例如一个下单的信息需要同步多个子系统,每个子系统都需要保存订单的数据的一部分,如果光靠订单服务的团队去维护所有的子系统数据同步,代价太大 解决方法是,通过发布订阅模型,订单服务在订单变化 时发送一条消息到一个主题中,所有的下游子系统都订单主题,这样可以每个子系统都可以获得一份完整的订单数据 即使是增加、减少子系统,也不会对订单服务造成任务电话号
优点:轻量,迅捷,容易部署和使用,拥有灵活的路由配置 缺点:性能和吞吐量较差,由于其采用的是Erlang语言不易进行二次开发
优点:性能好,稳定可选,有活跃的中文社区,实时性比较好, 缺点:但是兼容性较差,但随影响力的扩大,以后会有改善
优点:拥有强大的性能及吞吐量,在大数据和流计算领域,几乎所有的相关开源软件都会优先支持kafka 缺点:当消息数量没有那么多的时候,时延会比较高
两个模型的区别:一份消息是否能被多次消费 如果只有一个订阅者,两个模型基本一样,所以发布订阅模型在功能层面是兼容队列模型的
一个严格意义的事务实现是ACID4个属性:原子性、一致性、隔离性、持久性
在分布式系统中,光是要实现数据一致性就已经非常困难了,所以一般只保证达到最终一致性。比较常见的分布式事务实现有
Kafka和RocketMQ都提供了事务相关功能,下面以订单为例看下如何如何实现的
Kafka和RocketMQ都提供了事务相关功能,核心:半消息 ”半消息“:这个半消息不是指消息内容不完整,而是指在事务提交前,对于消费者来说,这个消息是不可见的(sendMessageInTransaction)