1

这是我要构建的模型: 无限主题(我知道 AWS 限制目前是 3000) 每个主题无限订阅者(AWS SNS 文档没有说明限制)

每个订户将有不同的时间表,他们希望接收 SMS 或电子邮件消息。

如果我有一个有 10 个订阅者的主题,其中 5 个想要早上消息,5 个想要晚上消息。日程表可以更改,并由管理员通过 Web 应用程序(使用 API)进行管理,因此每个日程表构建一个主题并不是理想的解决方案,并且这些变化会占用 3000 个主题中的很多。

4

1 回答 1

3

SNS 不支持发布到主题订阅者子集的能力,除了使用其 Android/iOS 推送通知功能时,它既不是电子邮件也不是 http 也不是短信,并且与 SNS 所做的一切都如此不同,我不是完全确定为什么亚马逊没有将其作为完全不同的产品进行营销。

目前,仅向 iOS、Kindle 和 Android 端点的推送通知支持直接寻址

http://aws.amazon.com/sns/faqs/#Does_SNS_support_direct_addressing_for_SMS_or_Email

单个主题的订阅者数量的记录限制为 10,000。这似乎是一个硬性限制;但是,每个帐户 3,000 个主题的限制显然不是硬性限制,因为有一个文档化的流程可以请求增加该限制。

3,000 个主题(每个主题有 10,000 个订阅者)和 10 个订阅者分布在 2 个或 3 个主题之间存在很大差距,但 SNS 似乎仍然不是您想要做的事情的正确平台——限制或无限制——因为每次将订阅者添加到主题时,他们都必须确认他们对该主题的订阅......因此,如果您的管理员为操纵主题订阅所做的任何事情仍会导致来自“AWS 通知”的确认消息被发送给每个订阅者Amazon SNS 要求他们在发送后续消息之前选择加入,如果订阅者想要更改他们的发送计划(这意味着将它们添加到新主题),则必须重复这个过程。您不能以编程方式跳过此步骤。

在 AWS 中,Simple Email Service似乎是一个更合适(并且对收件人友好,假设您的收件人来自公众)的平台,这取决于您正在考虑的情况,其逻辑是确定哪些收件人与每条消息相关联由您的数据库中的逻辑确定...它没有相同的定价结构,并且它不发送 SMS(尽管通过 SNS 发送的 SMS 无论如何似乎相当昂贵),并且与 SNS 不同,SES 没有每条消息 256k 限制。

这确实给您的应用程序增加了更多负担,因为您必须为每个订阅者将消息副本发送到 SES,但如果传出带宽是一个问题,部署在 EC2 内的实例可以轻松地负责复制和传输给 SES 的消息。使用 SES,您还可以收到有关邮件的 退回和投诉通知。

这是我会采取的方法。

但是话又说回来,很难准确地说出你在问什么。

于 2013-11-16T00:40:38.363 回答