我一直在学习storm和samza，以便了解流处理引擎是如何工作的，并意识到它们都是独立的应用程序，为了处理事件，我需要将其添加到一个队列中，该队列也连接到流处理引擎。这意味着我需要将事件添加到一个队列（这也是一个独立的应用程序，比方说kafka），storm将从队列中选取事件并在一个工作进程中处理它。如果我有多个螺栓，每个螺栓将由不同的工作进程处理(这是我不太明白的一件事，我看到一个公司在生产中使用了20多个螺栓，每个事件在螺栓之间以特定的路径转移）
但是我真的不明白为什么我需要这么复杂的系统。这些进程涉及太多的io操作（my program->queue->storm->bolt），这使得控制和调试它们变得更加困难。
相反，如果我是从web服务器收集数据，为什么不使用同一个节点进行事件处理呢？这些操作已经由我用于web服务器的负载均衡器分布在节点上。我可以在相同的jvm示例上创建执行器，并将事件从web服务器异步发送到执行器，而不涉及任何额外的io请求。我还可以监视web服务器中的执行器，并确保执行器处理了事件（至少一次或正好一次处理保证）。通过这种方式，管理我的应用程序会容易得多，而且由于不需要太多io操作，因此与通过网络将数据发送到另一个节点（也不可靠）并在该节点中处理数据的其他方式相比，它会更快。
很可能我在这里遗漏了一些东西，因为我知道很多公司都在积极使用storm，我认识的很多人推荐storm或其他流处理引擎进行实时事件处理，但我就是不明白。
2条答案
按热度按时间s4n0splo1#
您认为通过网络发送数据将消耗总处理时间中的更多时间是正确的。然而，创建这些框架（storm、spark、samza、flink）是为了处理大量可能不适合一台计算机内存的数据。因此，如果我们使用多台计算机来处理数据，我们就可以实现并行性。接下来是关于网络延迟的问题。对！这是一个值得权衡的问题。开发人员必须知道他们正在实现在并行框架中部署的程序。他们构建应用程序的方式也会影响通过网络传输的数据量。
eni9jsuy2#
我的理解是，使用像storm这样的框架的目的是从应用程序/web服务器上卸载繁重的处理（无论是cpu受限的、i/o受限的还是两者兼而有之的），并保持它们的响应性。
考虑到每个应用服务器可能必须服务于大量并发请求，而不是所有请求都与流处理有关。如果应用程序服务器已经在处理大量的事件，那么它可能会成为较轻请求的瓶颈，因为服务器资源（如cpu使用率、内存、磁盘争用等）已经与较重的处理请求相关联。
如果您需要面对的实际负载没有那么重，或者可以简单地通过添加app server示例来处理，那么当然，复杂化您的体系结构/拓扑结构是没有意义的，这实际上可能会降低整个过程的速度。这实际上取决于您的性能和负载要求，以及您可以在这个问题上投入多少（虚拟）硬件。和往常一样，基于负载需求的基准测试将有助于决定要走哪条路。