批量推送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。

當試圖弄清楚如何正確響應錯誤時會遇到麻煩。關於如何正確處理和從不同錯誤中恢復的文檔不明確或缺乏。這顯然是作爲讀者的練習。