相辅相成地，由于「back pressure」被国内翻译为了「背压」，那么这个概念对于国内的程序员来说就更加难懂了，很多人对此或多或少加了一些自己的猜测：「背压？来自背后的压力？是说上游给下游的压力太大了吗？」

其实程序开发中的 Backpressure ，只是一种和工程上的 back pressure 相似的概念，我在这里再重复一遍：在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure 出现。需要强调的是：这句话的重点不在于「上游生产速度大于下游消费速度」，而在于「Buffer 溢出」。

Backpressure 和 Buffer 是一对相生共存的概念，只有设置了 Buffer，才有 Backpressure 出现；只要设置了 Buffer，一定存在出现 Backpressure 的风险。

不懂？我举个实际的例子。

例如你是开发服务器后端的，有一个 Socket 不断地接收来自用户的 http 请求来把用户需要的网页返回给用户。你的服务器所能承受的同时访问用户数是有上限的吧？比如说，你的服务器主机的处理器和内存情况决定了，它最多只能承受 5000~6000 个用户同时访问，再多的话服务器就有当掉的风险了。那么你决定：把用户数上限设置为 5000，当超出 5000 用户数的时候，再有新的访问就把它丢弃或者拒绝。那么对于这个案例，5000 就是你对于用户访问数设置的 Buffer；第 5001 个用户的访问，就叫做造成了 Backpressure 的产生；而你的「丢弃或拒绝」的行为，就是对于 Backpressure 的处理。

我来多问几个问题来把事情说得更加透彻一点。

为什么要设置 Buffer？

因为下游消费速度小于上游生产速度（对用户访问的处理速度小于新访问的出现速度）。

为什么要丢弃 Backpressure 出现时的新事件？

1. 因为处理不过来（本来就是因为处理不过来，所以才设置了 Buffer 的）
2. 因为事件可丢弃。

有人说了，卧槽卧槽要死要死，你敢说用户的请求可以丢弃？打你哦。

是的，就是可以丢弃。由于消费速度可能会小于生产速度，所以才设置了 Buffer；而由于一些外部条件的限制（例如主机内存大小），所以 Buffer 需要有上限；而当 Backpressure 出现时，你其实已经在面临「要么丢弃新事件，要么系统崩溃」的选择。所以说是选择，其实根本没得选，只能选择丢弃新事件。

所以明白了吗？

生产速度大于消费速度，所以需要 Buffer；

外部条件有限制，所以 Buffer 需要有上限；

Buffer 达到上限这个现象，有一个简化的等价词叫做 Backpressure；

Backpressure 的出现其实是一种危险边界，唯一的选择是丢弃新事件。

这就是 Backpressure 的本质。

再给个实用性的总结：

永远不要用「上游生产速度是否大于下游消费速度」来判断你的某个模块是否需要 Backpressure 的支持，因为现实场景是不可预估的，生产速度总是有一定的可能会大于下游消费的速度，所以 Buffer 是永远需要的。再所以：

1. 只要你的上游生产速度不会快到把系统搞崩溃，那么不用设置 Buffer 上限（从而也就不用考虑 Backpressure），随它去吧。例：按钮点击事件与处理点击 -> 就算这个事件处理很慢，就算这个用户的手点抽筋了，他能点多快？
2. 只有上游生产速度可能会快到把系统搞崩溃，并且事件是可以丢弃的，才需要设置 Buffer 上限。当 Buffer 有上限的时候，Backpressure 也就存在了出现的可能。一旦 Backpressure 出现，只能选择丢弃，只是具体的丢弃策略可能不同（全部丢弃、只保留最新的一个而丢弃其余的等等，但丢弃是不变的基本原则）。例：前面提到的服务端处理用户请求。
3. 如果上游生产速度可能会快到把系统搞崩溃，而事件也不可丢弃，怎么办？这个时候，你就要修改程序的设计了：修改代码设计来规避风险，或者修改软件设计、通过让步的方式来从根源上避免问题发生。总之，这已经不是 Buffer 或者 Backpressure 能解决的问题了。

总结：Backpressure 指的是在 Buffer 有上限的系统中，Buffer 溢出的现象；它的应对措施只有一个：丢弃新事件。

Backpressure 只是一种现象，而不是一种机制

原文链接：https://www.zhihu.com/question/49618581/answer/237078934