腾讯云产品——消息队列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
文章内容仅用于作者学习使用，如果内容侵犯您的权益，请立即联系作者删除，作者不承担任何法律责任。
