我们的交易系统原来用定时任务把 MySQL 数据同步到数据仓库,每 5 分钟跑一次,分析师看到的总是"5 分钟前的旧账"。业务方要实时大屏,等不了。于是用 Kafka 搭了一条 CDC 驱动的实时数据管道,端到端延迟从 5 分钟压到 800 毫秒。 CDC 接入:让数据库自己说变化 定时拉全量太低效
背景:ZooKeeper 又成了单点隐患 七月中我们的 Kafka 集群(3.2 版本,还跑在 ZooKeeper 上)遇到一次 ZK 会话超时,导致整个集群控制器选举卡了 90 秒,消息生产大面积抖动。ZK 那套独立组件既要单独运维、又要和 Kafka 版本对齐,一直是心腹大患。Kafka 3.3
一次奇怪的吞吐量瓶颈 大促前给订单流水 topic 扩分区,从 12 个加到 48 个,本以为吞吐能线性提升,结果生产端 P99 延迟不降反升,监控上看到 broker 端请求队列开始堆积。翻了半天才意识到:分区数过了拐点就是负担,不是越多越猛。 这事其实之前踩过一次。那回我们是 consumer
对账群里跳出一条消息:同一笔订单扣了两次款 2 月 19 号下午,财务在对账时发现一笔订单出现了两次支付成功记录,金额都是 199 元。看起来是消费者把消息重复处理了。 我们用的 Kafka 是 3.1.0,消费者是 enable.auto.commit=true 默认配置。同事问我:不是说 Kaf
现象:每次发版,消费停 47 秒 9 月底做容量复盘时,我发现一个奇怪的规律:每次发布,Kafka 消费 lag 都会先涨后落,中间有大约 45 到 60 秒消费完全停住。看消费者日志,那段时间全是这个: 2021-09-28 14:22:31.407 WARN [Consumer client
财务对账少了 3 笔积分 2 月中旬,财务同学找过来:2 月 10 号这天的积分发放和订单数据对不上,少了 3 笔。 我们链路是:订单服务发 ORDER_PAID 事件到 Kafka,积分服务消费后发积分。查了一圈,积分服务没报错,是消息压根没到。 先看生产者的配置: spring: kafka
扩容前的一次基准压测 2020 年 11 月,订单事件 topic 的日均写入量从 3000 万条涨到 1.1 亿条,运维要我给个扩容方案。我没直接拍板加机器,先用 kafka-producer-perf-test.sh 在现有 3 台 broker 上跑了一轮,想摸清单机的真实上限。 机器配置:1
早上八点,消费积压告警:lag 320 万 6 月 1 号早上八点十几分,钉钉机器人开始刷屏:ORDER_EVENT_TOPIC 的消费 lag 突破 300 万,还在涨。 这个 topic 是订单事件流,下游有 5 个消费者组:风控、数据同步、搜索索引、积分、客服。lag 涨到 320 万意味着这