Redis FUNCTION STATS 怎样区分运行中的函数与引擎统计

排查 Redis Functions 时，我会先问一个很具体的问题：现在到底有函数在执行，还是只是某个执行引擎里已经加载了不少函数库？FUNCTION STATS 的价值就在于把这两类信息放进同一个回复里，但它们的观察对象完全不同。

官方地址：https://redis.io/docs/latest/commands/function-stats/

running_script 看“此刻正在跑什么”，engines 看“有哪些执行引擎以及各自登记了多少函数和库”。前者适合定位长时间运行的调用，后者适合了解函数运行环境的结构，不能拿引擎统计代替正在执行的证据。

先把运行态与引擎态分成两条观察线

Redis 官方文档把 FUNCTION STATS 的返回说明为一个包含两个键的回复。第一条是 running_script：如果没有正在执行的函数，它就是 nil；如果有，则包含函数名、调用命令及参数、运行时长。第二条是 engines：它按执行引擎分组，提供每个引擎的函数数和库数等统计。

这其实是一种很实用的观察模式：用同一个入口同时回答“有没有当前任务”和“环境里装了什么”。但不能因为 engines 有数据，就推断某个函数正在执行；引擎统计更像结构概览，running_script 才是当前调用的线索。

用 FUNCTION STATS 读取长任务线索

命令本身没有参数，直接执行即可。它从 Redis Open Source 7.0.0 开始提供，时间复杂度为 O(1)，ACL 分类属于 @slow 和 @scripting。

# 读取当前运行函数和各执行引擎的统计
redis-cli FUNCTION STATS

为了理解返回结构，可以把它抽象成下面的示例。示例中的名称、命令和耗时只是解释字段含义，不是某个实例的实测输出：

# 有函数运行时，running_script 提供调用线索
running_script
  name: order:reserve
  command: FCALL order:reserve 2 stock:1 order:9
  duration_ms: 842

# engines 提供执行引擎的结构统计
engines
  LUA
    functions: 12
    libraries: 3

阅读时先看 running_script 是否为 nil，再看 duration_ms 是否说明调用持续时间已经值得关注。name 告诉你函数标识，command 帮你回到调用入口和参数上下文；它们比单独看到一个“Redis 变慢了”的告警更接近问题现场。

按 engines 判断函数库分布，而不是判断当前请求

如果 running_script 没有在执行，engines 仍然可能返回引擎统计。这正是标题里“区分”的关键：函数库已经加载、函数数量发生变化，说明运行环境有内容，但不代表某个函数此刻占用执行时间。

我会把这部分用于两类架构判断。第一类是部署后检查：某个引擎是否拥有预期的函数与库数量。第二类是变更排查：加载或恢复函数库后，结构统计是否符合设计。它适合回答“环境里有哪些能力”，不适合单独回答“哪个请求正在拖慢当前实例”。

把观察结果接到 FUNCTION KILL 决策

官方文档给出的使用方向是：可以用 FUNCTION STATS 检查长时间运行的函数，再决定是否使用 FUNCTION KILL。这里必须保留一个重要边界：FUNCTION KILL 只能终止执行期间没有修改数据集的函数，因为停止只读函数不会破坏脚本引擎对原子性的保证。

# 先观察当前执行对象；不要把引擎统计当成终止依据
redis-cli FUNCTION STATS

# 只有确认目标函数仍在执行且满足只读边界后，才考虑终止
redis-cli FUNCTION KILL

这两条命令不是“查到耗时就立即停止”的自动流程。观察结果要和函数是否修改数据集、业务是否允许中断一起判断；如果函数已经写入数据，不能为了追求响应时间而越过原子性约束。

用一张清单避免把三种状态混在一起

• 没有运行函数：running_script 为 nil，只能说明当前没有 in-flight function，不等于历史上没有慢调用。
• 有长时间运行函数：查看 name、command 和 duration_ms，先确定调用上下文，再评估是否需要动作。
• 只有引擎统计：查看 engines 的函数数和库数，把它当作环境结构，不要据此锁定某个当前请求。
• 准备终止：额外确认函数没有修改数据集，并接受中断带来的业务影响。

我的结论是：FUNCTION STATS 不是一张历史性能报表，而是一张“当前执行线索 + 引擎结构概览”的快照。先沿 running_script 找当前函数，再沿 engines 看环境结构，最后才把 FUNCTION KILL 当成带条件的动作，排查路径会清晰很多。

相关问题

FUNCTION STATS 能查看历史函数耗时吗？ 不能把它当成历史累计报表；它主要返回当前运行函数的信息和执行引擎统计。

running_script 为空时 engines 也会为空吗？ 不一定。当前没有 in-flight function 与引擎中登记了多少函数、库是两条独立信息。

看到 duration_ms 很大就能直接 FUNCTION KILL 吗？ 不能。还要确认函数没有修改数据集，并结合业务影响判断是否允许终止。