在小型环境中使用APNS和低容量通知不是问题。
问题（至少对我来说）是如何在大量的通知环境中使用APNS限制。
APNS有一些限制（按设计）使得工作更加顺畅
与APNS持续连接和断开连接可能会被视为DOS攻击。这让我相信我需要每隔几秒批量发送通知，而不是实时＆＃34;实时＆＃34;发送
不知道通知是否已到达或已成功发送。只有在出现错误时才会返回，并且在返回时可能不会立即生效。
当通知导致错误时（例如由于令牌错误），APNS会关闭连接，并且该批次中的其他通知不会被发送到目的地，但是有些人可能仍会被发送到APNS然后永远丢失（没有关于成功的反馈，因此不知道他们发生了什么）。
现实生产应用程序如何与APNS一起解决上述问题？我应该保存我发送的所有通知以及每个通知以检查是否返回了错误？我应该把它们放在队列中吗？我是否应该面对这样一个事实，即会有不会发送的通知？连接之间的合理时间是多少，因此它不会被视为DOS攻击？
（目前我在Ruby中使用Houston来处理通知）
答案 0 :(得分：1)
如您所知APNS服务不可靠。您可以使用 亚马逊简单通知服务（Amazon SNS）。
这是一种快速，灵活，完全托管的推送通知服务，可让您向大量收件人发送单个邮件或扇出邮件。 Amazon SNS使推送通知能够简单且经济高效地向移动设备用户，电子邮件收件人发送消息，甚至向其他分布式服务发送消息。 请按照以下网址获取更多详细信息......
https://aws.amazon.com/blogs/aws/push-notifications-to-mobile-devices-using-amazon-sns/
答案 1 :(得分：0)
这是我从Local and Remote Notification Programming Guide
中找到的管理连接的最佳做法
您可以与同一网关建立多个连接 多个网关实例。如果你需要发送大量的 远程通知，通过几个连接传播它们 不同的网关。与使用a相比，这提高了性能 单一连接：它可以让您更快地发送远程通知， 它让APN更快地提供它们。
在多个通知中保持与APN的连接; 不要反复打开和关闭连接。 APN迅速对待 连接和断开作为拒绝服务攻击。你应该 保持连接打开，除非你知道它会闲置一个 延长的时间段 - 例如，如果您只发送通知 您的用户每天可以使用一次新连接。