使用AWS SNS与直接使用Apple APNS的优势

Question

我有一个应用程序逻辑，它要求我将用户设备划分为订阅不同类型的“频道/主题”的组。

然后，我想向特定主题或频道的所有订阅者发送广播消息。

我可以有多达500,000个主题或频道，每个频道有多达20,000个订阅者。

由于AWS SNS的每个频道有3,000个主题和10,000个订阅者的限制，他们的常见问题建议您使用直接寻址，即由我逐个发送。他们建议我们也走这条路线，如果我们有大量的..

AWS SNS没有批量发布功能，所以我实际上需要为每个订阅者发出一个SNS发布请求，这可以挂载到数万个请求。

所以我发现AWS-PHP-SDK是建立在Guzzle之上的，并通过多curl支持并行请求处理，但即便如此，如果我同时运行20个连接，我仍然需要发出如此多的请求……这是有效的吗？如果我的数据量很大，为什么推荐使用这种方式？

另一个问题浮现在我的脑海中，如果我需要一个接一个地向每个订阅者发送相同的消息，为什么还要使用SNS？

Apple APNS服务的工作方式是打开TCP连接并写入字节的请求，每个请求都有不同的订阅者详细信息，但我可以只写入字节，而不需要构建PHP请求和处理20个进程的开销。这不是更快地将我的消息发送给所有主题/通道订阅者的方式吗？

在这种情况下，我对AWS SNS服务的权衡和附加值感到有点困惑。我希望过去有这方面经验的人或AWS员工能提供一些见解。

谢谢

Answer 1

如果你只是打算对APNS目标进行一对一的通知，那么使用SNS并没有太大的优势。

如果你想开始针对iOS、安卓和其他通知平台的1-1通知，SNS会变得更有用，因为它可以帮助你在代码中将所有这些不同的平台目标抽象到一个SNS API后面。

如果你想广播1-N，那么SNS也很有用，因为你可以打一个电话就能发送到10,000台设备。