Apple 批量推送通知答案

【问题标题】：Apple Push Notifications in BulkApple 批量推送通知
【发布时间】：2013-04-27 10:57:56
【问题描述】：

我有一个应用程序需要定期向大约 100 万用户发送 Apple 推送通知。这样做的设置已经针对少量通知进行了构建和测试。由于我无法以这种规模测试发送，因此我很想知道在发送批量推送通知方面是否存在任何问题。我有用 Python 编写的脚本，它们打开到推送服务器的单个连接并通过该连接发送所有通知。 Apple 建议尽可能长时间保持打开状态。但我也看到连接终止，您需要重新建立它。

总而言之，令人不安的是，成功的发送未被确认，只有错误的发送被标记。从程序员的角度来看，您现在需要注意许多可能出错的事情，而不是简单地检查一件事“如果（成功）”。

我的问题是：您需要注意哪些典型错误，以确保您的消息不会悄无声息地被遗忘？连接关闭很容易。还有其他人吗？

【问题讨论】：

您是否找到一种方法可以为 iphone 发送批量推送通知？因为我没有找到任何：/
如果您刚刚开始，那么请考虑从 Urban Airship 开始，它每月为您提供约 100 万次免费推送，但在其他方面非常昂贵。如果你有更多的流量，那么你可能会使用亚马逊的 SNS 服务（它比 Urban Airship 便宜几个数量级，而且是我使用的）。
但我是免费发送推送的，所以必须有一种方法可以免费发送批量推送

标签： iphone ios push-notification apple-push-notifications

【解决方案1】：

我完全同意你的观点，这个 API 非常令人沮丧，如果他们会为每个通知发送响应，它会更容易实现。

也就是说，Apple 说你应该这样做（来自Technical Note）：

推送通知吞吐量和错误检查

使用 APN 没有上限或批量大小限制。 iOS 6.1 新闻稿称 APNs 已发送超过 4 万亿次推送自成立以来的通知。它是在 WWDC 2012 上宣布的 APNs 每天发送 70 亿条通知。

如果您发现吞吐量低于每秒 9000 条通知，您的服务器可能会受益于改进的错误处理逻辑。

以下是使用增强型二进制文件时检查错误的方法界面。继续写入，直到写入失败。如果流准备好了再次写作，重新发送通知并继续。如果流尚未准备好写入，请查看流是否可用于阅读。

如果是，请从流中读取所有可用的内容。如果你得到零返回字节，连接因错误而关闭，例如无效的命令字节或其他解析错误。如果你得到六个字节返回，这是一个错误响应，您可以检查响应代码和导致错误的通知的 ID。你需要再次发送每个通知。

所有内容发送完毕后，进行最后一次检查是否有错误回应。

断开的连接可能需要一段时间才能从 APN 只是因为正常延迟而返回到您的服务器。这是可能的在写入失败之前发送超过 500 个通知，因为连接被丢弃。大约 1,700 条通知写入可能会失败只是因为管道已满，所以在这种情况下重试一次流已准备好再次写入。

现在，权衡取舍变得有趣了。你可以检查一个每次写入后的错误响应，您将正确捕获错误离开。但这会导致发送邮件所需的时间大幅增加一批通知。

如果您已捕获设备令牌，它们几乎都应该是有效的正确，您将它们发送到正确的环境。所以假设故障很少见，优化是有意义的。你会成功的如果您等待写入失败或批处理失败，则性能会更好在检查错误响应之前完成，甚至计算时间再次发送丢弃的通知。

这些都不是真正特定于 APN 的，它适用于大多数套接字级编程。

如果您选择的开发工具支持多线程或进程间通信，你可能有一个线程或进程在等待一直为错误响应，让主发送线程或进程知道何时应该放弃并重试。

【讨论】：

哇。我不是第一次在我不知道的 Apple 技术说明中找到大量信息和答案。谢谢指点！
不客气。这个技术说明已经存在了一段时间，但他们添加了我最近引用的部分。
@Eran，我在批量发送推送通知时遇到管道损坏错误，我正在使用 django-python 发送通知，如何避免管道损坏错误？我是第一次从事这种类型的项目，所以我不知道有这么多事情，请提出避免这些错误的正确方法。

【解决方案2】：

我们只是想以第一人称视角加入，因为我们每天都会发送数百万条 APNS 通知。

不幸的是，@Eran 引用的引用是关于 Apple 如何管理 APNS 套接字的最佳资源。它适合小批量，但 Apple 的文档总体上非常偏向于休闲、小批量的开发人员。扩大规模后，您会看到大量未记录的行为。

该文档中关于异步执行错误检测的部分对于高吞吐量至关重要。如果您坚持在每次发送时阻止错误，那么您将需要高度并行化您的工作人员以保持吞吐量。但是，推荐的方法是尽可能快地发送，并且无论何时遇到错误：修复和重播。

我反对的那篇文章的部分是：

设备令牌应该几乎都是有效的如果你已经捕获它们正确，您将它们发送到正确的环境。 原来如此假设失败很少发生，那么优化是有意义的。

用如此巨大的“IF”来断言该建议似乎具有极大的误导性。我几乎可以保证，大多数开发人员都没有 100%“正确”地获取令牌并处理 Apple 的反馈服务。即使它们是，系统本质上是有损的，所以会发生漂移。

我们看到非零数量的错误 #8 响应（无效的设备令牌），我将其归因于有根电话、客户端错误或用户故意将其令牌欺骗给我们。过去，我们还看到了一些错误 #7（无效的有效负载大小），我们将其追踪到开发人员在我们端添加的编码不正确的消息。这当然是我们的错，但这是我的观点——说“优化假设失败将是罕见的”是发送给学习开发人员的错误信息。我要说的是：

假设会发生错误。

希望它们很少发生，但是防御性地编码，以防他们不这样做。

如果您在假设错误很少发生的情况下进行优化，那么每当 APNS 服务出现故障并且您发送的每条消息都返回错误 #10 时，您的基础架构可能就会面临风险。

当试图弄清楚如何正确响应错误时，麻烦就来了。关于如何正确处理和从不同错误中恢复的文档不明确或不存在。这显然是留给读者的练习。

【讨论】：