rea规则引擎：事件驱动的轻量级文件处理自动化

你可能在某个技术群里看到有人发了个词：“rea”。没头没尾，三个字母，有人说是“正则”的简写，有人说是某个内部项目代号，也有人直接把它当成一个命令去查了一圈，结果什么都没找到。说实话，我第一次见到这个词的时候也愣了一下，后来才反应过来，这是一个相当有代表性的命名习惯——用三个字母去概括一个工具的核心理念，看起来随意，但背后往往藏着完整的设计逻辑。这篇文章我就用自己的实际折腾经历，把这个“rea”拆开揉碎讲一讲，包括它到底是什么、能解决什么问题、怎么上手、以及我在过程中踩过哪些坑。如果你正准备做一个轻量级自动化工具或者批处理脚本，这篇文章应该能给你不少实在的参考。

1. 项目概述与核心需求拆解

1.1 一句话搞清楚“rea”是什么

先说结论，按我的理解，rea指的是一个基于“规则表达式匹配 + 事件驱动回调”的轻量级文件处理引擎。它的目标非常朴素：当你有一堆文件（日志、配置、文本、表格导出），需要按规则做重命名、分类、内容替换、告警触发等操作时，不用写一堆if-else和循环遍历，只要写几条规则，把“文件长什么样”和“要做什么动作”分开描述，剩下的交给rea去执行。

这个名字本身取自三个英文单词的首字母，也即：

• R：Rule / 规则
• E：Event / 事件
• A：Action / 动作

所以rea的完整含义，简单说就是“规则—事件—动作”三层结构。

1.2 开发背景：这类工具到底在解决什么痛点

我自己当时为什么会去弄这么个东西，是因为有一段时间被一批日志文件折磨到不行。情况大概是这样：某个运行环境每天会在固定目录下生成几十个日志文件，文件名带时间戳，但格式偶尔会变，今天可能是app-20250121.log，明天可能就是app_2025_01_21.log，还时不时混进几个.log.1、.log.2这种轮转出来的旧文件。我要做的事情其实不复杂：按天归档、按大小筛选、超过阈值的压缩、超过保留周期的删除。

就这么个需求，用脚本来写倒也写得出来，但问题在于规则很容易改。今天要加一个“凡是在晚上十点以后生成的日志都要立刻发告警”，明天要改成“文件名里包含error的不要压缩”，每次改需求我都要拧着眉头去找那一大段处理文件名的正则，反复调试，相当痛苦。

rea这类工具想解决的，说到底就是“把策略和实现分开”这件事。

1.3 适用场景与目标人群

我后来慢慢发现，rea其实并不只是给我一个人用的，它适合的人群还挺宽：

• 如果你经常和服务器日志、批量导出文件打交道，需要自动化归档和清理；
• 如果你在维护一套数据管道，源文件、结果文件散落在不同目录，需要做定时整理；
• 如果你是一个脚本爱好者，想用一个更“声明式”的写法来管理你的文件处理任务；
• 甚至你只是写个小工具，希望用户填个规则就能自动处理指定类型的文件，不需要为每种情况单独写逻辑。

这些场景都有一个共同点：数据处理规则变化频繁，但处理的“动作”本身比较固定。在这种场景下，把规则和动作拆开，让规则本身变成一份独立的配置，维护成本会下降很多。

2. 整体方案设计与运行机制

2.1 为什么选择“规则驱动”而不是“脚本驱动”

这个问题我在设计初期纠结过很久。既然能用Python、Shell写脚本，为什么还要抽象一个规则引擎出来？答案是：脚本适合做一次性的事，规则引擎适合做反复要做的事。

这么说可能有点抽象，我给你打个比方。脚本就像你直接跟理发师说“左边推平、右边剪短、后面修圆”，理发师听懂了，直接上手。但如果这家店每天要接待几百个客人，每个客人进来都有类似但稍有不同的要求，理发师不可能每次都重新理解一遍。这时候就需要一个“预约卡”：上面写了顾客编号、发型代码、注意事项，理发师只管按卡执行。rea就是那张预约卡，只不过服务对象是文件。

