禁用swap让服务OOM时快速失败："死了比慢要好"的设计哲学

雪球在容器内存资源限制上做了一个反直觉但很有说服力的决策：主动禁用swap（交换分区）。常规直觉认为swap是一道保险——内存不够时用磁盘空间顶一顶，避免进程直接被OOM Killer杀死。但雪球团队的判断是：一旦一个服务真的触发了OOM（内存耗尽），更希望它直接快速失败（Fast Fail）、被监控系统立刻捕捉到并报警，而不是靠swap硬撑着继续运行——因为一旦开始用swap顶替物理内存，服务的响应会因为频繁的磁盘I/O而急剧变慢，这种”卡在半死不活”的状态往往比”直接挂掉”更难被及时发现和处理，也更容易在用户侧造成体验极差但又不至于触发常规故障告警的隐性伤害。这个决策背后有一句朴素但精辟的原则：”死了比慢要好”——一个明确失败的服务能被监控和自动化恢复机制迅速感知并处理（比如重启这个容器实例），而一个”没死但极慢”的服务往往会拖累整条调用链路，造成的连锁影响可能远大于它直接挂掉。这个决策能够成立还有一个重要前提：雪球同时大力推进了服务化和去状态化，因为服务本身无状态、可以被随时重建，”死了”的代价被压得很低（重启一个新实例就好），”死了比慢要好”这个取舍才划算——如果服务本身是有状态的，直接失败可能意味着数据丢失或状态不一致，这时”宁可慢一点硬撑住”可能才是更合理的选择。这提醒了一条通用的容错设计原则：故障处理策略的选择（快速失败 vs 尽力硬撑）不能脱离服务本身”失败代价有多高”这个前提单独讨论，无状态、易恢复的服务更适合选择快速失败。