Powiadomienia Apple Push w dużych rozmiarach

Question

Mam aplikację, która polega na okresowym wysyłaniu powiadomień Apple Push do ~ 1 mln użytkowników. Konfiguracja do tego została zbudowana i przetestowana pod kątem niewielkiej liczby powiadomień. Ponieważ nie ma możliwości przetestowania wysyłania w tej skali, chciałbym wiedzieć, czy są jakieś błędy w wysyłaniu masowych powiadomień push. Mam napisane w Pythonie skrypty, które otwierają jedno połączenie z serwerem push i wysyłają wszystkie powiadomienia za pośrednictwem tego połączenia. Firma Apple zaleca pozostawienie go otwartego tak długo, jak to możliwe. Ale widziałem również, że połączenie się kończy i trzeba je przywrócić.

W sumie niepokojące jest to, że wysyłanie zakończone sukcesem nie jest potwierdzone, tylko te błędne są oflagowane. Z punktu widzenia programisty zamiast po prostu sprawdzać jedną rzecz "jeśli (sukces)" trzeba teraz obserwować wiele rzeczy, które mogą pójść nie tak.

Moje pytanie brzmi: Jak wygląda typowy zestaw błędów, na które należy uważać, aby upewnić się, że wiadomości nie znikną w milczeniu w zapomnienie? Zamknięcie połączenia jest łatwe. Czy są inni?

Answer 1

Całkowicie się z tobą zgadzam, że ten interfejs API jest bardzo frustrujący, a gdyby wysłał odpowiedź na każde powiadomienie, byłoby to znacznie łatwiejsze do wdrożenia.

powiedział, że tu właśnie jabłko powiedzieć należy zrobić (z 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

Chciałem tylko dostroić się z perspektywy pierwszej osoby, a my wyślemy miliony zgłoszeń APNS codziennie.

Cytaty z cytatów @Eran są niestety najlepszym źródłem informacji o tym, jak Apple zarządza gniazdami APNS. W przypadku niewielkich rozmiarów wszystko jest w porządku, ale ogólnie dokumentacja firmy Apple jest bardzo przekręcona w stosunku do zwykłego, niskonakładowego programisty. Zobaczysz wiele nieudokumentowanych zachowań, gdy dojdziesz do skali.

Część tego dokumentu dotycząca asynchronicznego wykrywania błędów ma krytyczne znaczenie dla wysokiej przepustowości. Jeśli nalegasz na blokowanie błędów przy każdym wysyłaniu, będziesz musiał silnie zrównoleglować swoich pracowników, aby utrzymać przepustowość. Zalecanym sposobem jest jednak po prostu wysłać tak szybko, jak można wysłać, a gdy pojawi się i błąd: naprawić i powtórzyć.

Część tego postu biorę wyjątek jest:

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.

orzekać tej rady z takim ogromnym „IF” wydaje się niezwykle mylące. Mogę niemal zagwarantować, że większość programistów nie przechwytuje tokenów i nie przetwarza w 100% informacji zwrotnej firmy Apple w prawidłowy sposób. Nawet gdyby tak było, system jest z natury stratny, więc nastąpi dryf.

Widzimy niezerową liczbę błędów nr 8 (nieprawidłowy token urządzenia), które przypisuję do zrootowanych telefonów, błędów klienta lub użytkowników celowo podrabiających nam tokeny. W przeszłości zauważyliśmy również szereg błędów nr 7 (nieprawidłowy rozmiar ładunku), które znaleźliśmy w nieprawidłowo zakodowanych wiadomościach, które programista dodał na końcu. To oczywiście była nasza wina, ale to jest moja uwaga - twierdzenie "optymalizacja przy założeniu, że awarie będą rzadkie" jest błędną wiadomością dla programistów nauki. Co powiedziałbym zamiast byłoby:

Assume errors will happen.

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

Jeśli zoptymalizować zakładając błędy będą rzadkie, może być wprowadzenie infrastruktury zagrożone, gdy usługa APNS idzie w dół, a każda wiadomość wysłaniu zwraca błąd # 10.

Problem pojawia się, gdy próbuje się dowiedzieć, jak prawidłowo reagować na błędy. Dokumentacja jest niejednoznaczna lub nieobecna, jeśli chodzi o prawidłową obsługę i odzyskiwanie po różnych błędach. Zostało to najwyraźniej ćwiczeniem dla czytelnika.