不同消息队列有各自合适的应用场景
如果你的工作以业务开发为主
建议了解一下消息队列背后的设计思想,以及基本特性
RocketMQ 应用
RocketMQ 前身是淘宝的MetaQ,加入 Apache 基金会
RocketMQ 提供低延时,高可靠的消息发布与订阅服务
![](https://img.haomeiwen.com/i7399010/92397ace6e69f54c.jpg)
NameServer 主要功能——管理 Broker ,以及进行消费的路由信息管理
在服务器启动时,节点会注册到 NameServer 上,通过心跳保持连接,并记录各个节点状态
Broker 是消息存储的承载,管理生产者和消费者的消费情况
Broker 可以扩展副本机制,通过主从节点间的数据同步保证高可用
消息队列的 Topic 会分散在多个队列中传输
Broker 可以进行横向扩展—— 如果消息队列集群不能满足目前的业务场景,可以增加新的机器,扩展Broker 集群
新的 Broker 节点启动以后,会注册到 NameServer 上
集群中的生产者和消费者通过 NameServer 感知到新的节点
RocketMQ 支持 Tag,Tag是对 Topic 的进一步扩展
例如:订单消息有订单创建,订单支付,订单配送等不同的消息
商品消息会有商品价格更新,库存更新等不同的分类
Tag——把订单消息统一为 Order-Topic
继续创建 Order-Create-Message,Order-Pay-Message 等子主题
实例一:实现 Binlog 分发
在大多数业务场景下,会有文件索引,各类缓存的存在
电商中的订单信息,订单信息在用户端的展示—— ElasticSearch 等文件索引
在订单状态修改后,需要实时同步修改
如何同步数据呢? 基于 Binlog 的数据同步
![](https://img.haomeiwen.com/i7399010/118328c53ec1edbd.jpg)
实例二:实现分布式一致性
事务消息时支持类似 XA 规范的分布式事务功能,通过 RocketMQ 达到分布式事务的最终一致
以电商中的下单后扣款为例,用户在完成商品购买后,点击确认支付会调用交易模块的服务,更新账号金额,或者从第三方支付扣款。
分布式事务,可以使用 TCC 进行改造,也可以使用基于消息队列的本地消息表
RocketMQ 在事务消息的实现中添加了一个 Half Message 的概念
Half Message 表示事务消息处于未完成状态
可以实现一个类似于两个阶段提交的流程,实现最终的一致性
网友评论