如何形象的描述反应式编程中的背压(Backpressure)机制？

按照https://github.com/ReactiveX/RxJava/wiki/Backpressure的描述和人讲，大多数人很难听懂。特别是Throttling、throttleLast、throttleFirst、debounce等概念。

目前网上大多数对 Backpressure 的解释都是错误的。如果你认为你对 Backpressure 「有一定的理解，但不太能讲清楚」，那么你很可能其实并没有理解它，因为 Backpressure 其实是一个非常简单的概念。

首先，Backpressure 并不是响应式编程（Reactive Programming，或者有的人喜欢按字直译为「反应式编程）独有的；其次，Backpressure 并不是一种「机制」，也不是一种「策略」。Backpressure 其实是一种现象：在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure 出现。

编程中的 Backpressure 这个概念源自工程概念中的 Backpressure：在管道运输中，气流或液流由于管道突然变细、急弯等原因导致由某处出现了下游向上游的逆向压力，这种情况称作[back pressure」。这是一个很直观的词：向后的、往回的压力——back pressure。可是，国内的热力工程界对这个词的正式翻译是「背压」，把「back」翻译成了「背」，着实有点让人无力吐槽。

相辅相成地，由于「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 只是一种现象，而不是一种机制；至于你说的 throttleFirst、debounce ，更不是某个机制中的一环，它们只是可以通过人为过滤的方式来降低生产速度，从而降低 Backpressure 出现的几率罢了。*注：它们并不是专门用来降低生产速度的，只是可以这么用。