在spark流中，我们为近实时的微批处理设置了批间隔。在Flink (DataStream)或Storm中，流是实时的，所以我想没有这样的批处理间隔的概念。
在kafka中，消费者是拉动的，我想象Spark使用批处理间隔参数从kafka代理中拉动消息，那么Flink和Storm是如何做到的呢?我想象Flink和Storm在一个快速循环中拉出Kafka消息来形成实时流源，如果是这样，如果我将Spark批处理间隔设置得很小，比如100ms, 50ms甚至更小，我们在Spark Streaming和Flink或Storm之间有显著的差异吗?
同时，在Spark中，如果流数据很大，批处理间隔太小，我们可能会遇到有很多数据等待处理的情况，因此我们会看到outofmemory发生变化。这会发生在Flink或Storm中吗?
我已经实现了一个应用程序做主题到主题的转换，转换很容易，但源数据可能是巨大的(考虑到它是一个物联网应用程序)。我最初的实现是由react -kafka支持的，它在我独立的Scala/Akka应用程序中工作得很好。我没有实现要集群化的应用程序，因为如果我需要的话，Flink/Storm/Spark已经在那里了。然后我发现了Kafka Stream，对我来说，从客户端使用的角度来看，它类似于reactive-akka。所以，如果我在独立应用程序或微服务中使用Kafka流或响应式Kafka，我们是否需要担心客户端代码的可靠性/可用性?
你对微批处理和流处理的理解是正确的。你也是对的，这三个系统都使用Kafka提供的标准Java消费者来在无限循环中提取数据进行处理。
主要的区别是，Spark需要为它处理的每个微批调度一个新的作业。这种调度开销非常高，以至于Spark不能有效地处理非常低的批处理间隔，如100ms或50ms，因此小批处理的吞吐量下降。
Flink和Storm都是真正的流系统，因此在启动时都只部署一次作业(并且作业持续运行直到用户显式关闭)，因此它们可以处理每个单独的输入记录而没有开销和非常低的延迟。
此外，对于Flink, JVM主内存不是一个限制，因为Flink可以使用堆外内存，如果可用的主内存太小，也可以写入磁盘。(顺便说一句:Spark自项目Tungsten以来，也可以使用堆外内存，但它们可以在某种程度上溢出到磁盘-但与Flink AFAIK不同)。Storm，据我所知，两者都不做，并且仅限于JVM内存。
我不熟悉响应式Kafka。
对于Kafka Streams，它是一个完全容错、有状态的流处理库。它是为微服务开发而设计的(你不需要像Flink/Storm/Spark那样专门的处理集群)，但可以在任何地方以任何方式部署你的应用程序实例。只需启动更多实例即可扩展应用程序。查看文档了解更多细节:http://docs.confluent.io/current/streams/index.html (Confluent博客中也有关于Kafka Streams的有趣文章:http://www.confluent.io/blog/)