对比Flink与Storm性能，分布式实时计算框架该这样选

由②、⑧的测试功效可以看出，Storm QPS 靠近吞吐时耽误(含 Kafka 读写时刻)中位数约 100 毫秒，99 线约 700 毫秒，Flink 中位数约 50 毫秒，99 线约 300 毫秒。Flink 在满吞吐时的耽误约为 Storm 的一半，且跟着 QPS 逐渐增大，Flink 在耽误上的上风开始浮现出来。

综上可得，Flink 框架自己机能优于 Storm。

2、伟大用户逻辑对框架差此外减弱

比拟①和③、②和④的测试功效可以发明，单个 Bolt Sleep 时长到达 1 毫秒时，Flink 的耽误仍低于 Storm，但吞吐上风已根基无法浮现。

因此，用户逻辑越伟大，自己耗时越长，针对该逻辑的测试浮现出来的框架的差别越小。

3、差异动静投递语义的差别

由⑥、⑦、⑨、⑩的测试功效可以看出，Flink Exactly Once 的吞吐较 At Least Once 而言降落 6.3%，耽误差别不大;Storm At Most Once 语义下的吞吐较 At Least Once 晋升 16.8%，耽误稍有降落。

因为 Storm 会对每条动静举办 ACK，Flink 是基于一批动静做的搜查点，差异的实现道理导致两者在 At Least Once 语义的耗费差别较大，从而影响了机能。而 Flink 实现 Exactly Once 语义仅增进了对齐操纵，因此在算子并发量不大、没有呈现慢节点的环境下对 Flink 机能的影响不大。Storm At Most Once 语义下的机能如故低于 Flink。

4、Flink 状态存储后端选择

Flink 提供了内存、文件体系、RocksDB 三种 StateBackends，团结⑪、⑫的测试功效，三者的对好比下：

5、保举行使 Flink 的场景

综合上述测试功效，以下及时计较场景提议思量行使 Flink 框架举办计较：

要求动静投递语义为 Exactly Once的场景;

数据量较大，要求高吞吐低耽误的场景;

必要举办状态打点或窗口统计的场景。

七、瞻望

本次测试中另有一些内容没有举办越发深入的测试，有待后续测试增补。譬喻：

Exactly Once 在并发量增大的时辰是否吞吐会明明降落?

用户耗时到 1ms 时框架的差别已经不再明明(Thread.sleep() 的精度只能到毫秒)，用户耗时在什么范畴内 Flink 的上风依然能浮现出来?

本次测试仅调查了吞吐量和耽误两项指标，对付体系的靠得住性、可扩展性等重要的机能指标没有在统计数据层面举办存眷，有待后续增补。

Flink 行使 RocksDBStateBackend 时的吞吐较低，有待进一步试探和优化。

关于 Flink 的更高级 API，如 Table API & SQL 及 CEP 等，必要进一步相识和完美。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!