如何形象的描述反应式编程中的背压(Backpressure)机制？
[TOC]
按照https://github.com/ReactiveX/RxJava/wiki/Backpressure的描述和人讲，大多数人很难听懂。特别是Throttling、throttleLast、throttleFirst、debounce等概念。
首先，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 出现时的新事件？
- 因为处理不过来（本来就是因为处理不过来，所以才设置了 Buffer 的）
- 因为事件可丢弃。
有人说了，卧槽卧槽要死要死，你敢说用户的请求可以丢弃？打你哦。
是的，就是可以丢弃。由于消费速度可能会小于生产速度，所以才设置了 Buffer；而由于一些外部条件的限制（例如主机内存大小），所以 Buffer 需要有上限；而当 Backpressure 出现时，你其实已经在面临「要么丢弃新事件，要么系统崩溃」的选择。所以说是选择，其实根本没得选，只能选择丢弃新事件。
所以明白了吗？
生产速度大于消费速度，所以需要 Buffer；
外部条件有限制，所以 Buffer 需要有上限；
Buffer 达到上限这个现象，有一个简化的等价词叫做 Backpressure；
Backpressure 的出现其实是一种危险边界，唯一的选择是丢弃新事件。
这就是 Backpressure 的本质。
再给个实用性的总结：
永远不要用「上游生产速度是否大于下游消费速度」来判断你的某个模块是否需要 Backpressure 的支持，因为现实场景是不可预估的，生产速度总是有一定的可能会大于下游消费的速度，所以 Buffer 是永远需要的。再所以：
- 只要你的上游生产速度不会快到把系统搞崩溃，那么不用设置 Buffer 上限（从而也就不用考虑 Backpressure），随它去吧。例：按钮点击事件与处理点击 -> 就算这个事件处理很慢，就算这个用户的手点抽筋了，他能点多快？
- 只有上游生产速度可能会快到把系统搞崩溃，并且事件是可以丢弃的，才需要设置 Buffer 上限。当 Buffer 有上限的时候，Backpressure 也就存在了出现的可能。一旦 Backpressure 出现，只能选择丢弃，只是具体的丢弃策略可能不同（全部丢弃、只保留最新的一个而丢弃其余的等等，但丢弃是不变的基本原则）。例：前面提到的服务端处理用户请求。
- 如果上游生产速度可能会快到把系统搞崩溃，而事件也不可丢弃，怎么办？这个时候，你就要修改程序的设计了：修改代码设计来规避风险，或者修改软件设计、通过让步的方式来从根源上避免问题发生。总之，这已经不是 Buffer 或者 Backpressure 能解决的问题了。
总结：Backpressure 指的是在 Buffer 有上限的系统中，Buffer 溢出的现象；它的应对措施只有一个：丢弃新事件。
Backpressure 只是一种现象，而不是一种机制；至于你说的 throttleFirst、debounce ，更不是某个机制中的一环，它们只是可以通过人为过滤的方式来降低生产速度，从而降低 Backpressure 出现的几率罢了。*注：它们并不是专门用来降低生产速度的，只是可以这么用。