所以rea的核心设计理念，就是让我可以把所有文件处理需求归纳成一组规则：

• 匹配什么特征的文件；
• 在什么时机进行匹配；
• 命中了之后做什么动作。

这三者分离，每个维度都可以独立修改，互不干扰。

2.2 三层结构：规则、事件、动作的具体含义

在rea里，这三层各自承担不同的职责，我一个个说。

规则（Rule）：定义“对哪些文件感兴趣”。这个维度通常包括文件路径的匹配模式、文件扩展名、文件名中的关键字、文件大小范围、修改时间范围等。规则一般是一段表达式，可以简单也可以复杂。比如说：

• 路径包含 /logs/ 且扩展名为 .log 且大小 > 10MB
• 文件名匹配 ^app-\\d{8}\\.log$ 且修改时间在最近24小时内

事件（Event）：定义“什么时候触发”。比较常见的是文件被创建、被修改、被移动、被删除，也可以是一个时间点事件（比如每天凌晨两点扫描一次目录）。rea会监听或者定期扫描这些事件，当它发现某个文件的变化符合某条规则时，就进入下一步。

动作（Action）：定义“匹配之后做什么”。这是最灵活的部分，常见动作包括：移动文件、重命名文件、复制文件、删除文件、压缩文件、执行一条外部命令、发送HTTP请求。

举个例子，一条完整的rea规则可能是：

事件：每天03:00触发一次扫描
规则：/data/logs 目录下所有 .log 结尾、大小超过 100MB 的文件
动作：写入归档清单后，调用 gzip 压缩，并在完成后输出一条日志

看到没有，整条规则读起来已经接近自然语言了，这就是规则驱动的好处。

2.3 核心执行流程：匹配、决策、执行、反馈

就拿一次实际执行来说，rea的处理流程可以拆成四个阶段：

• 扫描/监听阶段：rea根据配置，监控一个或多个目录。如果是扫描模式，就走一遍目录树，收集全部文件状态。
• 匹配阶段：对每个文件逐一跑规则集，看是否命中。匹配顺序也很重要，命中了第一条就不再往下走（后面的规则优先级低）。
• 决策阶段：执行动作前，rea会先模拟确认一遍，比如目标路径是否已存在同名文件、是否需要先备份、当前文件是否被占用。这个阶段本质是“保护性检查”。
• 执行阶段：执行真正的动作，同时把操作结果记录到运行日志里，并能通过回调（webhook、邮件、命令行通知）把结果反馈出去。

我实际用下来觉得，四个阶段里最容易出问题的其实不是执行，而是匹配阶段的规则先后顺序。比如你有一条“所有.log文件都压缩”的规则，又有一条“error开头的.log文件直接删除”的规则，如果不注意顺序，前者先把文件压缩了，后面的删除规则就永远触发不了。这就是典型的“执行顺序即业务逻辑”问题，测试时极其容易被忽略。

3. 核心配置解析与实操参数详解

3.1 配置文件的骨架结构

rea的配置我建议用YAML来写，理由很简单：它支持注释，层级清晰，不会像JSON那样写长了眼花缭乱。下面是一个最精简的配置骨架：

app: data_dir: ./data watchers: - name: log_watcher path: ./logs event: scan schedule: "0 3 * * *" rules: - name: compress_large_logs priority: 1 match: pattern: ".*\\.log$" min_size_mb: 100 action: compress action_params: keep_original: false

这段配置的意思很直白：每天凌晨3点扫描./logs目录，找出所有以.log结尾、大小超过100MB的文件，压缩它们，并且不保留原文件。

首次看到这种配置的人通常会问一个问题：为什么定时任务的标准表达式（Cron表达式）会出现在这里？其实这是因为rea调度器底层就是把事件分成了两类：一类是由文件变化触发的“自然事件”，另一类是由时间触发的“定时事件”。定时事件整体上也是事件的一种，只是触发源变成了时间。

3.2 匹配规则里的常用参数与写法建议

匹配规则是rea的核心，参数看着不多，但组合起来变化很多。我整理了一份自己常用的参数清单：

