核心观点与关键数据
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 基于消耗的计费型号。
- 贡献开源！
