1. 先说清楚 rea 是什么以及我为什么需要它先交代背景。前一阵我负责某业务线的数据支持工作业务方每隔几分钟就来问一句现在的点击量是多少某个转化环节的成功率怎么样这次活动上线后延迟有没有变高如果按老办法走离线数仓跑一次任务要等 15 分钟以上等我把结果反馈回去运营早就失去了耐心。后来我花了一个周末搭了一套轻量级实时事件分析系统项目名就叫 rea全称是 Real-time Event Analytics。它的核心能力很简单接收事件数据在秒级延迟内做窗口统计并通过 REST API 把结果暴露出去。适合的场景是团队没有专职大数据岗、也不想引入重型组件却需要尽快看到实时指标的情况。1.1 名字背后的需求当“等数仓出表”变成一种痛苦先说痛点。当时我们不是没有数据而是数据到得太晚。业务埋点每天产生大量日志数仓任务会在凌晨把它清洗成报表所以业务方上午看到的其实是前一天的情况。活动当天如果需要实时监控就只能靠人去手工拉日志、反复写临时脚本统计。这个流程的问题很明显脚本逻辑每次都要重写统计口径容易不一致日志量大时分析耗时高线上业务数据库又不能频繁查询怕影响正常服务。一次偶然的机会我看到服务端访问日志就躺在本地文件里于是冒出一个念头能不能在日志产生的同时直接用程序把需要关注的指标算出来rea 的雏形就是这么来的。这其实不是新想法市面上有大量成熟的实时计算平台但大多数对团队规模有要求。我当时所在的组只有两三个人没人能专职维护一套大数据系统数据库资源也非常紧张。所以我对 rea 的定位很明确第一能跑在普通 Linux 服务器上不依赖特殊硬件第二部署成本低最好一份压缩包加一个配置文件就能启动第三保留扩展接口以后如果数据量真的大了可以把数据转接给更专业的处理平台而不是推倒重来。这个定位决定了后面所有技术选型的方向。1.2 为什么没直接上重型组件团队现状决定技术路线可能有人会问为什么不直接用现成的开源方案自己写不是重复造轮子吗我认真比较过。主流的实时链路大体是日志采集器加消息队列加流处理框架加分析型数据库。这套链路能力很强但运维成本也很高需要维护采集器、消费者组、作业状态、集群监控光是“作业挂了自动恢复”这一件事就能耗掉很多精力。对于一个目标是“第二天就能跑起来”的小项目来说确实太重了。rea 的做法是砍掉消息队列和流处理框架只保留最必要的部分接收层直接收 HTTP 事件计算层用有状态的窗口计数器存储层只保存聚合结果和少量明细。整条链路是“事件进、指标出”没有中间环节所以故障点少很多。用我的话说它是用“单机、单进程、少量文件”换来了“十分钟部署、十分钟理解、随时能改”的体验。如果你所在的环境也像我当时一样既要快速响应业务需求又没有人力和资源去维护复杂组件可以认真考虑这类轻量方案。1.3 rea 的边界只解决“从事件发生到看见结果”这十秒的事我还想强调 rea 的边界。它不是一个通用数据处理平台不处理复杂的关联计算不做机器学习特征工程也不承诺无限水平扩展。它解决的是很小但很痛的问题事件发生后能不能在几十秒甚至几秒内看到聚合指标。比如运营想看某一小时的漏斗转化rea 可以给出秒级延迟的窗口统计结果真正精确的离线报表仍然交给数仓在第二天产出。两者并行各干各的。想清楚这层边界非常重要。因为如果一开始就奔着“替代数仓”或“替代流计算平台”去设计方案就会失控。后来我把 rea 的说明写成了一句话秒级窗口聚合10 秒内出结果事件日志完整可追溯。这十几个字基本框定了项目范围后续讨论方案时大家也不会再把不切实际的期望压过来。2. 第一版架构接收、计算、落盘三条线分开rea 的第一版架构非常朴素完全可以画在一张餐巾纸上。整体分三条线事件接入、窗口计算、结果存储与查询。之所以强调“分开”是因为这三个部分的性能特征完全不同接入层要能扛突发流量计算层要保证事件处理顺序与一致性存储层要兼顾写入和查询。如果混在同一个线程里做任何一个环节的抖动都会拖垮整条链路。2.1 事件接入层一个薄的 HTTP 接口就够了接入层我选择提供 HTTP POST 接口而不是自己去对接各种日志采集器。原因很现实业务方已有的埋点系统基本都支持 webhook 回调只要给他们一个 URL他们就能把 JSON 事件 POST 过来。对于一些无法改代码的老系统我又加了一个文件采集通道直接 tail 指定日志文件按行解析成事件。两个通道最终进入同一个内存队列这样后续处理逻辑只有一份避免维护两套代码。接入层讲究一个“薄”字。收到事件后只做两件事解析 JSON 并校验基本字段然后放入内存队列立即返回 200。落盘和计算都不在这个路径里做所以请求耗时稳定在毫秒级。一个典型的事件 JSON 大概长这样{ event: click, user_id: u123, item_id: i456, ts: 1730000000000, props: { channel: app, page: home } }有人担心内存队列会不会丢数据我的处理顺序是先追加写入原始事件日志再返回 ACK。也就是先落盘、后确认。这样虽然损失了一点吞吐但换来的是“已确认的事件一定留下了痕迹”。如果系统崩溃恢复后可以从这个原始日志重新解析不丢不重。对于事件类数据这条原则值得写进任何实时项目的设计文档。2.2 计算核心窗口计数器不复杂复杂的是组织方式计算核心其实没有用什么框架本质就是若干张哈希表key 由窗口时间、维度组合和指标名拼接而成value 是一个计数器。事件进来时先提取业务时间戳按窗口大小取整得到窗口 ID然后把需要累加的维度组合 key 找出来计数加一。这里强调“按业务时间戳”而不是按事件进入系统的时间因为网络延迟和批量重放都会让到达时间失真这一点后面会专门展开。组织方式上我维护了三层结构当前活跃窗口、近端已结束窗口、冷窗口。当前活跃窗口常驻内存更新最快窗口结束后进入近端已结束窗口保留一段时间供迟到事件修正最终刷盘后就进入冷窗口只从磁盘读取。这套结构和常见的 Lambda 架构有些相似但没有那么重核心思想是“热点数据在内存冷数据在文件”。2.3 存储层选型SQLite 为什么赢了结果存储我对比过 SQLite、LevelDB、RocksDB 和 ClickHouse。ClickHouse 很好但对当时的我来说部署和调优成本偏高LevelDB 和 RocksDB 性能出色但使用上要自己处理很多细节。最后我选了 SQLite原因是稳定性足够、事务模型清楚而且以文件形式存在备份非常方便。考虑到 rea 保存的是预聚合结果写入频率并不高每 10 秒左右批量写一次SQLite 完全够用。当然 SQLite 也有自己的脾气。默认模式下一个进程同时写和读时写锁可能阻塞读操作导致查询毛刺。我的解决办法有两个一是所有写入走同一个串行化写通道避免并发写二是开启 WAL 模式让读不阻塞写。实际运行下来分钟级查询的 P99 延迟稳定在 150 毫秒以内。如果你也要用 SQLite 存类似的结果数据建议先了解它的三种日志模式再决定是否开启 WAL。2.4 项目跑通后的目录结构整个项目跑通后目录结构非常清爽rea/ bin/ rea-server # 主程序 conf/ rea.toml # 配置文件 data/ logs/ # 原始事件日志 db/ # SQLite 文件核心程序负责接收、计算和查询数据目录下有两个子目录一个存原始事件日志一个存 SQLite 结果文件。没有外部依赖没有数据库账号没有环境变量迷宫。部署一台新机器基本就是解开压缩包、改一改配置里的监听端口和窗口大小然后启动进程。为什么要强调目录结构因为之前我见过太多项目代码写得不错部署时却要跟着文档配半天环境。rea 把依赖收敛到“一个进程、一个数据目录”大大降低了使用门槛。这也是它能在小团队里活下来的原因之一人少事多时一个能被新手在半小时内看懂的系统的价值远高于功能列表的长度。3. 窗口计算里的三个容易翻车的边界问题窗口计算看起来只是“取整、计数”实际上细节非常多。我在联调和压测阶段反复踩坑后总结出三个最容易翻车的地方事件时间归属、迟到事件处理、维度组合导致的内存膨胀。这三个问题如果不提前设计上线后会以各种诡异的方式冒出来。3.1 事件必须按业务时间归窗口而不是按到达时间先说时间归属。假设用户在北京时间 14:00:03 点击了一个按钮但因为网络抖动这条事件直到 14:01:20 才送到 rea。如果按到达时间归入 14:01 的窗口那么这 17 秒的延迟就凭空制造了一个错误的计数。短期看误差不大但在高峰时段大量延迟事件会导致窗口数据此消彼长最终和离线统计完全对不上。正确的做法是每个事件必须带业务时间戳 ts计算窗口 ID 时用 ts 取整。以分钟窗口为例窗口 ID 可以简单算成 ts 减去 ts 对 60000 的余数。这样无论事件晚到多少秒只要还在允许迟到范围内它都会回到正确的窗口。与此同时我会额外记录到达时间字段 arrive_ts用来监控端到端延迟。这些延迟数据可以帮助业务方判断自己的上报链路是否健康而不只是给一个最终结果。3.2 迟到事件的处理策略等待窗口加修正通道既然按业务时间归窗口迟到的旧事件就可能出现在新窗口里。比如 14:00 窗口已经结束并刷盘14:05 又来了一条 ts 为 14:00:59 的事件。直接丢弃会让结果偏低等待太久又会让查询延迟变大。我设定的策略是每个窗口在结束后继续保留 5 分钟供迟到事件修正超过 5 分钟的事件仍然写日志但不再修改在线结果统一进入一个“修正结果表”离线对账时参考。实现修正通道时我维护了一个“待修正窗口集合”。如果一个新事件命中了已经结束但仍在修正期内的窗口就把该窗口重新标记为 dirty并把事件计入内存副本。每 30 秒检查一次 dirty 窗口把更新后的计数合并到 SQLite 结果里。这样既保证了绝大多数迟到事件被正确计入又不会无限期等待。对大多数业务来说5 分钟已经是很宽裕的延迟容忍度了。3.3 维度爆炸内存里能装下多少个计数器窗口计数器的内存消耗容易被低估。一个事件往往带有多个维度比如渠道、页面、用户等级每个维度又有若干取值多维组合后的 key 数量是乘积关系。我做过一次估算1 个小时窗口3 个维度各有 100 个取值组合最多就是 100 万组。如果再算上指标数量内存占用会明显上升。rea 默认只保留最近若干小时窗口的活跃数据每批聚合完成后允许旧窗口被回收从而控制内存稳定。针对需要在用户维度做统计的场景我不会把所有用户都放内存而是维护一个 TopN 采样结构。比如只保留访问量最高的 1 万个用户其余用户统一累加到一个“其他”聚合项。这个策略在大多数场景下完全够用又能把内存增长从 O(用户数) 摊平到 O(固定值)。如果你想快速估算自己的场景可以按这个公式大致算key 数等于并发窗口数乘以维度取值数量乘积再乘以指标数单个 key 的计数器和时间信息加起来大约 100 字节左右。3.4 多窗口聚合与跨天切分的具体实现窗口不只是分钟这一种。rea 里同时存在分钟窗、小时窗、日窗。我没有为每种窗口单独写一套逻辑而是抽象了一个“窗口套窗口”的机制分钟窗是基础单元小时窗和日窗通过分钟窗结果再聚合得到。这样做的好处是基础数据只有一份减少重复计算坏处是小时窗和日窗的结果天然带一些修正延迟因为要等分钟窗修正完毕。跨天切分的问题容易被忽略。业务日通常按自然日 00:00 到 24:00 算但如果系统时区不是业务时区切分点就会偏移。我在 rea 里把所有时间戳都存成 UTC 毫秒窗口 ID 也按 UTC 计算只在对外提供查询时转换时区。这样服务器时区怎么变底层数据口径都不受影响。早期版本在这个问题上吃过亏凌晨的统计总和对不上后来统一成 UTC 存储才彻底解决。4. 部署压测阶段踩过的四个实实在在的坑真实环境永远比 Demo 残酷。rea 从“能跑”到“稳定跑”中间经历了几个让人头疼的问题崩溃恢复导致重复计数、流量尖峰打满接入层、SQLite 写入卡顿、时区错乱。逐个说下原因和解决思路这些经验比功能代码本身更有复用价值。4.1 崩溃恢复时日志重放导致计数翻倍第一次长时间压测时我故意 kill 进程模拟崩溃重启后发现某个窗口的计数明显翻倍。查了半天才想到原因原始事件日志是追加写的程序启动时会自动扫描堆积的日志把未处理的事件重新加载。但崩溃前已经处理过的事件还可能滞留在内存队列里启动后再次被扫描到于是同一批事件被处理了两次。修复方式分两层。第一层是在原始事件日志里记录每个事件的解析状态和对应文件偏移量启动时从上次记录的偏移量继续读避免整文件重扫。第二层是为每个事件生成一个内容哈希聚合时按“窗口加事件哈希”做去重表只在修正通道和启动恢复时启用。这样做之后多次 kill 重启都不会再出现翻倍。实时系统中的“至多一次”和“至少一次”很容易搞混我的建议是宁可接受重复、也要用去重兜底因为这样能保证计数结果单调可信。4.2 流量尖峰把 HTTP 接收层打满某次压测模拟活动流量QPS 从平时的 50 突然涨到 2000接入线程池很快被占满大量请求超时。当时我意识到实时系统的第一个瓶颈往往不在计算而在接入。针对这个问题我把接入层改成“只收不办”的模式HTTP 请求线程只负责解析和入队然后立刻返回真正的计算由独立的处理线程池消费队列。两者解耦后即使计算暂时跟不上请求线程也能快速响应压力被内存队列缓冲掉。队列本身也不是无限的。我给它设了一个最大深度比如 50 万条超过后新事件直接返回 503。业务方收到 503 后可以做本地重试压力会自然回弹而不是压垮系统。同时我特意保留了一个小容量的紧急通道不受限流影响用来接收极少数关键告警事件。这类应急设计平时用不上但真出事时它是最后一根救命稻草。4.3 SQLite 写锁引发的“写 10 秒卡 3 秒”问题用 SQLite 存聚合结果后查询接口偶尔会出现 3 秒左右的毛刺。一开始以为是查询太复杂后来发现是批量写入触发 checkpoint 时写进程和读进程产生了锁竞争。SQLite 的 WAL 模式本身允许读写并发但 checkpoint 在特定条件下还是会阻塞写尤其是磁盘 IO 比较慢的机器上。我的调整是把 checkpoint 改成手动触发放在低峰时段执行同时查询走单独的只读连接避免与写连接共享同一份连接池状态。改动后用压力脚本复测P99 从 3 秒降回 150 毫秒左右。这件事给我的教训是选型时不仅要看“默认配置”的表现更要看“极端情况”下的表现。SQLite 本身没错错的是我之前没有关心日志模式细节。4.4 时区不统一跨天统计对不上账最后一个坑最有欺骗性。某个服务部署在 UTC 时区的机器上rea 却默认按服务器本地时间计算窗口导致每天对账时总会差出几百条数据。找问题时我一度怀疑是去重逻辑出错最后打印出原始事件的时间戳和窗口 ID 才恍然大悟窗口切分点整体偏移了 8 个小时。修复方式是统一使用 UTC 时间戳计算窗口 ID查询时再由前端把时间标签转换成业务时区。我还额外加了一个展示时区配置项告诉前端和业务方“UTC 存储、本地展示”的口径。之后跨天统计就稳定了。如果你也要写类似的窗口系统建议从第一天就把时区问题写进设计文档而不是留到对账时再补救。5. 验证与交付我怎么让业务方放心使用这套结果光有系统不够还得证明结果可信。我从两个维度做验证压测看性能是否达标和离线数仓对账看数据是否准确。这两个维度缺一个业务方都不会真正放心把实时数字用于运营决策。5.1 三组压测数据从常规流量到突发流量我压测时选取了三组场景。第一组是 100 QPS 持续 10 分钟观察稳定运行时的内存和磁盘走势第二组是 1000 QPS 持续 30 分钟模拟活动期间的正常流量第三组是瞬间把流量从 300 QPS 拉到 1500 QPS 并保持 1 分钟再降回 300模拟流量尖峰。每组压测都重点记录 P99 延迟、内存增长率、请求失败率这三个指标。结果还算理想1000 QPS 持续运行时P99 延迟大约 200 毫秒内存占用稳定在 800MB 左右没有出现明显波动尖峰场景下接入线程池短暂排队但 503 率控制在 2% 以内计算线程池没有积压过多。这里要补充一句压测环境是 4 核 8GB 的普通虚机如果你的配置更高或更低数字会相应变化。重要的是通过压测找到系统的软肋而不是追求一个绝对指标。5.2 和离线数仓的对账方法误差要可解释数据准确性验证上我采用的方法是同时段对比让 rea 的分钟级聚合结果按小时汇总和数仓当天产出的小时级报表做差值对比。对账窗口设在凌晨因为此时线上流量低网络抖动对两端数据的影响最小。连续跑了几天分钟级结果汇总后与数仓的误差率可以控制在 0.5% 以内差异主要来自迟到超过修正期的事件和 503 重试造成的个别丢失。对账的关键不是数值绝对相等而是误差可解释。我会把每一笔差异都归因到具体原因这条缺了 3 条是因为超过了 5 分钟迟到窗口那条多了 2 条是因为离线任务去重逻辑与 rea 不一致。当差异都能解释清楚业务方才愿意接受这套实时数字。否则任何“基本一致”的说辞都很难让人信服。5.3 沉淀出的配置模板与参数建议经过多轮调整我把 rea 的关键参数沉淀成一份模板新环境部署时直接复制修改即可。下面是我个人比较推荐的一组初始值配置项推荐值说明窗口大小1 分钟基础窗口小时窗和日窗由它聚合迟到等待时间5 分钟窗口结束后保留供修正的时间修正刷盘间隔30 秒触发修正结果合并的频率内存队列深度50 万条超过后对新事件返回 503结果批量写入间隔10 秒聚合结果落盘周期SQLite 日志模式WAL避免读写互斥checkpoint 时机手动触发放在低峰时段执行这组参数适合单机处理每秒数百到几千事件的场景。如果事件量更大我不会急着调优单机参数而是考虑加一台机器让接入层做简单路由或者干脆把原始日志转发给更完整的流处理平台。rea 的定位始终是“够用就好”当需求超过这个定位时升级架构才是更理性的选择。最后再分享一点我的个人体会项目走到这里我最想说的不是技术细节而是一个朴素的判断实时系统的价值不在于技术多炫而在于它能不能在你需要的时候给出可信的数字。rea 这套东西没有引入任何重量级组件代码量也不大但它把事件接收、窗口计算、结果存储这几件事的边界理清了把迟到事件、去重、时区这类细节处理好了所以它在实际使用中一直很稳。如果你也要做一个类似的轻量实时分析工具建议从最小闭环开始先把一条业务线的指标跑通再去想扩展。最后提醒一句任何实时系统都要有对账手段否则没人敢真信你的数字。以上是我在模拟项目 rea 上走完整个流程后最想分享的经验。