寒蝉 Hancic
负载均衡：不只是平均分配
负载均衡不只是轮询分请求。节点能力不同要加权，实时负载不同要动态选，有状态要保亲和，缓存要一致性哈希，节点上下线要平滑过渡，健康检查要主动加被动，还得和熔断配合。多层配合比单层完美更靠谱。
标签：后端
Web 服务器怎么选
Nginx、Apache、Tomcat、Caddy、Traefik，还有框架自带的 uvicorn、Gunicorn、net/http——这些 Web 服务器各自擅长什么，什么场景选什么。
脑裂：分布式系统里最危险的故障
脑裂：集群分区后两个子集各自选出主节点，并行写入导致数据分叉。根因不是节点真挂了，而是看起来挂了——网络分区、心跳超时、VM暂停都会触发。防护靠 quorum + fencing token + 租约三层。Raft/Paxos 防选主脑裂，但 fencing 仍需存储层配合。
幂等性：分布式系统里"做两次"为什么不等于"做一次"
幂等性（Idempotency）= 同一操作执行一次和多次产生相同结果。分布式环境下网络超时、消息重投、自动重试逼着操作必须幂等。实现靠"记住做过没有"：request_id 去重表、唯一约束、状态机、乐观锁。幂等和并发安全是两件事——前者管重复不出错，后者管同时不出错。
认证与鉴权选择指南：JWT、OAuth 2.0、RBAC、ABAC、Keycloak 各自该出现的地方
一个服务刚上线，没用户，没登录。调用方都是内部系统，相互信任——IP 白名单就够了。 后来用户来了。要区分谁是谁。再后来有管理员、有普通用户、有只读用户。角色一多，权限判断就散在代码里——if user.role == 'admin' 写了二十遍，改一次要改二十个文件。 这时候你才开始看认证鉴权方案
压缩算法选择指南：LZ4、Snappy、gzip、Brotli、Zstd
一个服务每天往外吐几十 G 日志。你第一反应不是「换个压缩算法」，是「太大了，压一下」。 gzip -9 access.log，跑完一看，体积缩到十分之一。满意了。 后来日志量翻倍，gzip 跑一次要二十分钟。你开始想：能不能快点。 再后来上了 Kafka，消息要实时传。压缩不是在磁盘上慢慢压——每
重试机制选择指南
调用一个外部服务失败了，第一反应是再试一次。这个直觉没错，但「再试一次」从一句代码到生产可用的重试策略，中间隔着好几层坑——每一层都是被上一层的代价逼出来的。 起点：固定次数重试 最直觉的做法：失败就重试，重试 N 次，还不行就放弃。 for i in range(3): try: return c
API 限流方案选择指南
限流是个听起来很简单的问题：请求太多，挡一挡就行。但真到实现的时候，你会发现「怎么挡」的答案一直在变——被业务规模一层层逼着升级。 起点：固定窗口计数器 最直觉的方案：在内存里记一个计数器，当前这一秒来了多少请求，超过阈值就拒。 伪代码，不是让你抄 counter = 0 windowstart =
日志级别选择指南：DEBUG、INFO、WARN、ERROR 各自该出现的地方
刚开始写代码，日志就是 print("hello")。能出结果就行。 后来项目上了线，print 不管用了。打了太多，找不着；打了太少，查不到。半夜三点报警响了，你翻日志翻了几百兆，发现全是「程序已启动」「查询已完成」，没有一条告诉你为什么慢。 这就是日志级别的由来：不是给机器分类的，是帮你在半夜三
定时任务方案选择指南：crontab、K8s CronJob、Airflow、XXL-JOB 各自该出现的地方
一个项目刚开始，定时任务少，随手扔个 crontab -e，一行表达式一个脚本。没人纠结——能跑就行。 后来定时任务多了。三个 cron 变十几个，散在不同机器上。没人知道哪个在跑、哪个停了、哪个重复了。要补跑、要暂停、要看日志——每次都先 ssh 上去找脚本在哪。然后你开始看调度框架：Airflo
