展开查看详情
1 .AscentStream 基于 Apache Pulsar 探索
上海谙流科技有限公司 EventBus 应用场景
@傅腾 社区负责人
2 .社区发展历程
633+ Contributors
45+ Committers
3.4K+ Forks
13.2 K+ Stars
3 .Apache Pulsar 中文社区落地案例（仅部分）
一致性：强一致性 + 高性能； 高可用：异常情况自动修复； 快速响应：极速扩容、平滑响应；
4 .Apache Pulsar 海外社区落地案例（仅部分）
5 .公司介绍
AscentStream l 致力于打造金融级云原生消息流平台，助力企业挖掘实时数据价值。
ān l 由 Apache Pulsar 与 Apache BookKeeper 创始团队成员组建。
上海谙流科技有限公司 l 专注中国商业化和社区，满足信创要求。
7 .消息驱动 vs 事件驱动（EDA）
消息驱动： 事件驱动：
l 生产者对消息的投递状态保持关注。 l 生产者发布事件后不关心消费者的状态，强调“既定事实”。
l 上下游通过消息队列（MQ）紧密协作。 l 事件可以广播给多种类型的消费者，如 webhooks、其他MQ、邮件
l 消费者需要主动从MQ拉取消息。 等。
l 消息传递复杂，需处理事务、顺序、消费策略等。 l 事件由 Event Bus 推送至消费者，无需消费者监听。
l 消费者限定为MQ客户端。 l 事件格式（CloudEvent规范）和大小有明确的限制，以简化交互。
l 支持多种设备作为事件源，不限于 MQ 客户端。
https://serverlessland.com/event-driven-architecture/visuals/message-queue-vs-event-broker
8 .事件处理的“不可能三角”
订单与库存：
• 一致性优先：确保库存数据准确，可能导致订单服务在网络问题
时无法处理新订单。
• 可用性优先：即使部分数据过时，仍然处理新订单，可能导致库
存数据暂时不一致。
• 分区容错性优先：系统继续运作，即使部分节点间通信中断。
实际业务中，充满了权衡！
电商平台可能在网络问题时牺牲一致性以保持订单处理能力，后续通过补偿策略解决数
据不一致。
• 一致性（Consistency）：所有节点看到相同数据
• 可用性（Availability）：每个请求都得到响应
• 分区容错性（Partition tolerance）：分区故障发生时系统可以继续运作
9 .dotnetcoreCAP：经典 CAP 架构
CAP 类框架的作用
• 事务保障
• 发布事件
• 服务订阅
• 重试机制
• 顺序保障
• 分布式跟踪（*）
• 管控和可观测性
CAP 框架的关键优势在于简化了分布式事务的复杂性，将分布式事务“降维”到单数据库事务，
同时保证事件的可靠传输。
https://github.com/dotnetcore/CAP
10 .当 Pulsar 遇到 CAP 会发生什么？
当 Pulsar 遇到 CAP 会发生什么？
11 .Pulsar核心能力: 必达性
生产：
Pulsar发送一条消息生产请求，都会以最终应答来判
断该消息是否已成功送达，超时情况需要重试，因此
接收成功应答则一定已持久化到MQ中。
消费：
Pulsar为消费者维护了消息偏移量。判断一条消息是
否成功消费的依据，是Broker成功收到客户端发送的
ACK应答，除此之外任何失败的情况，都会进行消费
重试。
持久化：
消息数据采用多副本存储模式，一条消息持久化过程
中需要满足单副本同步刷盘，并半数以上副本成功应
答，才代表成功写入并返回给Producer。Topic、消
费关系持久化到ZK。
消息去重问题：
Pulsar满足至少一次处理语义，这必然会产消费重复，
在MQ层面实现消息去重的代价非常大，行业内解决
方案一般建议在业务层实现幂等，从根上解决。
12 .• Pulsar核心能力: 局部顺序消费 (顺序性)
顺序消费：
顺序消费一般可以分为全局顺序和局部顺序，
全局顺序要求非常苛刻，一般无法满足生产要
求，更多的是局部顺序更贴近实际业务，要实
现局部顺序需要生产端和消费端一起配合。
1. 局部顺序保证的是某一类消息顺序生产和消
费，例如同一个订单从创建到关键整个过程顺
序，因此可以为每条消息设置一个KEY，来标
记属于同一个订单消息。
2. 相同KEY的消息需要在生产和消费时在同一
个客户端处理，Pulsar具备消息生产按照KEY
进行路由，保证相同KEY在同一个分区中，消
费时可指定消费模式，确保同一个KEY被同个
消费端处理。
3. Pulsar除了传统的按分区消费的能力（消费
者个数不能超过分区个数），还支持直接按 注意：在对Topic进行动态扩容时，会丢失小
KEY进行消费，确保相同的KEY只被一个消费者 部分顺序性，在实际生产中，通常选择在没有
消费，同时突破了消费者个数。如果不考虑任 流量的时候进行操作。
何顺序，还支持类似RabbitMq的共享模式。
13 .• Pulsar核心能力: 高性能、低延迟
高性能：
1、多线程设计充分利用CPU硬件资源。
2、多副本并行请求处理，单副本组提交刷盘。
3、多Cache设计大概率避免消息请求穿透Broker到
达磁盘，提升消费速率。
低延迟：
1、同一资源写入无锁化，避免资源争抢。
2、顺序刷盘、多磁盘能力保证IO处理的稳定性。
3、Topic数据不与存储节点强绑定，避免异常节点导
致延迟持续增高。
14 .• Pulsar核心能力: 多租户与订阅模型
15 .• 云原生带来的运维轻量化、流程自动化
Pulsar Operator 将运维流程工具化，降低人为操作风险，释放人力资源
集群部署
扩容
故障处理
版本更新
应急恢复
......
集群缩容
日常运营一个MQ过程中，有近50%的时间需 我们将这些常规操作沉淀到Pulsar Operator中，释放
要处理常规的维护工作 更多精力到更有价值的工作中
16 .Pulsar 核心能力及其生态扩展
可信云 · 分布式消息队列
能力项列表
17 .当 CAP 遇到 Pulsar 会发生什么？
当 CAP 遇到 Pulsar 会发生什么？
Pulsar 自带 CAP 属性，基于 Pulsar 很容易打造企业自己的 EventBus。同
时基于 Pulsar 优秀的高级特性，可以衍生出更多的事件处理能力。
18 .衍生场景 1：大集群，降本
某客户前期使用MQ过程中，由各业务方独立建设，系统中并存了近百套集群，机器利用率低，运维复
案例 杂，开发运维成本居高。
APP1 APP2 APP3 APP4 APP5
Topi Topi Topi
c
Topi c
Topi c
Topi
APP2
APP5 c
Topi c
Topi c
Topi
c c c
租户1 租户2 租户3
APP6
APP3
APP4
APP1
利用Pulsar多租户和云原生弹性扩缩容的特性，统一了不同技术栈，将近百套集群缩减为6套集群，
大大降低了人员维护成本和硬件成本，提升了业务协同效率
19 .衍生场景 2：责权明晰
例如：消息没收到？
l 查看生产日志确认是否成功？
l 查看消费者日志是否报错？
l 查看mq日志，查看发送到了哪台？
l 查看mq日志，确认消费者偏移量的情况
l 日志不全，重发一条？
20 .衍生场景 3：多地多中心 + 实时和离线分析
某证券客户需要将北京、上海、深圳和香港等多地的交易类数据(委托、成交、资金和持仓等)汇集到南
案例 京机房进行统一的策略计算及其他业务场景使用。
(客户提供的测试报告)
北京 上海 深圳 香港
app app app app
时耗更低更稳定
Plusar Plusar Plusar Plusar
GEO
吞吐5倍+
南京
Plusar
消费app
⾼可⽤：不丢不重
利用 Pulsar GEO + KeyShare + 防重机制
降低了时耗的同时也大幅提升了性能
21 .加入我们
加入 Apache 社区 谙流科技
22 .加入 Apache 社区 谙流科技
THANK
YOU
热门城市
