批量Apple推送通知

Question

我有一个应用程序,涉及定期向〜1M用户发送Apple推送通知.这样做的设置已经构建并测试了少量通知.由于我无法测试那种规模的发送,我有兴趣知道发送批量推送通知是否有任何问题.我有用Python编写的脚本,它打开与推送服务器的单一连接,并通过该连接发送所有通知.Apple建议尽可能长时间保持打开状态.但我也看到连接终止,你需要重新建立它.

总而言之,令人不安的是,成功的发送不被确认,只有错误的发送被标记.从程序员的角度来看,而不是简单地检查一件事"如果(成功)",你现在需要注意许多可能出错的事情.

我的问题是:您需要注意哪些典型的错误,以确保您的消息不会默默地消失？连接关闭很简单.还有其他人吗？

Answer 1

我完全同意你的看法,这个API非常令人沮丧,如果他们会为每个通知发送一个响应,那么实现它会容易得多.

也就是说,这就是Apple说你应该做的事情(来自技术说明):

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

使用APN没有上限或批量大小限制.iOS 6.1新闻稿指出,APN自成立以来已经发送了超过4万亿次推送通知.在WWDC 2012上宣布,APN每天发送70亿条通知.

如果您发现吞吐量低于每秒9,000个通知,则您的服务器可能会受益于改进的错误处理逻辑.

以下是使用增强型二进制接口时如何检查错误.继续写入,直到写入失败.如果流已准备好再次写入,请重新发送通知并继续.如果流尚未准备好写入,请查看该流是否可供读取.

如果是,请从流中读取所有可用内容.如果返回零字节,则由于诸如无效命令字节或其他解析错误之类的错误而关闭连接.如果你得到六个字节,那就是一个错误响应,你可以检查响应代码和导致错误的通知的ID.您需要再次发送该通知之后的每个通知.

一旦发送完所有内容,请最后一次检查是否有错误响应.

由于正常的延迟,丢弃的连接可能需要一段时间才能从APN返回到服务器.由于连接被丢弃,在写入失败之前可以发送超过500个通知.大约1,700个通知写入可能因为管道已满而失败,因此只要流准备好再次写入就可以重试.

现在,这里的权衡变得有趣.您可以在每次写入后检查错误响应,并立即捕获错误.但这会导致发送一批通知所需的时间大幅增加.

如果您正确捕获设备令牌并将它们发送到正确的环境,则设备令牌几乎都应该有效.因此,优化假设失败是很少见的.如果在检查错误响应之前等待写入失败或批处理完成,您将获得更好的性能,甚至计算再次发送已删除通知的时间.

这些都不是APN特有的,它适用于大多数套接字级编程.

如果您选择的开发工具支持多线程或进程间通信,您可以让一个线程或进程始终等待错误响应,让主发送线程或进程知道何时应该放弃并重试.

Answer 2

我们希望以第一人称的观点来加入,因为我们每天都会发送数百万条APNS通知.

不幸的是,引用@Eran引用是关于Apple如何管理APNS套接字的最佳资源.它适用于低容量,但Apple的整体文档非常偏向于随意的低容量开发人员.一旦扩展,您将看到大量未记录的行为.

该文档中关于异步执行错误检测的部分对于高吞吐量至关重要.如果您坚持在每次发送时阻止错误,那么您将需要大量并行化您的工作程序以保持吞吐量.然而,推荐的方法是尽可能快地发送,并且每当你收到并发送错误时:发送和重放.

我不接受的那篇文章的部分是:

如果您正确捕获设备令牌并将它们发送到正确的环境,则设备令牌几乎都应该有效.因此,优化假设失败是很少见的.

用这样一个巨大的"IF"来预测这个建议似乎有很大的误导性.我几乎可以保证大多数开发人员不会"正确地"捕获令牌并100%处理Apple的反馈服务.即使它们是,系统本质上是有损的,所以漂移将会发生.

我们看到非零数量的错误#8响应(无效设备令牌),我将其归因于有根电话,客户端错误或用户故意欺骗他们的令牌给我们.我们在过去也看到了许多错误#7(无效的有效负载大小),我们追踪到了开发人员在我们最后添加的不正确编码的消息.这当然是我们的错,但这是我的观点 - 说"优化假设失败将是罕见的"是发送给学习开发人员的错误信息.我要说的是:

假设会发生错误.

希望它们不经常发生,但是防守代码以防万一.

如果您优化假设错误很少,那么每当APNS服务发生故障并且您发送的每条消息都返回错误#10时,您可能会将您的基础架构置于风险之中.

在试图弄清楚如何正确回应错误时会遇到麻烦.关于如何正确处理和从不同错误中恢复,文档是模糊的或不存在的.这显然是为读者留下的练习.