经验之谈，能不用正则就不用正则。ext、name_contains这种参数阅读起来更直观，也不会出现“看着能匹配但实际匹配不到”的尴尬情况。正则只留给真正需要表达复杂模式的地方。

3.3 动作定义的三种类型

动作是真正干活的环节，rea里的动作大致可以归为三类：

文件操作类这类动作最常见，比如移动、重命名、复制、删除、压缩。需要注意一点：rea处理移动动作时，如果目标路径不存在，默认会自动创建目录。这个默认行为看起来很贴心，但可能带来一个问题——自动创建的目录权限是默认权限，如果后续你的处理流程要求目录权限保持一致，可能还要额外配置权限参数。

命令执行类执行外部命令是rea的“万能后门”。比如压缩动作内置的算法不够用，你可以直接调用系统命令：

action: exec action_params: cmd: "tar -czf {{file_path}}.tar.gz {{file_path}}" shell: true

这里{{file_path}}是rea提供的模板变量，代表当前命中的文件路径。这个机制拓展性很强，但也要注意命令注入风险，尤其是文件路径来自外部输入时，最好先做一次路径白名单校验。

通知类通知动作主要用于告警和结果上报。常见的通知通道包括：HTTP请求、写文本日志、发送系统通知。比如我可以设定，凡是文件名包含error且文件大小超过50MB的日志，执行完归档动作后，自动向某个接口发起一个POST请求，带上文件名和大小信息。

这三类动作既可以单独使用，也可以串联成动作链。比如“先复制一份到备份目录，再执行压缩，最后删除原文件”，这种组合在实际场景里很常见。

4. 实操全过程：从初始化到规则调优

4.1 初始化环境与目录结构

我用一个模拟的场景来走一遍完整流程。假设现在有这么个需求：

• 有一个目录/home/user/rea_test/incoming，里面会不定时放入各种文本文件和日志文件；
• 需要把所有.log文件自动移动到processed目录下，并按当天日期生成子目录；
• 所有文件名中包含error的文件，在移动前需要额外做一次内容压缩备份；
• 整个处理过程需要输出一份处理摘要。

首先，创建一个项目目录，并初始化配置：

mkdir rea_test && cd rea_test mkdir -p incoming processed backup

然后我会写一个rea.yaml配置文件，内容如下：

app: data_dir: ./ runtime_file: .rea_state.json watchers: - name: incoming_watcher path: incoming event: scan interval_sec: 60 rules: - name: handle_error_logs priority: 1 match: ext: .log name_contains: error actions: - action: copy target: backup/ - action: exec cmd: "gzip -f {{file_path}}" shell: true - action: move target: processed/{{date}}/ - name: handle_normal_logs priority: 2 match: ext: .log actions: - action: move target: processed/{{date}}/

这里有个细节我要特意说一下：handle_error_logs优先级为1，先处理“包含error的log”；handle_normal_logs优先级为2，兜底处理其他所有log。顺序绝对不能反过来，否则所有日志都会被第二条规则吞掉，第一条规则永远轮不到。

4.2 核心处理逻辑的Python演示

虽然rea本身是配置驱动，但如果你打算自己实现一个最小版本，那么核心逻辑并不复杂。下面我用Python写一个极简版的核心处理调度，方便你理解rea在背后做了什么：

import os import re import shutil from datetime import datetime RULES = [ { "name": "handle_error_logs", "priority": 1, "ext": ".log", "contains": "error", "actions": ["backup", "compress"], }, { "name": "handle_normal_logs", "priority": 2, "ext": ".log", "actions": ["move"], }, ] def match_rule(filepath, rule): if not rule.get("ext") or filepath.endswith(rule["ext"]): pass else: return False if rule.get("contains") and rule["contains"] not in os.path.basename(filepath): return False return True def run_action(filepath, action_name, dest_dir): if action_name == "backup": shutil.copy2(filepath, os.path.join(dest_dir, "backup")) elif action_name == "compress": os.system(f"gzip -f {filepath}") elif action_name == "move": os.makedirs(dest_dir, exist_ok=True) shutil.move(filepath, os.path.join(dest_dir, os.path.basename(filepath))) def scan_and_process(base_dir): incoming = os.path.join(base_dir, "incoming") for filename in os.listdir(incoming): fullpath = os.path.join(incoming, filename) if not os.path.isfile(fullpath): continue date_str = datetime.now().strftime("%Y-%m-%d") processed_dir = os.path.join(base_dir, "processed", date_str) for rule in sorted(RULES, key=lambda x: x["priority"]): if match_rule(fullpath, rule): print(f"[matched] {filename} -> {rule['name']}") for action in rule["actions"]: run_action(fullpath, action, processed_dir) break if __name__ == "__main__": scan_and_process(".")

