【问题标题】:Build flexible publish/subscribe pattern with AWS Services使用 AWS 服务构建灵活的发布/订阅模式
【发布时间】:2013-11-24 20:51:23
【问题描述】:
我想在 amazon beanstalk 上的多个应用程序实例之间同步消息。
每个实例都必须能够在不知道它们的情况下向所有其他实例发送消息。
所以我想我用 SNS 和 SQS 构建了一个发布/订阅模式。
当一个新的应用程序实例启动时,它会创建一个新的 SQS 队列并订阅该主题。
到目前为止,一切都很好。但是如果自动扩缩器关闭了一个实例呢?
是否有可能捕获关闭事件?
或者您对其他实现有什么想法?
【问题讨论】:
标签:
amazon-web-services
amazon-sqs
autoscaling
amazon-sns
【解决方案1】:
您听起来好像可以通过现有指标很好地服务,您可以通过CloudWatch 设置警报,或通过创建自己的custom metrics。例如,每个 EC2 实例都有几个指标来监控重复出现的Status Checks。您可以定义将根据订阅者状态向订阅者发送通知的警报。一个状态检查失败超过 X 分钟的实例可能值得调查...如果您有应用程序监控警报,这可能会自动发生。
如果这对您来说还不够狭窄,我建议您查看自定义指标。您可以创建自己的指标和警报以(例如)按实例 ping 您的应用程序,以确保它们在同步消息之前响应。警报具有三种状态:“正常”、“警报”和“数据不足”,您可以收听并做出适当的响应。例如,如果您的指标在与应用程序相同的实例上轮询并且该实例出现故障,您将开始收到“数据不足”消息。
以前,自定义指标作为一个简单的应用程序监视器对我很有帮助...如果我可以经常 ping 我的应用程序,则报告 1 或 0。 ping 失败时发送通知,数据不足时发送通知。效果很好。
【解决方案2】:
这篇文章很旧,但我刚刚遇到它并且本周遇到了类似的问题 - 由于该帖子仍未标记为已接受,我试一试。
我看到了两种解决方案:
1) 如果消息的保留时间长于您要检查“未使用”队列的时间:您可以使用 API 检索所有队列的列表并检查ApproximateNumberOfMessages。如果它大约是指定的阈值,您可以假设队列已死,您可以将其删除。要么确保在给定时间段内始终发送指定数量的消息,要么您需要定义一种“保持活动”消息,其目标只是将死队列填充到您的阈值。
2) 如果可以检测到有多少/哪些节点正在运行 - 例如让每个节点定期(短期,在每个节点上执行)使用其 nodeName / lastActivity 时间戳更新数据库条目,然后定期(长期,仅在一个节点上执行)检索此列表 -> 遍历每个队列(由 API 检索)并检查对应的节点是否还处于活动状态,如果没有,则删除队列。