在小型环境和少量通知中使用 APNS 不是问题。
问题（至少对我而言）是如何在大量的通知环境中处理 APNS 限制。
APNS 有一些限制（按设计），这使得顺利工作变得更加困难
从 APNS 不断连接和断开连接可能被视为 DOS 攻击。这让我相信我需要每隔几秒钟批量发送通知，而不是“实时”发送
不知道通知是否已到达或成功发送。只有出现错误时才会返回，返回时可能不会立即发生。
当通知导致错误（例如由于令牌错误）时，APNS 将关闭连接，并且该批次中的其余通知将不会发送到它们的目的地，但有些可能仍会发送到 APNS 和然后永远失去（没有关于成功的反馈，所以不知道他们发生了什么）。
现实生活中的生产应用程序如何与 APNS 一起解决上述问题？我是否应该保存我发送的所有通知并为每个通知检查是否返回了错误？我应该把它们排成队列吗？我是否应该面对无法发送通知的事实？连接之间的合理时间是多少，因此它不会被视为 DOS 攻击？
（目前我在 Ruby 中使用 Houston 来处理通知）
如您所知，APNS 服务不可靠。您可以使用 Amazon Simple Notification Service (Amazon SNS)。
它是一种快速、灵活、完全托管的推送通知服务，可让您发送单个消息或将消息扇出给大量收件人。Amazon SNS 使向移动设备用户、电子邮件收件人发送推送通知甚至向其他分布式服务发送消息变得简单且经济高效。更多详情请关注以下网址......
https://aws.amazon.com/blogs/aws/push-notifications-to-mobile-devices-using-amazon-sns/
这是我从本地和远程通知编程指南中找到的
管理连接的最佳实践
您可以建立到同一个网关或多个网关实例的多个连接。如果您需要发送大量远程通知，请将它们分散到多个不同网关的连接上。与使用单个连接相比，这提高了性能：它可以让您更快地发送远程通知，并且可以让 APNs 更快地传递它们。
在多个通知中保持与 APN 的连接处于打开状态；不要反复打开和关闭连接。APNs 将快速连接和断开连接视为拒绝服务攻击。您应该让连接保持打开状态，除非您知道它会长时间处于空闲状态——例如，如果您每天只向用户发送一次通知，则可以每天使用一个新连接。