运行效果大致是这样：

$ python rea_lite.py [matched] app-error-20250121.log -> handle_error_logs [matched] normal.log -> handle_normal_logs

这种极简写法虽然离rea完整功能差得远，但它足以展示核心机制：按优先级顺序匹配规则，命中后执行一串动作，处理完一个文件就进入下一个。真正生产级的rea，还在这个基础上增加了事件监听、状态记录、并发控制等，但骨架就是上面这几行逻辑。

4.3 状态记录与断点续跑

文件数量一多，如果中途进程被中断，已经处理过的文件要不要重新处理？这个问题在批量处理场景里很要命。

rea的设计是引入一个状态文件，默认叫.rea_state.json。每处理完一个文件，rea会把文件的路径、大小、修改时间、哈希值记录进去。下一次扫描时，如果某文件的“路径+大小+修改时间”和状态文件里一致，就认为是“未变化”，直接跳过，不会重复执行动作。

这个机制对“移动动作”尤其重要。文件一旦被移动，原路径就不再存在，扫描也不会重复匹配，所以状态文件更多是防止重复处理内容相同的文件时用的。如果你后续自己实现rea，务必把状态文件的读写做成原子的——先写临时文件再替换，免得进程崩溃时把状态文件写坏了。

4.4 我实测的一组生产级配置

下面这个配置是我在一台文件服务器上实际用过的精简版，它做的事情是：

• 每10分钟扫描一次归档目录；
• 超过2天的.tmp文件直接删除；
• 超过500MB的.log文件压缩后归档；
• 所有处理动作记录到日志文件。

watchers: - name: archive_cleaner path: /data/archive event: scan interval_sec: 600 rules: - name: remove_old_temp priority: 1 match: ext: .tmp mtime_before: "2d" action: delete - name: compress_large_log priority: 2 match: ext: .log min_size_mb: 500 action: compress action_params: keep_original: false archive_dir: /data/compressed_logs logging: file: /var/log/rea/rea_run.log level: info format: "%(asctime)s %(levelname)s %(message)s"

这里提一个细节：mtime_before: "2d"这种写法支持相对时间表达式，比写绝对时间灵活得多。类似的表达式还有30m、6h、1w，在配置里表示“多久之前”非常方便。

5. 常见问题与排查技巧实录

5.1 规则没有按预期命中

这个问题出现的频率最高。我排查的时候，会按下面几个顺序来：

先排查扩展名大小写问题。比如.LOG和.log在Linux下是不同的文件名后缀，rea默认区分大小写。如果文件名是大写后缀，配置里写的却是小写ext: .log，必然命中不了。解决办法有两个：一是把文件名规范成小写，二是配置里加一个case_sensitive: false。

再排查路径是否真的对。很多人配置里写的是相对路径，但rea运行时的工作目录和你以为的不一样，导致扫描的目录根本不是同一个。我最开始就吃过这个亏：明明配置里写的path: logs，脚本却在项目根目录下找不到logs目录。解决方案很简单，建议所有路径都用绝对路径，除非你有特殊理由。

最后看状态记录。如果文件已经被处理过，状态文件里记录了它的信息，那无论如何都不会再匹配一次。这种情况下不是规则错了，而是“已经干过活”了。这时候可以临时删掉状态文件，或者调整规则内容，强制触发一次重新处理。

5.2 动作执行报错，文件被占用

在Linux下，文件被进程占用时依然可以读取和移动，但Windows下就会直接报错。如果你需要跨平台使用rea，建议对目标文件先做一次“是否能被重命名”的探测：

python -c "import os; os.rename('test.log', 'test.log.probe')"

