批量推送Apple推送

Question

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

所有的一切，这是令人不安的，成功的将不被确认，只有那些错误被标记。从程序员的角度来看，而不是简单地检查一件事情“如果（成功）”，你现在需要注意许多可能出错的事情。

我的问题是：什么是典型的集，你需要注意，以确保您的邮件没有声息被人遗忘的错误？连接关闭很容易。有其他人吗？

Answer 1

我完全同意你的看法，这个API是非常令人沮丧，如果他们所要发送的每个通知这本来是很容易实现的响应。

这就是说，这里就是苹果公司说，你应该（从Technical Note）做：

Push Notification Throughput and Error Checking

There are no caps or batch size limits for using APNs. The iOS 6.1 press release stated that APNs has sent over 4 trillion push notifications since it was established. It was announced at WWDC 2012 that APNs is sending 7 billion notifications daily.

If you're seeing throughput lower than 9,000 notifications per second, your server might benefit from improved error handling logic.

Here's how to check for errors when using the enhanced binary interface. Keep writing until a write fails. If the stream is ready for writing again, resend the notification and keep going. If the stream isn't ready for writing, see if the stream is available for reading.

If it is, read everything available from the stream. If you get zero bytes back, the connection was closed because of an error such as an invalid command byte or other parsing error. If you get six bytes back, that's an error response that you can check for the response code and the ID of the notification that caused the error. You'll need to send every notification following that one again.

Once everything has been sent, do one last check for an error response.

It can take a while for the dropped connection to make its way from APNs back to your server just because of normal latency. It's possible to send over 500 notifications before a write fails because of the connection being dropped. Around 1,700 notifications writes can fail just because the pipe is full, so just retry in that case once the stream is ready for writing again.

Now, here's where the tradeoffs get interesting. You can check for an error response after every write, and you'll catch the error right away. But this causes a huge increase in the time it takes to send a batch of notifications.

Device tokens should almost all be valid if you've captured them correctly and you're sending them to the correct environment. So it makes sense to optimize assuming failures will be rare. You'll get way better performance if you wait for write to fail or the batch to complete before checking for an error response, even counting the time to send the dropped notifications again.

None of this is really specific to APNs, it applies to most socket-level programming.

If your development tool of choice supports multiple threads or interprocess communication, you could have a thread or process waiting for an error response all the time and let the main sending thread or process know when it should give up and retry.

Answer 2

只想附和第一人称视角，因为我们每天发送数以百万计APNS通知。

@Eran报价参考不幸的是对我们有苹果如何管理APNS插座最好的资源。对于低销量的产品来说没什么问题，但苹果公司的文档总体上偏向于那些偶然的低产量开发者。一旦你达到规模，你会看到很多无证的行为。

这样做的错误检测该文件的一部分异步是高通量的关键。如果你坚持阻止每次发送错误，那么你需要大量的并行工作来保持吞吐量。然而，推荐的方式是发送速度尽可能快，并且每当发生错误时：修复并重播。

那个帖子我不同意的部分是：

Device tokens should almost all be valid if you've captured them correctly and you're sending them to the correct environment. So it makes sense to optimize assuming failures will be rare.

要谓词的意见如此庞大的“IF”，似乎巨大的误导。我几乎可以保证大多数开发人员不会捕获令牌并“正确”处理100％的Apple反馈服务。即使是这样，系统本身也是有损的，所以漂移将会发生。

我们看到一个非零数字的错误＃8的响应（无效的设备令牌），我归因于根深蒂固的手机，客户端的错误，或用户故意欺骗自己的令牌给我们。过去我们也看到了一些错误＃7（无效负载大小），我们追踪到开发人员在我们的末端添加的不正确编码的消息。这当然是我们的错，但这就是我的观点 - 说“优化假设失败是罕见的”是向学习开发人员发送的错误信息。我想说的，而不是将是：

Assume errors will happen.

Hope that they happen infrequently, but code defensively in case they don't.

如果您优化假设错误将是罕见的，你可能有危险把你的基础设施每当APNS服务下降和每封邮件发送返回错误＃10。

当试图弄清楚如何正确响应错误时会遇到麻烦。关于如何正确处理和从不同错误中恢复的文档不明确或缺乏。这显然是作为读者的练习。