Frank Kelly - 使用 Pulsar 实时流式传输数百万次联络中心互动
AI智能总结Cogito Corp 的实时通话流处理方案
公司概况
- 成立时间：2007年，源于MIT，总部位于波士顿，现拥有全球工程足迹。
- 愿景：提升实时的人际交流质量。
- 产品：提供呼叫中心AI解决方案，通过分析人类语音并提供即时指导来增强情感智能和客户服务。
架构与用例
- 架构：
- 实时音频和分析结果由AI/ML模型生成。
- 每个客户通话被拆分为单独的逻辑单元“间隔”，每个间隔由两个Pulsar主题支持。
- 实时音频主题和实时分析主题。
- 二进制格式被分割成离散的消息，去重非常重要。
- 预计15,000并发用户将产生1.5万到2万个主题，每个主题的吞吐量约为32KB/s。
- 用例：
- 大量吞吐量（约10Gbps）。
- 需要精确的时间顺序和去重功能。
- 接近实时的要求（<250ms）。
挑战
- 挑战：
- Zookeeper存储所有命名空间下的主题在单个ZNode下。
- 消息分发可能会因订阅/消费者消息积压而导致停止。
- 客户端性能问题，包括发送异步消息和启用批量发送。
- 默认超时设置过高，不适合实时系统。
- 持久性和非持久性选择。
初步经验教训
- 初步经验：
- 15,000用户导致5Gbps音频数据流入，在12小时内产生20TB的数据。
- 使用开放订阅可以防止主题数据被删除。
- Broker去重有自己的订阅机制。
- 磁盘空间管理，包括书签压缩阈值、分层存储等。
Kubernetes 经验教训
- 配置：
- 暂不开启Topic级别的指标暴露给Prometheus。
- 使用Prometheus/Grafana进行被动监控。
- 与Prometheus警报集成，并发送通知至Slack/PagerDuty。
- 命名空间捆绑：
- 默认情况下，15个Broker的命名空间捆绑数为128。
- 禁用捆绑拆分以解决特定问题。
- 负载均衡：
- 调整Managed Ledger的默认参数，优化写入和读取吞吐量。
关键性能和扩展设置
- 错误：
- 写缓存不足导致数据积压。
- 关键指标：
- Bookie：throttled_write_requests, rejected_write_request。
- Broker：ml_cache_hits_rate, ml_cache_misses_rate。
- 磁盘和内存配置：
- 使用GP3卷，最大IOPS和带宽设置。
- Broker缓存参数调整。
- Bookie参数调整，包括写缓存大小和RocksDB块缓存大小。
- 扩展方法：
- 扩展Bookie节点。
- 增加Broker节点数量。
最新结果
- 观察：
- Zookeeper的堆内存需求增加。
- Zookeeper磁盘使用量增加。
- Zookeeper的99%分位响应时间增加。
- Broker的堆内存增加。
- 影响：
- 增加Zookeeper的堆内存和CPU资源。
- 监控Zookeeper的磁盘空间和Broker到Zookeeper的延迟。
- 关键指标：
- 呼叫中心的实时通信使用案例的关键指标汇总。
总结
感谢各位同事的支持以及Pulsar社区的帮助。
