我是 Storm 的新手,一直在探索其功能以满足我们的 CEP 要求。我偶然发现的不同示例将 spouts 实现为来自消息代理数据库的轮询服务。如何实现基于推送的 spout,即在 spout 内运行的 Thrift 服务器?我应该如何让我的客户知道我的 spout 在哪里运行,以便他们可以在上面推送数据?
4 回答
Spout 旨在进行轮询,因此您无法向它们推送。然而,许多人所做的是使用 Redis、Thrift 或 Kafka 作为服务,您可以将消息推送到这些服务,然后您的 spout 可以轮询它们。
您对 spout 运行的位置和时间的控制是有限的,因此让外部进程直接与 spout 通信有点麻烦。这当然是可能的,但这不是最简单的解决方案。
标准解决方案是将消息推送到某个外部消息队列,并让您的 spout 轮询该消息队列。
在storm-contrib中有一些spout 的实现可以为常用的消息队列服务(例如Kafka、Kestrel 和JMS)执行此操作
一般来说,我对 Storm 或 Kafka/Kestrel 或 CEP 没有太多经验,但我正在寻找类似的解决方案 - 推送到 Storm spout。在事件源和 Storm 集群之间使用负载均衡器怎么样?对于我将 Syslog 消息从 rsyslog 推送到 Storm 的用例,负载均衡器可以跟踪哪些 Storm 节点正在运行侦听 spout,哪些节点已关闭,还可以根据不同的参数分配传入负载。我不太倾向于在源和 spout 之间引入另一层,例如消息总线。
编辑:我阅读了您的博客并总结一下,如果监听喷嘴的唯一问题是来源如何找到它,那么消息总线可能是错误的答案。有更简单/更好的解决方案可以根据简单的网络状态或更高的应用程序级别逻辑在接收器处引导网络流量。但是,是的,如果您想使用所有附加的消息总线功能,那么显然 Kafka/Kestrel 将是不错的选择。
这不是 Storm 的典型用法,显然你不能将同一台机器上的多个 spout 实例绑定到同一个端口。在分布式设置中,最好将 API 的当前 IP 地址和端口存储到 ZooKeeper,然后将请求转发到您的 API 的平衡器。
这是一个在 Storm 上使用简单 REST API 的项目: