本文作者知秋，节选自《Java编程方法论：响应式Spring Reactor 3设计与实现》一书。 -------
流计算作业通常运行时间长，数据吞吐量大，且对时延较为敏感。但实际运行中，Flink 作业可能因为各种原因出现吞吐量抖动、延迟高、快照失败等突发情况，甚至发生崩溃和重启，影响输出数据的质量，甚至会导致线上业务中断，造成报表断崖、监控断点、数据错乱等严重后果。
从“流”的概念出发，并引入响应式流程规范，从而分析响应式编程中所包含的各个核心组件。
Scala是可伸缩语言(Scalable Language)的缩写，读作skah-lah， 于2004年1月20日发布了第一个公开版本。其实早在2001年，Martin Odersky就开始Scala的设计工作，Martin 是瑞士洛桑联邦理工大学（EPFL）计算机与通信科学学院的一名教授， Martin曾和Haskell 语言设计者之一 Philip Wadler合作，设计了一个原型系统GJ， 最终演变为 Java 泛型。Martin还曾受雇于 Sun 公司，编写了 javac 的参考编译器，这套系统后来
上面这段文字摘抄自 Akka 官网（akka.io），翻译成中文也就是：“Akka 是一个为 Java 和 Scala 构建高并发、分布式和弹性消息驱动应用程序的工具包”。而 Akka 具有的一切特性，其实都源自于一个用于处理并发计算问题的模型——Actor 模型。
一个流程中，有两个重要子任务：一是数据迁移，将kafka实时数据落Es，二是将kafka数据做窗口聚合落hbase，两个子任务接的是同一个Topic GroupId。上游Topic的 tps高峰达到5-6w。
一个流程中，有两个重要子任务：一是数据迁移，将kafka实时数据落Es，二是将kafka数据做窗口聚合落hbase，两个子任务接的是同一个Topic GroupId。上游 Topic 的 tps 高峰达到5-6w。
2020年和2021年分别写了很多篇类似的文章，这篇文章是关于Flink生产环境中遇到的各种问题的汇总。
为了应对高并发场景下到服务端编程需求，微软最先提出了一种异步编程到方案Reactive Programming，也就是反应式编程。
反压机制（BackPressure）被广泛应用到实时流处理系统中，流处理系统需要能优雅地处理反压（backpressure）问题。反压通常产生于这样的场景：短时负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或者遇到大促或秒杀活动导致流量陡增。反压如果不能得到正确的处理，可能会导致资源耗尽甚至系统崩溃。反压机制就是指系统能够自己检测到被阻塞的Operator，然后系统自适应地降低源头或者上游的发送速率。目前主流的流处理系统 Apache Storm、JStorm、Spark Streaming、S4、Apache Flink、Twitter Heron都采用反压机制解决这个问题，不过他们的实现各自不同。
来源: https://martinfowler.com/articles/patterns-of-distributed-systems/
作者 | 罗燕珊 Apache 基金会孵化器近日迎来新成员——Pekko ，但对于部分开发者来说，Pekko 应该不陌生。 事实上，Pekko 是 Akka 项目的一个分支。不久前， Akka 的许可证从 Apache 2 更改为 Business Source License 1.1，Pekko 作为新的分支从中拉出。根据介绍，Pekko 项目提供了一套工具和框架，涵盖了分布式并发系统的复杂问题空间。它旨在支持响应式宣言的设计原则，通过提供组件来有效地在服务器内扩展系统或跨多个服务器横向扩展，是高性能、
Akka 是一个开源的并发、分布式、基于消息驱动的框架，用于构建高可伸缩性、可靠性和并发性强的应用程序。它是基于 JVM（Java虚拟机）的，主要使用 Scala 编程语言开发，但也提供了 Java API，因此可以在 Java 和 Scala 中使用。
在之前的博文中，我们介绍了Flink的网络堆栈如何从高级抽象到低级细节。 此系列网络堆栈帖子中的第二篇博客文章扩展了这一知识，并讨论了监视与网络相关的指标，以识别诸如背压或吞吐量和延迟瓶颈等影响。 虽然这篇文章简要介绍了如何处理背压，但未来的帖子将进一步研究调整网络堆栈的主题。 如果您不熟悉网络堆栈，我们强烈建议先深入阅读网络堆栈然后继续。
我们在日常使用 ELK 链路的时候，经常会碰到一个问题，由于链路涉及的组件较多，一旦当其中某些组件出现问题，就会出现“事件风暴”，如果没有做好相关的告警或者资源管控，很可能会使链路发生崩溃。
英文 | I'm not feeling the async pressure 原作 | Armin Ronacher，2020.01.01 译者 | 豌豆花下猫@Python猫 声明 ：本翻译基于CC BY-NC-SA 4.0授权协议，内容略有改动，转载请保留原文出处，请勿用于商业或非法用途。
AI 前线导读：2018 年接近尾声，AI 前线策划了“解读 2018”年终技术盘点系列文章，希望能够给读者清晰地梳理出重要技术领域在这一年来的发展和变化。本文是实时流计算 2018 年终盘点，作者对实时流计算技术的发展现状进行了深入剖析，并对当前大火的各个主流实时流计算框架做了全面、客观的对比，同时对未来流计算可能的发展方向进行预测和展望。
故障可能发生在网络连接级别（进程之间的消息丢失或传递缓慢），也可能发生在进程级别（进程崩溃或运行缓慢），并且延迟始终不能与故障区分开。这意味着在错误地将活动过程怀疑为已死（产生假阳性）与延迟将无响应过程标记为已死之间进行权衡，这给了它怀疑的好处并期望它最终做出响应（产生假阴性）。
2017年的首篇文章，本次依旧带来一叶飘舟的开年之作，新的一年祝大家事业有成，爱情美满！
在 Pinterest，流数据处理支持广泛的实时用例。 近年来，由 Flink 提供支持的平台通过提供近乎实时的内容激活和指标报告，已被证明对业务具有巨大价值，并有可能在未来解锁更多用例。 然而，为了利用这种潜力，我们需要解决开发者速度的问题。
Stream 在 Node.js 中是一个被广泛应用的模块，流的两端可读流、可写流之间通过管道链接，通常写入磁盘速度是低于读取磁盘速度的，这样管道的两端就会产生压力差，就需要一种平衡的机制，使得平滑顺畅的从一个端流向另一个端。
对于响应式编程来说，响应式流是一种非阻塞、响应式、异步流处理、支持背压的技术标准，包括运行时环境（JVM和JavaScript）及网络协议。JDK 9发布的Flow API（java.util.concurrent.Flow）和响应式流规范呼应，成为响应式编程事实上的标准。
Reactive Streams Reactive Streams 是一个使用非阻塞背压机制的异步流处理标准。 back pressure（背压）是其中的关键概念。在异步模式中，消费者订阅生产者，从生产者那里获取数据，需要提供回调方法，当生产者产生新的可用数据后，就调用回调方法。当生产者发送数据的速度大于消费者处理的速度时，消费者就会抢占更多的资源来处理，并且有崩溃的可能。为了防止这种问题，需要一种机制，能让消费者通知生产者：生产速度太快了需要减速，然后生产者可以进行相应调整。这个机制就叫做背压。 背压可以
每个Android开发者，都是爱RxJava的,简洁线程切换和多网络请求合并，再配合Retrofit,简直是APP开发的福音。不知不觉，RxJava一路走来，已经更新到第三大版本了。不像RxJava 2对RxJava 1那么残忍，RxJava 3对RxJava 2的兼容性还是挺好的，目前并没有做出很大的更改。RxJava2到2020年12月31号不再提供支持，错误的会同时在2.x和3.x修复，但新功能只会在3.x上添加。
场景描述：如果看到任务的背压警告（如 High 级别），这意味着 生成数据的速度比下游算子消费的的速度快。以一个简单的 Source -> Sink 作业为例。如果能看到 Source 有警告，这意味着 Sink 消耗数据的速度比 Source 生成速度慢。Sink 正在向 Source 施加反压。
2015 年反应式流 (Reactive Stream) 规范诞生，定义了如下四个接口：
如果有关注我公众号文章的同学就会发现，最近我不定时转发了一些比较好的WebFlux的文章，因为我最近在学。
如果看到任务的背压警告（如 High 级别），这意味着 生成数据的速度比下游算子消费的的速度快。以一个简单的 Source -> Sink 作业为例。如果能看到 Source 有警告，这意味着 Sink 消耗数据的速度比 Source 生成速度慢。Sink 正在向 Source 施加反压。
奈飞公司在整个微服务架构体系处于行业领先地位，在其内部有一种自研的通信协议方式，以实现微服务架构下高性能的通信，他就是RSocket。同时在云原生概念盛行的今天，一种可以在service mesh下高性能通信的组件同样也是各个企业需要的，所以今天我们就聊聊RSocket吧。
响应式编程最重要的是解决生产者和消费者之间的关系。如果生产者产生的数据过大，而消费者消费不过来，就会压垮消费者。所以就需要有一个重要的概念——流控。
人们经常会问Flink是如何处理背压(backpressure)效应的。 答案很简单：Flink不使用任何复杂的机制，因为它不需要任何处理机制。它只凭借数据流引擎，就可以从容地应对背压。在这篇博文中，我们介绍一下背压。然后，我们深入了解 Flink 运行时如何在任务之间传送缓冲区中的数据，并展示流数传输自然双倍下降的背压机制(how streaming data shipping naturally doubles down as a backpressure mechanism)。 我们最终通过一个小实验展示了这一点。
其实 IO 也就是搬东西，包括网络的 IO、文件的 IO，如果数据量少，那么直接传送全部内容就行了，但如果内容特别多，一次性加载到内存会崩溃，而且速度也慢，这时候就可以一部分一部分的处理，这就是流的思想。
反应式编程的提出，是在分布式编程刚兴起不久。当时没有各种 PaaS 平台，而分布式系统中，常常出现一个节点出问题，导致整个系统瘫痪的情况。所以，反应式编程的思想是：不等不靠，即当有一个节点慢下来的时候，整个系统都放慢，以此来避免灾难性的后果。
首先，我们需要明确一下这几个名词出现的场景：分布式高并发环境。如果你的产品卖相不好，没人鸟它，那它就用不着这几个属性。不需要任何加成，低并发系统就能工作的很好。
RSocket是一种二进制的点对点通信协议，是一种新的网络通信第七层协议。旨在用于分布式应用程序中。从这个意义上讲，RSocket是HTTP等其他协议的替代方案。它是一种基于Reactive Streams规范具有异步，背压的双向，多路复用，断线重连，基于消息等特性。它由Facebook，Netifi和Pivotal等工程师开发，提供Java，JavaScript，C ++和Kotlin等实现。
在 Android 应用开发中，异步编程是不可避免的，而 Kotlin Flow 是一个强大的库，能够使异步操作更加优雅和易于管理。本文将深入探讨 Kotlin Flow 的使用方法，同时也会解析其背后的实现原理，帮助你更好地理解这一技术。
反应式编程在好几年前就已经出现了，它原理是基于反应式编宣言。但是，由于反应式编程推广速度比较缓慢，导致很多人现在对其不是很了解。
解决了 因被观察者发送事件速度 与 观察者接收事件速度 不匹配（一般是前者 快于 后者），从而导致观察者无法及时响应 / 处理所有 被观察者发送事件 的问题
转载自：Rxjava2入门教程五：Flowable背压支持——对Flowable最全面而详细的讲解
在讲flink的back pressure之前，我们先讲讲Spark Streaming的back pressure。Spark Streaming的back pressure出现的原因呢，我想大家应该都知道，是为了应对短期数据尖峰。Spark Streaming的back pressure是从spark 1.5以后引入的，在之前呢，只能通过限制最大消费速度（这个要人为压测预估），对于基于Receiver 形式，我们可以通过配置 spark.streaming.receiver.maxRate 参数来限制每个 receiver 每秒最大可以接收的记录的数据；对于 Direct Approach 的数据接收，我们可以通过配置 spark.streaming.kafka.maxRatePerPartition 参数来限制每次作业中每个 Kafka 分区最多读取的记录条数。
在Android领域，面试是展示个人技能和经验的重要场合。本文将围绕Android中的Flow相关技巧展开，深入分析高级疑难问题，帮助Android技术人员提升面试水平。
数据 生产者 的 生产效率 大于 数据 消费者 的 消费效率 , 就会产生 背压 ;
构建复杂程序的时候，通常会将系统拆解成若干功能，这些功能的之间的接口遵循一定的规范，以实现组合连接，共同完成复杂任务。例如管道运算符 | 。
浪尖一直觉得spark 的源码值得我们细细品读，帮助解决我们生产中的问题，可以学习大牛的编程思路，学习spark架构设计，学习scala及java编程，到处都是成长。但是，成长欠缺的地方可能是大家希望有个人做指导，那么点击阅读原文加入浪尖知识星球，已经和正在公布源码学习视频及文章。帮助大家在技术方面更进一步。
单个 TaskManager 上的缓冲区总数通常不需要配置。需要配置时请参阅配置网络缓冲区文档。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
