从项目代号rea到实时事件分析系统：需求挖掘与架构落地全记录

我最近接手一个内部项目时能看到的全部信息只有立项时留下的三个字母rea。项目正文是空的关键词是空的摘要描述也是空的相关热搜词、网络热词一概没有。换句话说这个项目在我这里就是一道只有答案没有题面的填空题。真实开发里“只有一个代号”的情况远比想象中多某个模块做到一半换了负责人、某个临时方案慢慢长成了核心系统、某个Demo被周围服务依赖后又没人写过文档。如果你也正对着一个名字发愁这篇文章会告诉你我是怎么拿“rea”这三个字母一步步还原出需求边界、技术选型、最小实现、落地踩坑和知识沉淀的。需要说明的是这里的“rea”只是内部演示项目的代称不代表任何真实系统。我把它最终收敛为“Realtime Event Analytics实时事件分析模块”——一个接收操作事件流、输出实时指标和告警的小系统。这个判断不是猜出来的是靠一轮一轮问话问出来的。整个过程完全可以复现下面拆开讲。1. 项目代号rea从三个字母开始的需求边界重构拿到一个只有代号的项目第一反应通常是上网搜或者把缩写全称猜一圈。我试过REA可以对应很多词Real Estate Agent、Regulatory Economic Analysis、Rapid Environment Assessment。每一个看起来都合理每一个都跟我们这摊事没关系。所以这里有一个很重要的经验缩写猜谜永远不是起点起点是把项目周围关键人物的脑子都掏干净。1.1 为什么先别急着打开代码仓库看代码很多人拿到空项目后会急着找代码仓库。如果仓库有旧代码还好歹有个抓手如果仓库是空的就更不知道干什么了。我的建议是先别碰代码先做一场带具体问题的访谈。这里的道理很简单代码是一个项目“已经怎么做”的产物而你缺少的恰恰是它“为什么这么做”。一个只留代号的项目往往连“已经做”都未必靠谱——很可能上一任为了赶工搭了个临时方案下一任要是照着临时方案的思路继续后面全是债。我会找三类人问话提需求的人这个系统给谁用输入是什么输出是什么哪些场景绝对不能丢之前碰过代码的人当时先做了什么、放弃了什么、卡在哪里下游对接的人谁在等rea的结果他们拿这些结果干什么在rea这个例子里访谈得到的关键信息是某业务团队手中有一批用户操作事件流每天几千万条他们想实时看到“某种操作类型每分钟发生了多少次、成功率和异常率是多少”并且希望在某些指标超过阈值时能立刻提醒。再往下挖他们还希望保留原始事件出了问题能回查。到这里rea的轮廓已经不再是三个字母而是一个清晰的实时事件分析模块。1.2 rea的三种合理猜想与实践收敛面对rea我列了三种最有可能的含义然后拿访谈到的信息去筛选。这个过程我建议你遇到类似项目时也做一遍用表格把不确定变成可以否决的判断。候选含义数据特征交付物与访谈信息是否吻合Realtime Event Analytics持续到达的事件流实时指标、告警、明细查询高度吻合来访者反复强调“实时”“事件”“统计”Resource Estimation Agent资源使用历史数据、配额信息容量评估报告、预测曲线部分吻合但没人提到“预测成本”或“资源配额”需求Refactor Execution Assistant代码仓库、依赖关系重构计划、变更风险清单完全不吻合没有任何重构目标也没有人说“这块代码坏到要重写了”通过这种否决法rea几乎没有任何悬念地收敛为Realtime Event Analytics。这个收敛动作本身就有价值我不是拍脑袋确定“它就是个实时分析”而是让所有相关方看到为什么另外两个解释被排除。后面对话时大家说的都是同一件事没有人再为“rea到底代表什么”争论。2. 链路选型rea最终采用“队列流计算冷热存储”的组合rea的核心是事件分析所以整个链路天然分成四段事件接入、消息缓冲、流式处理、结果存储。最终我们采用的是“轻量队列 流处理引擎 三层存储”的组合。这个组合没有用任何炫技的组件但足够稳定也足够解释给新成员听。2.1 采集层轻量队列与直写存储的取舍最直接的方案是客户端把事件POST到后端接口后端直接写数据库。曾经某个内部系统就是这个风格前面三个月的确能用流量起来之后问题全来了突然的流量尖峰把数据库打满、业务侧提出要加字段时数据库改表要半天、上游服务重试时同一事件被写了两遍。rea如果继续直写等于把这些坑原样再踩一遍。所以rea在接入之后放了一个轻量队列。它的作用有三个削峰填谷写入方不管下游能不能吞下先把事件落进队列消费方按自己的速度拉取。哪怕瞬间来了十倍流量也只是队列积压不会打垮数据库。事件重放出了乱子比如流计算程序上线失败队列里的数据还能从某个offset重新消费不用让上游重发。结构解耦上游只管生产事件下游只关心队列里的topic双方不需要知道对方的表结构。选型对比也很直白方案优点缺点适配情况直写数据库链路最短、实现最快峰值易击穿、结构难变、无法重放每天几百条内部日志的简易工具轻量消息队列缓冲、重放、解耦多一个组件需要运维每天千万级事件、下游多个消费方的生产系统这里有个容易被忽略的点队列不是越重越好。我们有真实案例某个团队为了“一步到位”上了带强事务能力的企业级消息中间件结果配置复杂到没人敢动。rea选择了单节点就能跑起来的轻量队列把所有默认参数暴露在配置文件里。从小规模起步流量增长后再加副本和分区这是最务实的选择。2.2 分析层窗口计算与状态管理的取舍队列后面的流处理引擎主要解决两件事算窗口和管状态。窗口计算解决的是“每分钟成功率”这类带时间维度的问题。按小时和按分钟跑批是完全两种玩法按分钟跑批意味着每次都要与上一批数据对齐而流处理可以按事件时间自动切窗数据迟到后还能通过Watermark机制去容忍一小段时间。状态管理则更隐蔽。实时指标的背后通常是多维度计数某个用户在一个小时内操作了多少次、某个错误码在全网维度下出现了多少次。这类计数需要平台帮我们维护每个key的当前值。我们做了一个关键取舍聚合状态尽量只放中间结果不放原始明细。举个例子计算“每分钟各事件类型的计数”状态里只需要维护每个事件类型在当前窗口的计数器而不是把所有事件原样堆在内存里。曾经有人为了图方便把窗口内所有事件ID都塞进状态数据量一大内存直接爆了这种坑不该再踩。并发度的设置也来自这个取舍。我们的经验是并发度不用一开始就拉满先用默认并行度跑通链路再用“单分区事件积压量”这个指标去判断是不是该加资源。不要拍脑袋从1调到16这种调节经常因为连接数暴增而引入新的瓶颈。2.3 存储层实时指标不能只依赖关系库很多人听到“存储”第一反应是上MySQL。但rea这种场景关系库单独扛不住。原因有两个一是关系库擅长的是低并发下的点查和强一致不擅长高并发批量写入二是实时指标天然是时间序列按时间范围扫描和聚合才是高频操作。我们最终把存储拆成了三层实时指标层用内存数据库/列式存储保存最近几分钟或几小时的聚合结果供大屏和Dashboard低延迟查询。明细查询层用列式存储保存带事件时间、用户标识、事件类型等字段的明细数据支持排错时按条件回查。归档层原始事件完整落进对象存储按天分目录只在需要深度回溯时使用。这个设计本质上就是冷热分离越热的数据越贵越快越冷的数据越便宜越慢。预算有限的时候可以先把指标层和明细层做出来归档层用最简单的文件目录加索引服务代替。不必一开始就上重型大数据仓库。3. 最小可跑链路从一条日志到一张指标表的完整实现再好的架构要落到能跑的程序上才算数。rea的第一步目标不是完美而是让一条假事件流进去一分钟之后在输出端看到一张带着正确聚合结果的指标表。这条最小链路我们只做了三件事规范化输入、写窗口聚合、端到端验证。3.1 输入规范化与事件时间处理真实事件流的格式永远比你想的乱。有的埋点用snake_case有的用camelCase有的时间戳是毫秒有的是秒有的带时区有的不带。rea在入口处做的第一件事就是统一格式。一条典型的原始事件大概是这样的{ user_id: u_10231, event_type: click_pay, event_time: 2025-01-10 14:23:18.123, ts_ms: 1736504598123, platform: android, detail: { page: order_confirm, amount: 99.0 } }我们把它统一成内部规范事件{ uid: u_10231, event: click_pay, et: 1736504598123, plat: android, page: order_confirm, amount: 99.0 }这里最重要的字段是et即事件实际发生的毫秒时间戳也就是事件时间。为什么要较真这个因为实时计算里“按到达时间算”和“按发生时间算”区别巨大。如果消费者短暂阻塞晚到达的事件会涌入下一个窗口导致指标看起来发生了偏移。rea所有窗口都基于事件时间切分同时设置Watermark来容忍一定延迟。这个细节在你手动测试时很难暴露但线上一定会遇到。3.2 用一段代码把窗口聚合讲清楚我们采用的是支持流式处理的引擎但概念和代码完全可以抽出来给大家看。核心逻辑是按事件时间对齐到60秒窗口统计每个事件类型出现的次数最后把窗口结果写入输出表。用Flink SQL表达非常直观-- 输入表从消息队列读取事件 CREATE TABLE event_source ( event STRING, et BIGINT, uid STRING, ts_ltz AS TO_TIMESTAMP_LTZ(et, 3), WATERMARK FOR ts_ltz AS ts_ltz - INTERVAL 5 SECOND ) WITH ( connector kafka, topic rea.event, properties.bootstrap.servers localhost:9092, format json ); -- 输出表写入明细查询层 CREATE TABLE event_metrics ( win_start TIMESTAMP(3), event STRING, cnt BIGINT, PRIMARY KEY (win_start, event) NOT ENFORCED ) WITH ( connector jdbc, url jdbc:clickhouse://localhost:8123/rea, table-name event_metrics ); INSERT INTO event_metrics SELECT TUMBLE_START(ts_ltz, INTERVAL 60 SECONDS) AS win_start, event, COUNT(*) AS cnt FROM event_source GROUP BY TUMBLE(ts_ltz, INTERVAL 60 SECONDS), event;这段代码有几个细节值得解释。WATERMARK FOR ts_ltz AS ts_ltz - INTERVAL 5 SECOND表示允许事件最多迟到5秒超过5秒还到的数据不参与窗口计算。这个数字不是随手写的它来自上游链路实测99%的事件在3秒内到达所以5秒是个有余量的选择。窗口大小60秒则是业务方直接提出的他们盯的是分钟级指标过小会显得抖动太大过大会掩盖瞬时异常。输出表主键定为(win_start, event)非常重要。它是幂等写入的前提同一个窗口、同一个事件类型的结果重复写入时数据库能通过主键覆盖而不是追加多条。这个设计直接规避了一个大坑流任务失败重启后重复写入导致指标翻倍。3.3 端到端验证步骤与预期结果写完代码不算完rea跑通的最小验证循环是这样的启动本地队列和流计算环境。向队列写入一批固定顺序和固定时间的模拟事件比如在et1736504598000到et1736504598999之间均匀放入500条login事件。等一分钟查询输出表预期得到一行记录win_start对应那分钟的开始时间eventlogincnt500。再写入100条et时间落在上一分钟但延迟到达的事件确认它们不会污染当前窗口也不会把上一窗口的计数无限拉高。这个验证脚本我们保留成了仓库里的自动化测试。以后任何人动了时间字段解析或窗口参数跑一遍就知道有没有把老逻辑弄坏。测试实时任务最怕的就是“看起来有输出”如果连一行确定的输出和一条迟到数据的行为都验证不了后面的优化都是空中楼阁。4. 落地过程中的三个真实坑乱序、背压与容量估算章节标题里的三个问题几乎每个实时事件分析项目都会遇到。我把踩坑过程完整写出来不是给答案而是让你知道答案是怎么一步步试出来的。4.1 乱序事件导致重复计数水印、幂等、去重rea上线后第一次报警是计数对不上。业务方反馈某个操作类型的分钟计数比实际值高了大约2%而且高出来的量很有规律每隔一段时间就冒一次。直觉告诉我这不是数据源在造假而是处理链路把同一批事件算重了。排查之后原因有三层第一层事件乱序。下游消费者处理速度波动时事件到达顺序会跟发生顺序不一致。一些本来属于上一分钟窗口的事件在关闭窗口后才被拿到于是被算到了下一分钟。第二层任务重启。流任务发布或者异常重启时source端为了不丢数据会从保存的offset继续消费。如果sink写结果的动作不是幂等的同一批事件就会被重复写入。第三层延迟数据补偿机制。我们曾经尝试让迟到事件“重新触发”对应的老窗口重算结果watermark没调好老窗口被重算了两次。解决办法是一套组合拳Watermark再放宽了一点从5秒调到8秒让绝大多数乱序事件能落回正确的窗口sink写入改成带主键的幂等写入窗口的重复计算结果直接覆盖掉旧值关闭早期触发机制不再让窗口结果在被关闭后反复更新。改完之后计数误差立刻回到可接受范围。核心教训是实时计算的正确性不是某一个组件保证的而是水印、幂等写入、窗口触发策略三者凑齐才保证的少一个都会在某个流量时辰给你颜色看。4.2 背压传递到数据库连接池参数调整实测第二个坑出现在流量高峰期。现象是流处理引擎的任务图里source端积压的记录数暴涨sink端却显示高延迟。看监控面板数据库的连接池已经满到没有空闲连接所有写入请求都在排队。这就是典型的背压传递数据库写入跟不上sink算子成了全链路的瓶颈数据库的慢身为源头消费者越积越多最终把整个链路拖慢。排查时我们一度怀疑是数据库规格不够加了内存和CPU结果毫无变化。后来打印sink算子的线程堆栈才发现每次Flush都会等待数据库连接池分配连接。连接池本身只有20个连接而sink算子的并行度是8冲进来时大家都在抢连接。最终调整是三层各退一步写入方式从单条写入改成批量写入攒够1000条或等待1秒再一次性提交连接池上限从20调整到40同时数据库侧增加一点请求排队限制防止无限连接把数据库拖垮流处理算子把并行度从8降到4减少对连接池的并发争抢。有意思的是并行度降下来之后总体吞吐反而上去了因为每个任务分到的资源更充足批量写入的批次更大。这个结果让我更相信一个判断调优不是把所有数字调大而是找到那个让系统各部分刚好匹配的点。4.3 生产容量估算用小流量推全量资源需求第三个坑不是事故是早期的拍脑袋。最初我们给rea分配资源时负责人问“需要多少核多少内存”我给了一个“感觉够用”的数字。上线前做压测才发现这个数字在生产峰值流量下连一半都撑不住。后来我们整理了计算公式每次扩容都按这个公式来单秒事件量 接口峰值QPS × 单事件平均字节数单秒写入带宽 单秒事件量 × 平均每条序列化后大小 × 冗余系数(通常1.2)窗口状态内存 状态key数量 × 每key状态大小 × 冗余系数举个具体例子假设当前rax要接入的接口峰值QPS是5000单事件序列化后约400字节那么单秒事件量就是5000条写入带宽约5000×400×1.2≈2.4MB/s。这看起来不大但如果窗口是15分钟且需要按用户维度维护登录状态状态key数量可能是500万每个key状态1KB那就需要5GB以上内存。如果只盯着带宽而忽略状态内存最后就会在某个高峰期内存溢出一阵。容量估算的核心不是算得精而是把每一项资源的依据写出来。就算估算错也能知道偏差在哪里下一次能修正。没有任何依据的“感觉够用”是最危险的。5. 代号型项目的知识沉淀术语表、ADR与一键复现rea这种项目最遗憾的结局是做出来了、上线了、半年后没人知道它为什么要这样设计。为了不让项目重新变成另一个没人看得懂的代号我们提前做了三件事术语表、ADR架构决策记录和一键复现脚本。5.1 用ADR记录关键决策避免后来人重复踩坑ADR听起来很正式其实就是一个简短的Markdown文件记录一次技术决策的前因后果。我看到的许多内部项目根本没有这种东西。有人依赖口头沟通三个月后人走了记忆也没了有人只在代码注释里写“不要改这里”但从不解释为什么。rea的ADR模板很轻总共五段# 决策事件存储采用三层冷热分离 ## 背景 实时指标需要聚合查询明细需要按条件回查原始事件需要长期归档。 ## 被否决的方案 - 只用 MySQL高并发写入扛不住时间范围聚合成本高。 - 只用列式存储实时指标查询延迟不够低且成本高。 ## 最终决策 实时指标层用内存数据库/列式存储明细层用列式存储原始事件归档对象存储。 ## 影响 写入链路多了一次分发小流量阶段可以只保留前两层。 ## 备注 如果未来指标查询并发超过现有预期优先增强指标层而不是把明细层改成热点库。写这份文档平均只要十几分钟但它省掉的是后来人重新“为什么不用MySQL”的半天争论。在我们团队里“没有ADR就改关键设计”会被视为不合规这个习惯比任何代码规范都对项目寿命有利。5.2 本地Demo启动步骤和自检命令清单最后一个方法是把“能跑通”变成一种人人都能获得的确定性。我们写了一份一键启动脚本把队列、流计算任务、输出表全部用Docker Compose拉起。再给新人一张自检命令清单。# 1. 启动本地依赖队列、数据库、演示任务 make up # 2. 写入一批模拟事件脚本内部按1分钟窗口构造500条login事件 make seed # 3. 查看输出指标 make query # 4. 观察任务健康状态水位是否推进、积压是否下降 make health自检清单长这样检查项预期结果异常处理队列consumer lag持续下降到0八成是sink写太慢检查批量写参数Watermark是否持续推进与当前时间差在5秒内检查source分区数和并行度匹配指标表行数每分钟一个窗口、每事件类型一行主键重复导致覆盖或漏写明细回查延迟秒级确认列式存储分区裁剪生效做完这三件事我第一次觉得“rea”不是一个残留的符号而是一个有血有肉、有历史、有决策记录的项目。最后分享一个自己摸索出来的体会代号越短、资料越少的项目越需要把“为什么”写下来。rea这三个字母本身毫无意义意义在于当你走到半年后回看当初每个选择时还能说得清它是怎么被确定下来、怎么被否决掉的。如果你手里也有一个只留下一串字符的空项目不要急着猜全称先找人谈需求边界你选的每一步都要留一行字说明理由同时让最小可跑链路尽量早地跑通因为完美的架构图永远不会自己产生反馈。沿着这个思路走下去任何空项目都能变成一篇让人看得明白的技术记录。