默认情况下，SparkStremaing根据Receiver以生产者生产数据的速度来接收数据，但是在工作状态下， 实际计算一个批次数据的时间一般要大于Streaming应用设置的批处理间隔。这就意味着Spark Streaming处理数据的速度要小于数据接收的速度， 数据处理能力低，导致数据全部堆积在内存中，进一步导致Receiver所在的Executor会发生内存溢出的问题。 同为优秀的大数据实时处理框架，这个问题和类比于Storm的雪崩问题，Storm中若是Spout，或者是其他上游的Bolt发送数据的速度过快，而下游Bolt因为并行度，或者是业务逻辑较为复杂， 就会导致数据堆积到内存中，进而引发雪崩的问题。Storm解决这个问题，有两种思路。第一种，控制上游发送数据的速度topology.max.spout.pending，比如说内存中未处理的Tuple(Storm中的数据处理单位，类似于kafka中的message)达到10000条的时候，堵塞发送线程，停止发送，直到内存中的数据小于我们设置的阈值；第二种思路，就是提高下游处理数据的速度， 提高并行度， 设置下excutor的数目。其实还有第三种思路，即当内存中的数据达到一定阈值后，将其写入Disk中。 Spark Streaming的解决思路和Storm的解决思路是一样的，但是比Storm更为灵活。因为Storm设置上游发送数据的Tuple数目，当消费者消费数据能力很大的时候，会造成资源利用率下降等问题。为了更好的协调数据接收速率与资源处理能力，Spark Streaming可以动态控制数据接收速率来适配集群数据处理能力。 Spark Streaming Backpressure: 根据JobScheduler反馈作业的执行信息来动态调整Receiver数据接收率。通过属性“spark.streaming.backpressure.enabled”来控制是否启用backpressure机制，默认值false，即不启用。
在原架构的基础上加上一个新的组件RateController,这个组件负责监听“OnBatchCompleted”事件，然后从中抽取processingDelay 及schedulingDelay信息. Estimator依据这些信息估算出最大处理速度（rate），最后由基于Receiver的Input Stream将rate通过ReceiverTracker与ReceiverSupervisorImpl转发给BlockGenerator（继承自RateLimiter）.
