核心观点与关键数据
Flipkart 使用案例:构建 Topic-as-a-Service
- 背景:Flipkart 使用 Kafka 进行消息传递,但面临硬件利用率低、开发速度慢、运营负担重等问题。
- 解决方案:采用 Pulsar 构建 Topic-as-a-Service,以减轻集群维护负担,提供统一复制、安全和可扩展的合同。
- 用例特征:
- 耐用性强:采购订单和库存分析。
- 耐用性弱:Clickstream 分析。
- 订购加工:订单系统至仓库管道。
- 消息队列:搜索中的价格标签处理。
- 实时消息传递:低延迟、权衡吞吐量优先。
- 权衡吞吐量:订单取消流。
Pulsar vs Kafka 对比
- Kafka 部署现状:不同配置和大小,介质大小小于 15 个节点、小于 50 个节点、大于 50 个节点,由相关团队异步数据流拥有和经营。
- Pulsar 优势:减少硬件利用率,改进开发人员速度,减轻运营负担,保证正常运行时间和地理位置,无需设置 Kafka 或 Pulsar,快速进入业务逻辑。
构建 Topic-as-a-Service 的原因
- 减轻集群维护的负担。
- 向用户提供可依赖的合同。
- 公司广泛统一复制,安全。
Topic-as-a-Service 特征
- 板载新功能。
- 扩展、架构用户友好的主题管理。
- 遥测租户。
选择 Pulsar 的原因
- 排队和分层存储。
- 成熟地理复制。
- 多租户支持。
- 高可用性。
- 水平扩展。
- 选择 Pulsar 的三个主要优势:容器 on K8s、守护进程在 VM 上、每个区域 1 个集群。
部署拓扑
- 容器 on K8s:守护进程在 VM 上,每个区域 1 个集群,仅取决于生产/调度配额,优先级高,复杂性理想,适合新的和不可预测的工作负载。
- 守护进程在 VM 上:每个区域 1 个集群,与隔离组每个多个群集,区域最大隔离的代价是高操作工作量。
Gatekeeper:直接在 Pulsar 上进行零管理员操作
- 功能:Provision 根据底层租户的保证容量拓扑,用户直接对 Pulsar 进行任何管理操作,禁用业务和组织特定政策,强制执行更简单的入职流程,优惠向平台用户公开的控制平面,抽象与内部 Pulsar 集群的 API 交互。
容量: 预配租户
- 生产吞吐量:1 个分区优化 conf& cpu / mem / tx,经纪人 3 Bookie 合奏能力,建立缩放单位红线,测试量化经纪人和博彩公司增加的影响,以处理扩大某一主题的生产 throughput,处理日益增加的主题热度:消费,地理复制和记账复制在危机中的影响。
混沌测试
- 确保正常运行时间:PodDisruptionBudget。
- 深入挖掘代理负载平衡:K8s 中的 TODO。
- Pulsar 运算符:调优代理对于 addEntryTimeout, readEntryTimeout, zkSessionTimeout。
零数据丢失
- 分类帐法定人数:write = 3,ack = 3。
- 机架感知放置政策。
- 自动恢复已启用。
- 计算 - 存储分离。
- TODO 探索有关主题复制不足统计信息的警报#10013。
安全性:与 OAuth2 和内部 RBAC 集成
- 安全访问主题即服务:对用户而言的所有管理员操作被阻止。仅允许平台管理员进行操作。每个租户都配置了合适的生产/消费角色。pulsar 代理中插入的自定义身份验证提供程序。
- 不支持主动 - 被动主题活动 - 开箱即用,但是...考虑复制订阅默认值。
地理复制及其注意事项
- 收养努力:Pulsar 客户端食谱替换 Kafka,已开始迁移工作内部平台,升级火花 / 骆驼 / 等。
未来路线图
- 改进自动缩放能力。
- 进行生产转换的通用食谱。
- Rollout 基于消耗的计费型号。
- 贡献开源!