bash

  • 2026.08.10 | youres | 258次围观
    bash FIFO令牌桶实现并发控制完整教程:3种写法让你的批量任务跑满不超载
    写批量脚本的时候,你有没有遇到过这种两难:并行数设低了效率上不去,设高了服务器又扛不住。用 bash 的 FIFO 加 wait -n 搭一个令牌桶,就能把这事解决得很漂亮。 什么是令牌桶?为什么它适合做并发控制 令牌桶的核心逻辑很简单:桶里有固定数量的"令牌",每个任务启动前必须从桶里取走一个令牌,任务结束后把令牌还回去。这样同时运行的任务数量永远不会超过桶的容量。换成 bash 的说法就是:创建 N 个 FIFO,启动任务前从某个 FIFO 读一把,任务结束时往另一个...
  • 2026.08.09 | youres | 95次围观
    bash wait -n作业表回收机制详解:为什么后台任务结束后记录还在
    在写bash并发脚本时,很多人会遇到这样一种困惑:明明后台任务已经执行完了,jobs 命令却仍然显示那条记录。脚本跑久了,作业表越来越长,甚至开始影响脚本行为。这到底是怎么回事?今天就来把 wait -n 相关的作业表回收机制讲清楚。 什么是bash的作业表 bash 为每个 shell 会话维护一张「作业表」(job table),用于跟踪当前 shell 中启动的所有后台任务。每启动一个后台进程,bash 就会在作业表中创建一条记录,记录内容包括:进程号(PID)、任...
  • 2026.08.07 | youres | 93次围观
    bash随机抖动jitter防止重试风暴:让批量任务不再同时撞墙
    写批量任务脚本时,你可能遇到过这种情况:服务器临时挂了,一堆客户端同时检测到失败,然后——按照同一个固定间隔——在完全相同的时刻发起重试。结果不是问题解决了,而是把服务器直接冲垮了。这种现象叫重试风暴(Thundering Herd),也叫惊群效应。问题的根源不在重试逻辑本身,而在重试时机太整齐。 固定间隔为什么会引发风暴 假设100台机器同时检测到API超时,约定每隔5秒重试一次。这100台机器从同一秒开始计时,下一次重试全部发生在T+5s、T+10s……每5秒就有10...
  • 2026.08.05 | youres | 91次围观
    bash随机抖动jitter防止重试风暴实战:让批量任务的等待策略不再集体踩踏
    你有没有遇到过这种情况:一批脚本同时跑,突然某个接口抖动了一下,结果所有脚本同时失败,又同时在第30秒、60秒、120秒发起重试——流量撞在一起,雪球越滚越大。这就是典型的「惊群效应」,也叫重试风暴(Retry Storm)。 解决思路其实很简单:给每次重试间隔加一点随机性,让大家的等待时间错开。这就是本文要讲的 jitter(随机抖动)。 为什么指数退避还不够 先看一个典型的指数退避脚本: #!/bin/bashmax_retries=5delay=2attempt...
  • 2026.08.04 | youres | 91次围观
    bash jobs命令管理后台任务生命周期:3个实战技巧让你的任务稳如泰山
    在 Linux 和 macOS 上写 Shell 脚本时,后台任务管理是个绕不开的话题。启动一个后台进程之后,它到底在跑还是在等?关了终端会不会丢?想把任务拉回前台怎么做?这些问题的答案,全靠 bash jobs 命令和相关工具链撑起来。 这篇文章把后台任务的整个生命周期讲清楚:从启动到查看、从挂起到恢复、从转后台到彻底脱离终端,每一步都有实战代码。搞懂这些,你写出来的脚本在生产环境里才不会莫名其妙断掉。 什么是 bash 后台任务? 默认情况下,你在终端执行的命令是前...
  • 2026.08.01 | youres | 119次围观
    wait -n实现Shell并发数控制任务池:3种写法让批量任务跑满不超载
    批量任务跑得慢,第一反应是加并发;结果一梭子把几百个后台进程全放出去,机器直接卡死、连接被对端限流、日志乱成一锅粥。真正需要的不是"无限并发",而是并发数可控的任务池——池子里始终跑 N 个,结束一个补一个。bash 从 4.3 起提供的 wait -n 就是干这个的,配合几行循环就能搭出一个够用的调度器,不用装 GNU Parallel,也不用被 xargs 的参数拼接折腾。 下面把我实际在巡检脚本里跑过的几种写法、踩过的坑和兜底方案一次讲清楚。 一、为什么"全放后台再...
  • 2026.07.29 | youres | 87次围观
    bash wait -n 返回 127:究竟是怎么回事
    bash wait -n 返回 127:究竟是怎么回事在 Shell 脚本里用 wait -n 等待后台任务时,最让人摸不着头脑的报错就是退出码 127。明明 wait 是 bash 内置命令,为什么会报"命令找不到"?这篇文说清楚背后的原因。退出码 127 的本质含义在 POSIX 规范里,退出码 127 的标准含义是"命令或参数无法找到"("command not found")。但当你看到 wait -n 触发...
  • 2026.07.28 | youres | 94次围观
    bash wait -n用法详解与版本兼容:并行脚本等任意一个任务结束的正确姿势
    写并行 Shell 脚本时,最常见的痛点是:起了一堆后台任务,想在「任何一个」任务结束时立刻拿到它的退出码,而不是傻等全部跑完。bash wait -n 就是干这个的。但这个选项有明显的版本门槛,macOS 自带的老 bash 直接不认识它。这篇把 wait -n 的用法、退出码规则和版本兼容一次讲清,全部内容都在真机上验证过。 一、wait -n 是干什么的 普通的 wait 不带参数时,会阻塞到所有后台任务结束,且返回值恒为 0——这意味着你根本不知道哪个任务失败了。而...
  • 2026.07.27 | youres | 91次围观
    wait后台任务退出码精确捕获方法:3种方案让并行脚本失败无处遁形
    Shell脚本里用「&」把任务扔到后台跑,速度是快了,但退出码经常收不回来——脚本最后一行 wait 一执行,$? 永远是 0,哪个任务失败了根本不知道。这篇把 wait 后台任务退出码精确捕获的几种方法一次讲透,全是能直接抄的代码。 为什么直接 wait 拿不到退出码 先说清楚问题根源。不带参数的 wait 会等所有后台任务结束,但它的返回值和子任务的成败没有关系——在 bash 里,裸 wait 的退出码通常就是 0(除非 wait 本身被信号打断)。所以下面这...
  • 2026.07.11 | youres | 139次围观
    bash timeout自动重试循环脚本:3种写法让你的任务超时不再放弃
    批量跑任务最怕什么?不怕它慢,就怕它超时后直接放弃,特别是关键的数据同步、健康检查、接口调用这类必须成功的场景。bash脚本配合timeout命令,可以让任务超时后自动重试,直到成功或达到重试上限才退出——这篇文章介绍3种常见写法,各有各的适用场景。 先搞清楚timeout命令的行为 timeout是GNU coreutils里的命令,作用是给进程发送指定信号,超时后强制终止。基本用法是: timeout 30s curl -s https://api.example.co...
1