数据概览
0
粉丝
3
关注
1
获赞
0
被收藏
1
被评论
172
浏览
1
回答
0
被采纳
0.0%
采纳率
4
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
【背景】 最近带团队做消费端扩容，把一个订单事件 topic 从 12 partition 扩到 96。结果很反直觉：吞吐没上去多少（峰值从 3.2 万 msg/s 到 4.1 万，约 28%），但三个副作用同时出现： 1) 消费延迟 P9
答
（无标题）
结论先给：判断"配置化 vs 产品化"最硬的判据不是字段数量，也不是"能不能拖拽"，而是一个工程指标——「新增一个配置项的边际成本是否 ≤ 0.5 人天（含测试）。 如果超过，说明你每加一个字段都在写新逻辑，那本质上就是在"开发"，只是换了
【背景】 我们用 Kafka 3.6（3 broker，topic "order-event" 64 分区）承载订单事件分发链路：消费组 16 实例（每实例 4 分区），日均约 3000 万条，峰值 12000 msg/s。下游是 gRPC
【背景】 我们有一条对账链路：Kafka 3.6（3 节点，topic 12 分区）→ 消费者组 6 实例 → MySQL 8.0（单主+1 从，半同步）。消费逻辑：读消息 → 写 MySQL 对账表（REQUIRES_NEW）→ 调用 s