能重命名说明文件没有被独占占用，反之则说明有进程正在写它。对于正在被写入的日志文件，最稳妥的策略是跳过该文件，等下一个扫描周期再处理，不要强行操作。

5.3 命令动作里使用了变量，但没有正确展开

这是一个典型的配置细节问题。很多人在action_params.cmd里写了类似gzip -f $file_path的写法，结果执行时发现变量没有被替换。这是因为rea里模板变量用的是双花括号{{file_path}}，而不是Shell风格的$file_path。如果你习惯写Shell，很容易在这里踩坑。

正确的写法应该是：

action: exec action_params: cmd: "gzip -f {{file_path}}" shell: true

如果你的命令本身就需要Shell变量（比如某些动态路径），建议分两步：先用rea模板变量取出文件路径，再在命令内使用Shell变量间接拼接。

5.4 并发与竞态问题

当文件数量很大，rea默认会使用多线程并发处理。多线程带来的问题也很经典：两个线程同时扫描到同一个文件，一个已经把它移动走了，另一个还在尝试匹配。这种情况通常表现为日志里出现大量“文件不存在”的报错。

我的建议是：在rea里开启“文件操作互斥锁”，或者干脆把并发数设成1。其实文件处理的耗时瓶颈通常不在操作本身，而在IO等待和外部命令调用，把并发从1调到4，性能提升可能不到两倍，但复杂度会上升不少。生产环境里我一般是保持并发为2，稳妥优先。

5.5 配置变更后产生误操作

这是最让我痛心的一类问题。有时候改配置只改了匹配范围的一个条件，没想到新的匹配条件覆盖了另一批原本不该动到文件，等执行完了才发现。这在rea里没有彻底的防御机制，但我们可以通过“演练模式”来规避。

rea支持dry_run: true模式，在这个模式下，所有动作都会被模拟但不真正执行，日志里会显示“将要做什么”。我的习惯是：任何配置变更后，先跑一次演练模式，肉眼检查输出的动作日志是否符合预期，再正式执行。千万不要图省事跳过这一步，一次误删的代价远大于多跑一次演练。

5.6 状态文件不断膨胀

状态文件如果记录的信息太多，比如每个文件都记录了哈希值，且文件数量庞大，运行一段时间后状态文件会变得很大。解决方案也不复杂：

• 只对关键目录开启哈希校验，普通目录只记录路径和修改时间；
• 定时清理状态文件中的过期条目，比如超过90天的直接忽略；
• 状态文件本身也要纳入日志轮转机制，避免单文件过大。

6. 一些想跟你分享的实操感悟

先说个大实话：rea这种工具，小项目用起来会觉得有点“过度设计”，明明一个for循环就能解决的事，非要变成配置和规则，看起来多了好几层。但项目一旦复杂起来，规则数量超过20条、文件类型超过5种、动作链路超过3步，for循环版本的代码就会迅速腐化，改一行都要担心影响另外十几种情况。配置驱动的价值，恰恰是在这个阶段体现出来。

我自己在做了几次规则调整之后最大的感受是：规则本身也是一份“代码”，需要review，需要测试，需要灰度。很多人觉得把脚本改成配置就是零成本，其实不是。脚本写错了会在运行时报错，规则写错了会静默地执行完全错误的操作。所以rea的“演练模式”不是设计者的自嗨，而是真实使用场景里必须的功能。

如果你也想自己实现一个简化版的rea，我的建议是先从“单目录扫描 + 三步规则”开始，不要一上来就搞事件监听、FTP监控、HTTP回调这些高级功能。启动时打印一条配置摘要就是一个很大的优势，比如：

[rea] loaded 2 watchers, 3 rules, 5 actions. dry_run=true

这一行信息就能避免大量低级的配错路径问题。

最后再分享一个“小技巧”：状态文件加上Git版本管理。每跑完一批任务，顺手把状态文件提交一次，这样就算误操作删了不该删的文件，你也能从状态文件里查出上一次扫描时那个文件存在过，至少知道它去了哪里、发生时间的线索。这是文件处理工具的保命机制，也是我踩过大坑之后养成的习惯。