我有一个应用程序，涉及定期向〜1M用户发送Apple推送通知。这样做的设置已经构建并测试了少量通知。由于我无法测试那种规模的发送，我有兴趣知道发送批量推送通知是否有任何问题。我有用Python编写的脚本，它打开与推送服务器的单一连接，并通过该连接发送所有通知。 Apple建议尽可能长时间保持打开状态。但我也看到连接终止，你需要重新建立它。
总而言之，令人不安的是，成功的发送未被确认，只有错误的发送被标记。从程序员的角度来看，而不是简单地检查一件事“如果（成功）”，你现在需要注意许多可能出错的事情。
我的问题是：您需要注意哪些典型的错误，以确保您的消息不会默默地消失为遗忘？连接关闭很简单。还有其他人吗？
答案 0 :(得分：12)
我完全同意你的说法，这个API非常令人沮丧，如果他们会为每个通知发送一个响应，那么实施起来就会容易得多。
那就是说，这就是Apple说你应该做的事情（来自Technical Note）：
推送通知吞吐量和错误检查
使用APN没有上限或批量大小限制。 iOS 6.1 新闻稿称，APN已经发送超过4万亿次推送 自成立以来的通知。它是在2012年WWDC上宣布的 APN每天发送70亿条通知。
如果您发现吞吐量低于每秒9,000次通知， 您的服务器可能会受益于改进的错误处理逻辑。
以下是使用增强型二进制文件时如何检查错误 接口。继续写入，直到写入失败。如果流准备就绪 再次写入，重新发送通知并继续。如果 stream尚未准备好写入，请查看该流是否可用 读数。
如果是，请阅读流中的所有内容。如果你得到零 返回字节，因为一个错误，连接被关闭了 无效的命令字节或其他解析错误。如果你得到六个字节 回来，这是一个错误响应，您可以检查响应 代码和导致错误的通知的ID。你需要 再次发送该通知后的每个通知。
一旦发送完所有内容，请最后一次检查是否有错误 响应。
删除连接可能需要一段时间才能完成 APN仅因正常延迟而返回您的服务器。这是可能的 在写入失败之前发送超过500个通知因为 连接被丢弃。大约1,700个通知写入可能会失败 只是因为管道已满，所以只需在那种情况下重试一次 流已准备好再次写作。
现在，这里的权衡变得有趣。你可以检查一下 每次写入后都会出现错误响应，并且您将正确捕获错误 远。但是这会导致发送时间的大幅增加 一批通知。
如果您捕获了设备令牌，那么设备令牌几乎都应该有效 正确而且您将它们发送到正确的环境。所以 有意义的优化假设失败将是罕见的。你会得到的 如果等待写入失败或批处理，则性能会更好 在检查错误响应之前完成，甚至计算时间 再次发送已删除的通知。
这些都不是APN特有的，它适用于大多数 套接字级编程。
如果您选择的开发工具支持多个线程或 进程间通信，你可以让一个线程或进程等待 为了一直错误响应，让主发送线程或 过程知道何时应该放弃并重试。
答案 1 :(得分：7)
我们希望以第一人称的观点来讨论，因为我们每天都会发送数百万张APNS通知。
遗憾的是，引用@Eran引用是关于Apple如何管理APNS套接字的最佳资源。它适用于低容量，但Apple的整体文档非常偏向于随意的低容量开发人员。一旦你进行扩展，你会看到大量未记录的行为。
该文档中有关异步执行错误检测的部分对于高吞吐量至关重要。如果您坚持在每次发送时阻止错误，那么您将需要大量并行化您的工作程序以保持吞吐量。然而，推荐的方法是尽可能快地发送，并且每当你收到并发送错误时：发送和重播。
我接受例外的那篇文章的部分是：
设备令牌几乎全部有效如果您已经捕获它们 正确，您将它们发送到正确的环境。 所以它 有意义的是优化假设失败很少。
断言如此巨大的“IF”的建议似乎极具误导性。我几乎可以保证大多数开发人员不会“正确地”捕获令牌并100％处理Apple的反馈服务。即使它们是，系统本质上是有损的，所以漂移将会发生。
我们看到非零数量的错误＃8响应（无效设备令牌），我将其归因于有根电话，客户端错误或用户故意欺骗他们的令牌给我们。我们在过去也看到了许多错误＃7（无效的有效负载大小），我们追踪到了开发人员在我们最后添加的不正确编码的消息。这当然是我们的错，但这是我的观点 - 说“优化假设失败将是罕见的”是发送给学习开发人员的错误信息。我要说的是：
假设会发生错误。
希望它们不经常发生，但是 防守代码以防他们不守。
如果您优化假设错误很少，那么每当APNS服务中断并且您发送的每条消息都返回错误＃10时，您的基础架构可能会面临风险。
在试图弄清楚如何正确回应错误时会遇到麻烦。关于如何正确处理和从不同错误中恢复，文档是模糊的或不存在的。这显然是为读者留下的练习。