寒蝉 Hancic
重试机制选择指南
调用一个外部服务失败了，第一反应是再试一次。这个直觉没错，但「再试一次」从一句代码到生产可用的重试策略，中间隔着好几层坑——每一层都是被上一层的代价逼出来的。 起点：固定次数重试 最直觉的做法：失败就重试，重试 N 次，还不行就放弃。 for i in range(3): try: return c
标签：后端
「2026-08」的文章 清除筛选
API 限流方案选择指南
限流是个听起来很简单的问题：请求太多，挡一挡就行。但真到实现的时候，你会发现「怎么挡」的答案一直在变——被业务规模一层层逼着升级。 起点：固定窗口计数器 最直觉的方案：在内存里记一个计数器，当前这一秒来了多少请求，超过阈值就拒。 伪代码，不是让你抄 counter = 0 windowstart =
日志级别选择指南：DEBUG、INFO、WARN、ERROR 各自该出现的地方
刚开始写代码，日志就是 print("hello")。能出结果就行。 后来项目上了线，print 不管用了。打了太多，找不着；打了太少，查不到。半夜三点报警响了，你翻日志翻了几百兆，发现全是「程序已启动」「查询已完成」，没有一条告诉你为什么慢。 这就是日志级别的由来：不是给机器分类的，是帮你在半夜三
定时任务方案选择指南：crontab、K8s CronJob、Airflow、XXL-JOB 各自该出现的地方
一个项目刚开始，定时任务少，随手扔个 crontab -e，一行表达式一个脚本。没人纠结——能跑就行。 后来定时任务多了。三个 cron 变十几个，散在不同机器上。没人知道哪个在跑、哪个停了、哪个重复了。要补跑、要暂停、要看日志——每次都先 ssh 上去找脚本在哪。然后你开始看调度框架：Airflo
配置文件格式选择指南：JSON、YAML、TOML、INI、ENV、XML 各自的代价与适用场景
有个事在软件开发里反复发生：你花在纠结配置文件格式上的时间，比你花在写配置本身上的时间还多。 这不是你的问题。配置文件在任何一个项目里都长成痛点：一开始随手扔个 .env 就够，后来要分环境、要嵌套、要注释、要校验——每个需求冒出来时，先前的格式就有一项撑不住。于是你开始看别的格式，发现每种都有一帮
从内存到消息队列：数据交换的进化链
一个系统刚开始的时候，所有数据都在一个进程里。函数调函数，变量传变量——快，简单，不会出错。这时候你不需要什么 REST，不需要什么消息队列，甚至不需要文件。 后来系统长大了。数据量撑破内存，业务逻辑要拆成多个进程，甚至要拆到不同的机器上。这时候你才意识到：数据要跨边界了。跨边界的代价，比你以为的大
