背景
目前流计算正在势头上，那么，什么是流计算呢？流计算可以简单地理解成对数据流的处理，但与传统的数据仓库、ETL相比，流计算更强调计算数据流和低时延，数据从数据源头（如消息队列）源源不断地写入，然后预先设计好的逻辑计算会对数据进行处理，最后将结果写到结果流（例如数据库、消息队列等）。
目前大多数公司都有离线计算和实时计算两块业务，离线计算通常使用批处理，将一大块的数据每天定时执行，这种主要适用于数据量大，实时性要求不高的场景。相比于批处理，流计算的适用于逻辑简单，实时性要求高的场景，天然地很合适增量数据的计算。
就像DC里的海王，前期弱成狗，后期超神反杀，靠的是什么，就是海王三叉戟，而Flink实际上也是企业流计算业务中的神器，有了它可以迅速高效地解决问题。
对比
市场上有许多针对批处理和流计算开源工具，例如批处理有MapReduce、Hadoop，流计算有Storm、Kafka、Samza等，而同时兼顾的框架有Spark和Flink，这也是这两者经常被用来比较的原因。
Spark的技术理念是基于批处理来模拟流的计算。而Flink则完全相反，它采用的是基于流计算来模拟批计算。Spark把处理放在内存里，速度大大快于MapReduce和Hadoop，因此这也是Spark出来后迅速流行起来的原因。而Flink的设计就是针对流计算，提供更加低延时和完善的机制，这块恰恰是Spark的短板，而且当数据是有界时就相当于批处理，逻辑清晰干净。
阿里巴巴目前采用的就是Flink框架，因为批处理和流计算的业务代码逻辑基本是一致的，没必要分开两套来处理，而且Flink也非常符合电商许多实时化的场景，更符合未来流计算发展的趋势。
特性
高吞吐&低延迟
在以往的框架里要么满足高吞吐，要么满足低延迟，而Flink能同时兼顾两者，延迟基本都在毫秒级别，也是Flink的一大优势。
支持乱序事件
由于网络等外部原因，源数据进入Flink的顺序有可能是乱的，Flink会记录事件的创建时间，通过watermark和window机制，通过这些机制可以解决在一定时间内的事件乱序问题，重新排序。
一致性语义
Flink支持exactly-once语义，这是一个很重要的feature，开发者可以放心地使用而不用担心消息被多次消费。Flink是通过checkpoint的机制实现，checkpoint是指会定时把成功的状态快照记录下来，当发现异常时，会重启节点并恢复到最近成功的checkpoint，并在源头重新回放数据流。
反压
流计算在流量大的场景例如大促等会出现反压的问题，反压是指目标节点的处理速度不够快，导致数据堆压在源头节点。这问题在Spark Streaming和Storm都会出现，而Flink是天然能解决这个问题，因为Flink的接收节点速率和处理节点速率是匹配的，因此只会处理多少来多少数据。
总结
Flink作为未来的流计算的趋势，是简化流计算逻辑的有利利器，如果开发者想做技术选型可以着重考虑Flink。据我所知Flink所在的公司已被阿里巴巴收购，将来阿里必将更多地赋能Flink，所以是一个很有前景的框架。