4. PFC死锁与PFC风暴：我踩过的坑，以及如何避免？
PFC这东西，说白了就是给无损网络兜底的。但兜底不等于万能。我在好几个数据中心项目里，都亲眼见过PFC从“救星”变成“灾星”。今天咱们就聊聊，PFC死锁和PFC风暴这两个最要命的坑，以及我是怎么爬出来的。
4.1 先搞清楚：PFC到底在干嘛？
PFC（Priority Flow Control）是一种基于优先级的流控机制。它允许接收端告诉发送端：“兄弟，我这边的缓冲区快满了，你先停一停。” 发送端收到PAUSE帧后，就会暂停发送对应优先级的数据。
嗯，听起来很美好对吧？但问题就出在“暂停”这两个字上。
核心要点： PFC不是万能的。它只能缓解拥塞，不能解决死锁。而且用不好，还会引发风暴。
4.2 PFC死锁：我踩过最深的一个坑
我记得有一次，在某个大型数据中心做RoCEv2部署测试。业务跑得好好的，突然整个集群的吞吐量掉到了零。所有交换机端口都在疯狂发PAUSE帧，但数据就是一动不动。
这就是典型的PFC死锁。为什么会这样？
你想想看，假设有两条数据流：流A从交换机1到交换机2，流B从交换机2到交换机1。如果流A占用了交换机2的缓冲区，导致交换机2向交换机1发PAUSE；同时流B占用了交换机1的缓冲区，导致交换机1向交换机2发PAUSE。好了，两边都在等对方先放行，结果谁都不动——死锁了。
说白了，这就是一个循环依赖的问题。我在项目中遇到过的最常见场景，就是多路径负载均衡不均匀导致的。一条路径堵死了，另一条路径还在拼命往里灌数据，死锁就来了。
4.2.1 死锁的典型特征
- 端口持续收到PAUSE帧，但数据吞吐量为零
- 所有相关端口的TX_PAUSE帧计数持续增长
- 链路利用率极低，但缓冲区占用率很高
- 重启端口或交换机才能恢复
警告： 死锁一旦发生，光靠软件层面的超时重传是解不开的。必须从硬件层面打破循环依赖。
4.3 PFC风暴：比死锁更隐蔽的杀手
PFC风暴，我个人的理解是：PFC帧在网络上像病毒一样扩散，最终导致整个网络瘫痪。
为什么会这样？举个例子：
交换机A的某个端口缓冲区满了，它向上一跳交换机B发PAUSE。交换机B收到后，暂停了对应优先级的数据发送。但交换机B的其他端口还在收数据，这些数据没地方去，于是交换机B的缓冲区也满了。它只好继续向上游发PAUSE。就这样，PAUSE帧一级一级往上传播，最终波及整个网络。
我在一个项目中就遇到过这种情况。当时只是某个ToR交换机的一个端口出现了短暂的拥塞，结果PAUSE帧一路传到了核心层，整个数据中心的RoCEv2流量全部停摆。嗯，那场面，真是让人印象深刻。
4.3.1 风暴的扩散路径
| 层级 | 现象 | 影响范围 |
|---|---|---|
| 接入层 | 单个端口缓冲区满，发送PAUSE | 仅影响该端口 |
| 汇聚层 | 多个端口收到PAUSE，缓冲区开始堆积 | 影响整个汇聚组 |
| 核心层 | PAUSE帧扩散到核心交换机 | 影响整个数据中心 |
4.4 如何避免？我总结的几条实战经验
踩过坑之后，我总结了一套比较实用的避坑指南。不一定适用于所有场景，但至少能帮你避开90%的坑。
4.4.1 死锁的解决方案
- 打破循环依赖：在芯片设计层面，确保每个优先级的数据流不会形成环路。我习惯的做法是，在交换芯片的流控逻辑里加入“超时回退”机制。如果一个端口持续收到PAUSE超过一定时间（比如100ms），就强制丢弃部分数据包，打破死锁。
- 使用死锁检测与恢复机制：在芯片内部实现死锁检测逻辑。当检测到某个优先级的数据流长时间没有进展时，主动丢弃一个数据包，让上层协议触发重传。
- 合理规划拓扑：避免在二层网络中出现环形拓扑。如果必须用环，确保使用STP或类似协议打破环路。
小技巧： 我曾经在交换芯片里加了一个“死锁看门狗”定时器。每个端口每收到一个PAUSE帧，就重置定时器。如果定时器超时（比如500ms），就认为可能发生了死锁，自动触发恢复流程。这个方法虽然简单，但效果很好。
4.4.2 风暴的解决方案
- 限制PAUSE帧的传播范围：在芯片设计时，可以配置PAUSE帧的“跳数限制”。比如，只允许PAUSE帧在接入层和汇聚层之间传播，不允许进入核心层。
- 使用PFC Watchdog：当某个端口持续发送PAUSE帧超过一定阈值时，自动关闭该端口的PFC功能，或者降低该端口的优先级。
- 缓冲区隔离：为每个优先级分配独立的缓冲区。这样，一个优先级的拥塞不会影响到其他优先级。
4.5 核心逻辑：一张图看懂
下面这张图，是我自己总结的PFC死锁与风暴的核心逻辑。你看完应该就能明白，这两个问题本质上都是“缓冲区管理不当”导致的。
4.6 避坑指南：我曾经犯过的错
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路。
- 我曾经以为PFC的阈值设得越低越好。结果呢？缓冲区还没用多少就开始发PAUSE，导致频繁的流控，吞吐量反而下降了。后来我学乖了，阈值要根据实际业务流量动态调整。
- 我曾经忽略了PFC帧的处理优先级。在芯片设计时，PFC帧的处理优先级应该高于普通数据帧。否则，当网络拥塞时，PFC帧可能被堵在队列里，根本发不出去。
- 我曾经没有做PFC风暴的防护。结果就是前面说的，一个端口的拥塞扩散到了整个网络。现在我的设计里，一定会加上PFC Watchdog和跳数限制。
我的建议： 在芯片设计阶段，就把PFC死锁和风暴的防护机制做进去。不要等到出了问题再打补丁。硬件层面的防护，比软件层面的补救要可靠得多。
好了，关于PFC死锁和风暴，今天就聊这么多。记住一句话：PFC是把双刃剑，用好了是利器，用不好是灾难。希望我的经验能帮你少踩几个坑。
公众号:蓝海资料掘金营，微信deep3321