Flink的优势和特点：
一、同时支持高吞吐、低延迟、高性能
Flink是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。Apache Spark也只能兼顾高吞吐和高性能特点，主要是因为Spark Streaming流式计算中无法做到低延迟保障；而流式计算框架Apache Storm只能支持低延迟和高性能特性，但是无法满足高吞吐的要求。而满足高吞吐、低延迟、高性能这三个目标对分布式流式计算框架来说是非常重要的。
二、支持事件时间（Event Time）概念
在流式计算领域中，窗口计算的地位举足轻重，但目前大多数框架窗口计算采用的都是系统时间（Process Time），也是事件传输到计算框架处理时，系统主机的当前时间。Flink能够支持基于事件时间（Event Time)语义进行窗口计算，也就是使用事件产生的时间，这种基于事件驱动的机制使得事件即使乱序到达，流系统也能够计算出精确的结果，保证了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响。
三、支持有状态计算
Flink在1.4版本中实现了状态管理，所谓状态就是在流式计算过程中将算子的中间结果数据保存在内存或文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果，计算当前的结果，从而无需每次都基于全部的原始数据来统计结果，这种方式极大地提升了系统的性能，并降低了数据计算过程的资源消耗。对于数据量大且运算逻辑非常复杂的流式计算场景，有状态计算发挥了非常重要的作用。
四、支持高度灵活的窗口（Window）操作
在流处理应用中，数据是连续不断的，需要通过窗口的方式对流数据进行一定范围的聚合计算，例如统计在过去1分钟内有多少用户点击某一网页，在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口的数据进行再计算。
FLink将窗口划分为基于TIme、Count、Session，以及Data-Driven等类型的窗口操作，窗口可以用灵活的出发条件定制化来达到对复杂的流传输模式的支持，用户可以定义不同的窗口出发机制来满足不同的需求。
五、基于轻量级分布式快照（CheckPoint）实现的容错
Flink能够分布式运行在上千个节点上，将一个大型计算任务的流程拆解成晓得计算过程，然后将task分布到并行节点上处理。在任务执行过程中，能够自动发现事件处理过程中的错误而导致数据不一致的问题，比如：节点宕机、网络传输问题，或是由于用户升级或修复问题而导致计算服务重启等。在这些情况下，通过基于分布式快照技术的Checkpoints，将执行过程中的状态信息进行持久化恢复，以确保数据在处理过程中的一致性（Exactly-Once）。
六、基于JVM实现独立的内存管理
内存管理是所有计算框架需要重点考虑的部分，尤其对于计算量比较大的计算场景，数据在内存中该如何进行管理显得至关重要。针对内存管理，FLink实现了自身管理内存的机制，尽可能减少JVM GC对系统的影响。另外，FLink通过序列化/反序列化方法将所有的数据对象转换成二进制在内存中存储，降低数据存储的大小的同事，能够更加有效地对内存空间进行利用，降低GC带来的性能下降或任务异常的风险，因此Flink较其他分布式处理的框架会显得更加稳定，不会因为JVM GC等问题而影响整个应用的运行
七、Save Points（保存点）
对于7*24小时运行的流式应用，数据源源不断的接入，在一段时间内应用的终止有可能导致数据的丢失或者极端结果的不准确，例如进行集群版本的升级、停机运维操作等操作。值得一提的是，FLink通过Save Points技术将任务执行的快照保存在存储介质上，当任务重启的时候可以直接从事先保存的Save Points恢复原有的计算状态，是的任务继续按照停机之前的状态运行，Save Points技术可以烫用户更好地管理和运维实时流式应用。
几种流式框架的对比：
| 产品 | 模型 | API | 保证次数 | 容错机制 | 状态管理 | 延时 | 吞吐量 |
| Storm | Native（数据进入立即处理） | 组合式（基础API） | At-least-once（至少一次） | Record ACK（ACK机制） | 无 | 低 | 低 |
| Trident | Mico-Batching（划分为小批次处理） | 组合式 | Exactly-once（仅一次） | Recoed ACK | 基于操作（每次操作有一个状态） | 中等 | 中等 |
| Spark Streaming | Mcio-Batching | 声明式（提供封装后的高阶函数，如count函数） | Exactly-once | RDD CheckPoint（基于RDD做CheckPoint） | 基于DStream | 中等 | 高 |
| Flink | Native | 声明式 | Exactly-once | CheckPoint（Flink的一种快照） | 基于操作 | 低 | 高 |
- 模型：Storm和Flink都是真正的一条一条处理数据；而Trident（Storm的封装框架）和Spark Streaming其实都是小批次处理，一次处理一批数据（小批量）
- API：Storm和Trident都使用基础API进行开发，比如实现一个简单的sum求和操作；而Spark Streaming和Flink中都提供封装后的高阶函数，可以直接拿来使用，这样就比较方便了。
- 保证次数：在数据处理方面，Storm可以实现至少处理一次，但不能保证仅处理一次，这样就会导致数据重复处理问题，所以针对计数类的需求，可能会产生一些误会；Trident通过事务可以保证对数据实现仅一次的处理，Spark Streaming和Flink也是如此；
- 容错机制：Storm和Trident可以通过ACK机制实现数据的容错机制，而Spark Streaming和Flink可以通过CheckPoint机制实现容错机制；
- 状态管理：Storm中没有实现状态管理，Spark Streaming实现了基于DStream的状态管理，而Trident和Flink实现了基于操作的状态管理；
- 延时：表示数据处理的延时情况，因此Storm和Flink接受到一条数据就处理一条数据，其数据处理的延时性是很低的；而Trident和Spark Streaming都是小型批处理，他们数据处理的延时性相对会偏高。
- 吞吐量：Storm的吞吐量其实也不低，只是相对于其他几个框架较低；Trident属于中等；Spark Streaming和Flink的吞吐量是比较高的。