Apple 批量推送通知 [英] Apple Push Notifications in Bulk

问题描述

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

I have an app that involves sending Apple Push Notifications to ~1M users periodically. The setup for doing so has been built and tested for small numbers of notifications. Since there is no way I can test sending at that scale, I am interested in knowing whether there are any gotchas in sending bulk push notifications. I have scripts written in Python that open a single connection to the push server and send all notifications over that connection. Apple recommends keeping it open for as long as possible. But I have also seen that the connection terminates and you need to reestablish it.

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

All in all, it is disconcerting that successful sends are not acknowledged, only erroneous ones are flagged. From a programmer's standpoint instead of simply checking one thing "if (success)" you now need to watch for numerous things that could go wrong.

我的问题是:您需要注意哪些典型的错误，以确保您的消息不会悄然消失?连接关闭很容易.还有其他的吗?

My question is: What are the typical set of errors that you need to watch out for to make sure your messages don't silently disappear into oblivion? The connection closing is an easy one. Are there others?

推荐答案

我完全同意你的看法，这个 API 非常令人沮丧，如果他们能够为每个通知发送响应，那么实施起来会容易得多.

I completely agree with you that this API is very frustrating, and if they would have sent a response for each notification it would have been much easier to implement.

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

That said, here's what Apple say you should do (from Technical Note) :

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

Push Notification Throughput and Error Checking

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

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.

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

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.

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

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.

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

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.

这些都不是真正针对 APNs，它适用于大多数套接字级编程.

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.

这篇关于Apple 批量推送通知的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！