标签：而不是 程序 处理器 方式 后端 共存 react 为什么 主机
首先，Backpressure并不是响应式编程（Reactive Programming）独有的，编程中的Backpressure这个概念源自流体工程中的Backpressure。其次，Backpressure 并不是一种「机制」，也不是一种「策略」，而是一种现象，流体在管道运输中，流体由于管道突然变细、急弯等原因导致在某处出现了自下游向上游的逆向压力，这种情况称作「back pressure」。这是一个很直观的词：向后的、往回的压力——back pressure。可是，国内的流体工程界对这个词的正式翻译是「背压」，把「back」翻译成了「背」，着实有点让人无力吐槽。在编程中，数据流从上游生产者向下游消费者传输的过程中，由于上游的生产速度大于下游的消费速度，导致下游的Buffer溢出，这种现象就叫做Backpressure。
其实程序开发中的Backpressure，只是一种和工程上的back pressure相似的概念，我在这里再重复一遍：在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的Buffer溢出，这种现象就叫做Backpressure出现。需要强调的是：这句话的重点不在于「上游生产速度大于下游消费速度」，而在于Buffer溢出。
Backpressure和Buffer是一对相生共存的概念，只有设置了Buffer，才有Backpressure出现；只要设置了Buffer，一定存在出现Backpressure的风险。
例如：你是开发服务器后端的，有一个 Socket 不断地接收来自用户的 http 请求来把用户需要的网页返回给用户。你的服务器所能承受的同时访问用户数是有上限的吧？比如说，你的服务器主机的处理器和内存情况决定了，
它最多只能承受5000~6000个用户同时访问，再多的话服务器就有当掉的风险了。那么你决定：把用户数上限设置为5000，当超出5000用户数的时候，再有新的访问就把它丢弃或者拒绝。那么对于这个案例5000就是你对于用户访问数设置的Buffer；
第5001个用户的访问，就叫做造成了 Backpressure 的产生；而你的「丢弃或拒绝」的行为，就是对于Backpressure的处理。
我来多问几个问题来把事情说得更加透彻一点。
1. 为什么要设置Buffer？——因为下游消费速度小于上游生产速度（对用户访问的处理速度小于新访问的出现速度）。
2. 为什么要丢弃Backpressure出现时的新事件？——因为处理不过来（本来就是因为处理不过来，所以才设置了Buffer的）同时也因为事件可丢弃，有人会说了，卧槽你敢说用户的请求可以丢弃？打你哦。
是的，必须要允许丢弃，由于消费速度可能会小于生产速度，所以才设置了Buffer；而由于一些外部条件的限制（例如主机内存大小），所以Buffer需要有上限；而当Backpressure出现时，你其实已经在面临「要么丢弃新事件，要么系统崩溃」的选择。
虽说是选择，其实根本没得选，只能选择丢弃新事件。
所以明白了吗？
1. 生产速度大于消费速度，所以需要Buffer；
2. 外部条件有限制，所以Buffer需要有上限；
3. Buffer达到上限这个现象，有一个简化的等价词叫做Backpressure；
Backpressure的出现时，应用本身其实是处在危险边界，唯一的选择是丢弃新事件。
这就是Backpressure的本质。永远不要用「上游生产速度是否大于下游消费速度」来判断你的某个模块是否需要Backpressure的支持，因为现实场景是不可预估的，生产速度总是有一定的可能会大于下游消费的速度，所以Buffer是永远需要的。
再所以：只要你的上游生产速度不会快到把系统搞崩溃，那么不用设置Buffer上限（从而也就不用考虑Backpressure），随它去吧。例：按钮点击事件与处理点击 -> 就算这个事件处理很慢，就算这个用户的手点抽筋了，他能点多快？
只有上游生产速度可能会快到把系统搞崩溃，并且事件是可以丢弃的，才需要设置Buffer上限。当Buffer有上限的时候，Backpressure也就存在了出现的可能。一旦Backpressure出现，只能选择丢弃，只是具体的丢弃策略可能不同（全部丢弃、只保留最新的一个而丢弃其余的等等，但丢弃是不变的基本原则）。例：前面提到的服务端处理用户请求。
如果上游生产速度可能会快到把系统搞崩溃，而事件也不可丢弃，怎么办？这个时候，你就要修改程序的设计了：修改代码设计来规避风险，或者修改软件设计、通过让步的方式来从根源上避免问题发生。总之，这已经不是Buffer或者Backpressure能解决的问题了。
Backpressure指的是在Buffer有上限的系统中，Buffer溢出的现象；它的应对措施只有一个：丢弃新事件。
Backpressure只是一种现象，而不是一种机制；至于你说的throttleFirst、debounce，更不是某个机制中的一环，它们只是可以通过人为过滤的方式来降低生产速度，从而降低Backpressure出现的几率罢了。*注：它们并不是专门用来降低生产速度的，只是可以这么用。
标签：而不是 程序 处理器 方式 后端 共存 react 为什么 主机
原文地址：https://www.cnblogs.com/JaxYoun/p/12401491.html
