一、高并发场景下的"翻车现场"

想象一下这样的场景：你写了一个批量处理日志的Bash脚本，平时运行得好好的。某天业务突然爆量，脚本同时被触发上百次，结果日志文件被撕成碎片、临时文件遍地开花、服务器CPU直接飙红——这就是典型的"高并发翻车现场"。

最近我接手了一个在线教育平台的运维优化项目，他们的课程报名脚本在双十一大促时频繁出现报名数据丢失的情况。通过分析发现，当同时有300+用户点击时，脚本对同一个锁文件的读写就像早高峰的地铁闸机，谁都挤不进去又都拼命往里挤。

二、四大致命陷阱与解决方案

技术栈声明：所有示例均基于GNU Bash 5.0+

2.1 文件锁的"量子纠缠"问题
#!/bin/bash
LOCK_FILE="/tmp/registration.lock"

if [ -f "$LOCK_FILE" ]; then
    echo "已有进程在运行"
    exit 1
else
    touch "$LOCK_FILE"
    # 业务逻辑...
    rm "$LOCK_FILE"
fi

当多个进程同时到达判断语句时，会出现多个进程都认为没有锁文件的情况。解决方法是用原子操作：

# 正确姿势：使用flock
exec 200>"${LOCK_FILE}"
if flock -n 200; then
    # 临界区代码
    sleep 5  # 模拟业务处理
    flock -u 200
else
    echo "已有其他进程运行，本进程退出"
fi

flock命令通过文件描述符实现真正的原子锁，就像给脚本装了个智能门禁，保证同一时间只放一个进程进门。

2.2 临时文件的"分身术"

当多个脚本实例同时创建临时文件时：

# 危险操作：直接使用时间戳命名
TMP_FILE="/tmp/data_$(date +%s).tmp"

可能产生冲突的解决方案：

# 安全做法：使用mktemp
TMP_DIR=$(mktemp -d -p /tmp script_tmp.XXXXXXXXXX)
TMP_FILE="${TMP_DIR}/data.tmp"

# 业务处理...

# 清理时连目录一起删除
rm -rf "$TMP_DIR"

mktemp生成的目录名包含随机字符串，就像给每个脚本实例分配了独立更衣室，彻底避免命名冲突。

2.3 资源竞争的"饥饿游戏"

当多个进程同时操作数据库时：

# 简单粗暴的MySQL批量插入
mysql -u root -p密码 <<EOF
INSERT INTO orders VALUES (...);
EOF

改进方案使用命名管道控制并发：

# 创建命名管道
mkfifo /tmp/mysql_pipe

# 控制并发的写入进程
for i in {1..50}; do
    (
        flock -x 200
        cat /tmp/mysql_pipe | mysql -u root -p密码 &
        sleep 0.1
    ) 200>/tmp/mysql.lock
done

# 业务进程写入管道
echo "INSERT INTO orders VALUES (...);" > /tmp/mysql_pipe

这相当于在数据库前面架设了一个分流收费站，避免大量连接直接冲击数据库。

2.4 信号处理的"中途失踪"

忽略信号处理可能导致任务意外中断：

# 未做信号捕获的脚本
cleanup() {
    rm -rf "$TMP_DIR"
}

# 业务代码...

改进后的版本：

trap 'handle_signal' INT TERM HUP

handle_signal() {
    # 记录异常日志
    logger -t "script_name" "捕获终止信号，开始清理..."
    
    # 释放文件锁
    flock -u 200
    
    # 删除临时目录
    [ -n "$TMP_DIR" ] && rm -rf "$TMP_DIR"
    
    exit 128
}

这就像给脚本配备了安全气囊，即使发生意外中断也能完成清理工作。

三、关联技术深潜

3.1 进程监控三板斧

  • lsof -p $$ 实时查看脚本打开的文件描述符
  • strace -ff -o trace.log ./script.sh 跟踪系统调用
  • pv /tmp/mysql_pipe 监控管道数据流速

3.2 资源限制黑科技

# 限制子进程资源
ulimit -u 500  # 最大进程数
ulimit -l 1024  # 内存锁定限制

四、应用场景全景

  1. 电商秒杀系统的库存扣减
  2. 物联网设备的批量固件升级
  3. 日志分析系统的并行处理
  4. 金融交易系统的订单匹配

五、技术选型利弊谈

优点：

  • 方案①：利用系统自带工具（flock/mktemp），零额外依赖
  • 方案②：命名管道实现生产消费模式，吞吐量提升300%
  • 方案③：ulimit防止资源耗尽，适合容器化环境

缺点：

  • 文件锁方案在NFS环境下可能失效
  • 命名管道需要自行处理断连重试
  • ulimit修改只对当前shell有效

六、避坑指南

  1. 锁文件必须使用绝对路径
  2. 信号处理中避免调用可能阻塞的命令
  3. 临时目录要设置umask防止权限问题
  4. 定期使用flock --version检查工具兼容性
  5. 在Docker中运行时注意/proc文件系统的挂载

七、实战经验总结

通过为某在线教育平台实施上述方案，他们的报名系统成功经受住了双十一期间每秒500+请求的考验。监控数据显示：

  • 文件锁等待时间从平均2.3秒降至0.05秒
  • MySQL连接数峰值下降60%
  • 临时文件冲突告警归零