对比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 等，需要进一步了解和完善。

（编辑：衡阳站长网）

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