腾讯云产品——消息队列Plusar版
1、简介
消息队列Plusar版(TDMQ for Pilsar)是腾讯基于Apache Pulsar自研的消息中间件,提供异步解耦和削峰填谷,适用于互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性,目前大量用在腾讯计费绝大多数场景,包括支付主路径、实时对账、实时监控、大数据实时分析。
2、优势
- 数据强一致性:采用BookKeeper一致性协议,同步刷盘
- 支持百万级消息生产和消费
- 支持百万级topic
- 支持丰富的消息类型,如普通消息、顺序消息(全局顺序/分区顺序)、分布式事务消息、定时消息。
3、应用场景
异步解耦
削峰填谷
顺序收发:确保消息先进先出
分布式事务一致性
数据同步:两个数据中心间数据同步
大数据分析:类似kafka
4、干货
① 原理
Apache Pulsar 是一个发布-订阅模型的消息系统,由 Broker、Apache BookKeeper、Producer、Consumer 等组件组成。
- Producer : 消息的生产者,负责发布消息到 Topic。
- Consumer:消息的消费者,负责从 Topic 订阅消息。
- Broker:无状态服务层,负责接收和传递消息,集群负载均衡等工作,Broker 不会持久化保存元数据,因此可以快速的上、下线。
- Apache BookKeeper:有状态持久层,由一组 Bookie 存储节点组成,可以持久化地存储消息。
Apache Pulsar 在架构设计上采用了计算与存储分离的模式,消息发布和订阅相关的计算逻辑在 Broker 中完成,数据存储在 Apache BookKeeper 集群的 Bookie 节点上。
② Topic与分区
Topic(主题)里面存放着消息,生产者往 Topic 中写消息,消费者从 Topic 中读消息。
分为Partitioned(分区自定义,数据按策略分给各个分区)和no Partitioned(分区为1)
分区 Topic1-Part2 的数据由N个 Segment 组成, 每个 Segment 均匀分布并存储在 Apache BookKeeper 群集中的多个 Bookie 节点中, 每个 Segment 具有3个副本
五、实践
①、定时消息和延时消息
- 微信红包发出后,生产端发送一条延时24小时的消息,到了24小时消费端程序收到消息,进行用户是否已经领走红包的判断,如果没有则退还到原账户。
- 小程序下单某商品后,后台存放一条延时30分钟的消息,到时间之后消费端收到消息触发对支付结果的判断,如果没有支付就取消订单,这样就实现了超过30分钟未完成支付就取消订单的逻辑。
- 微信上用户将某条信息设置待办后,也可以通过发送一条定时消息,服务端到点收到这条定时消息,对用户进行待办项提醒。
六、备注
消息队列这自己之前用的比较少,看过文档之后,我对他的一个理解大概是:一个管道,生产者生产出来,放到管道里,在管道里等待被消费者取走。
再多的emm
文章内容仅用于作者学习使用,如果内容侵犯您的权益,请立即联系作者删除,作者不承担任何法律责任。