秒杀系统中 Shell 脚本并发控制 Bug：究竟哪里出了

在高并发场景下，诸如秒杀、抢购等活动往往对系统的稳定性和性能提出极高要求。作为独立开发者或个人博主，我们在设计和部署相关系统时，常常忽视了一些看似"基础"的工具------Shell 脚本。本文将从一个真实线上 Bug 出发，深入探讨 Shell 脚本在处理高并发请求时可能引发的问题，并一步步还原、定位、修复及总结这一案例。

引言：从一次生产环境崩溃说起

某电商类项目上线后，每逢大促活动，服务器总会出现不同程度的崩溃现象。最初以为是数据库连接池配置问题或 Redis 缓存命中率不足所致。然而，在多次排查未果后，终于发现了一个被忽略的隐患：用于生成订单 ID 的 Shell 脚本存在并发控制缺陷。

该脚本原本设计为通过原子操作 find /tmp -name "order*.tmp" 获取当前最小的空闲文件，并重命名为实际的订单 ID 文件。但由于 Shell 脚本本身的执行机制问题，在高并发场景下出现了多个进程同时读取并重命名同一批文件的情况，导致生成的订单 ID 冲突甚至重复。

一、Bug 复现与初步分析

1.1 业务逻辑概览

在秒杀活动中，用户抢购商品时会通过 API 触发订单生成逻辑。为避免订单 ID 冲突，系统使用了一个简单的 Shell 脚本辅助生成全局唯一订单号。原始脚本如下：

bash 复制代码

#!/bin/bash
ORDER_DIR="/tmp/order_ids"
cd "$ORDER_DIR" || exit 1
for file in order*.tmp; do
    if [ ! -f "$file" ]; then
        mv "$file" "${file%.tmp}"
        echo "Generated order ID: ${file%.tmp}"
        exit 0
    fi
done

此脚本旨在查找 /tmp/order_ids 目录下的所有以 order*.tmp 命名的文件，并选择第一个"空闲"（即不包含 .tmp 后缀）文件进行重命名。

1.2 高并发场景下的异常行为

在测试环境中模拟 500 个并发请求时，发现有部分请求返回了相同订单号或错误提示"无法生成唯一订单号"。这表明脚本未能正确处理多个进程同时执行的情况。

为复现此问题，编写了以下测试脚本模拟多个子进程同时运行：

bash 复制代码

#!/bin/bash
for i in {1..500}; do
    (cd /tmp/order_ids && ./generate_order.sh) &
done
wait

运行该脚本后，在日志中确实出现了如下的冲突记录：

vbnet 复制代码

Generated order ID: order001
Generated order ID: order002
...
Generated order ID: order00357
Error: No available order template files.

可以看到，在某些情况下，所有 order*.tmp 文件均被占用后，脚本会返回错误信息。

二、深入分析与问题根源定位

2.1 Shell 脚本的并发特性分析

Shell 脚本本身是基于进程调度模型工作的。每个独立调用都会创建一个新的 shell 进程，并且每个进程都有自己的内存空间和变量副本。这意味着上述 generate_order.sh 脚本能被多线程/多进程同时调用。

但问题是：当多个进程几乎同时读取并处理同一目录下的 .tmp 文件时，"哪一个先执行"无法保证原子性。这种非原子操作极易造成竞态条件（race condition），即多个进程争抢同一资源而出现状态不一致的问题。

2.2 使用 fuser 和 lsof 工具辅助排查

为了确认这一点，我们在服务器上使用了 fuser 和 lsof 工具查看 /tmp/order_ids 目录下哪些文件正在被哪些进程打开：

bash 复制代码

fuser -v /tmp/order_ids
lsof | grep /tmp/order_ids/

输出显示，在高并发期间，有多个进程同时打开并修改该目录下的文件内容。

三、修复方案与优化建议

3.1 改进后的脚本设计：使用 flock 实现互斥锁

为避免竞态条件，在 Shell 脚本中可以借助 flock 命令实现对关键资源的加锁操作。改进后的脚本如下：

bash 复制代码

#!/bin/bash
ORDER_DIR="/tmp/order_ids"
LOCKFILE="$ORDER_DIR/generate_lock"

exec <"$LOCKFILE" # 将文件描述符设置为锁定对象（任意即可）
flock -n $LINENO || exit 1 # 尝试获取锁（-n 表示非阻塞）

cd "$ORDER_DIR" || exit 1

for file in order*.tmp; do
    if [ ! -f "$file" ]; then
        mv "$file" "${file%.tmp}"
        echo "Generated order ID: ${file%.tmp}"
        exit 0
    fi
done

echo "No available order template files."
exit 1

通过 flock 加锁的方式确保在同一时刻只有一个进程 能进入关键代码段（即搜索和重命名 .tmp 文件的部分），有效解决了竞态条件问题。

3.2 使用临时目录与异步清理机制优化性能

为了进一步提升系统的健壮性与效率，我们引入了临时文件清理任务：

bash 复制代码

#!/bin/bash

# 清理过期临时文件任务（每小时执行一次）
LOG_DIR="/var/log/order"
TMP_DIR="/tmp/order_ids"
MAX_AGE=3600 # 单位：秒

find "$TMP_DIR" -name "order*.tmp" -mmin +$MAX_AGE -delete > "$LOG_DIR/cleaner.log" 2>&1 &

这一方式减少了因长时间未清理导致磁盘空间耗尽的风险，并且提高了整体效率。

四、对比分析表：旧方案 vs 新方案效果对比

对比维度	原始方案	改进方案
并发安全性	存在竞态条件可能导致冲突	使用 flock 确保原子操作
性能	慢速、易出错	更加高效且稳定
日志完整性	日志杂乱、难以追踪	日志规范清晰
系统资源消耗	易导致磁盘空间耗尽	引入定时清理任务

小结与下一步建议

Shell 脚本虽然简单易用，但在处理高并发、分布式场景下仍需谨慎对待其并发控制能力。本文通过一个真实的生产 Bug 展示了如何从现象出发逐步排查问题的本质原因，并提供了切实可行的修复方案与优化策略。

下一步建议：

在所有关键路径中引入锁机制或数据库事务。
使用更现代的语言如 Python 或 Go 替代纯 Shell 实现核心逻辑。
定期评估现有系统中的同步点是否足够健壮。
对于大规模秒杀系统建议采用更专业的分布式 ID 生产方式如 Snowflake 或 Redis 自增计数器等手段。

对于独立开发者来说，在面对复杂业务逻辑的同时也要关注"细节"，哪怕是一个简单的 Shell 脚本也值得认真对待。

本文参考文献： http://www.wzjinhao.cn/juejin-phfl68rt.html