用户您好!请先登录!

背压(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 出现的几率罢了。*注:它们并不是专门用来降低生产速度的,只是可以这么用。

 

行走的code

要发表评论,您必须先登录