Pengiriman ulang pesan Amazon SNS - Amazon Simple Notification Service

Protokol dan kebijakan pengiriman Tahap kebijakan pengiriman Membuat kebijakan HTTP/S pengiriman

Amazon SNS menentukan delivery policy (kebijakan pengiriman) untuk setiap protokol pengiriman. Kebijakan pengiriman menentukan cara Amazon SNS mencoba ulang pengiriman pesan ketika kesalahan sisi server terjadi (ketika sistem yang menghosting endpoint berlangganan menjadi tidak tersedia). Ketika kebijakan pengiriman habis, Amazon SNS berhenti untuk mengirimkan ulang dan membuang pesan-kecuali antrean surat mati dilampirkan ke langganan. Untuk informasi selengkapnya, lihat Antrian surat mati Amazon SNS.

Protokol dan kebijakan pengiriman

catatan

Dengan pengecualian HTTP/S, Anda tidak dapat mengubah kebijakan SNS-defined pengiriman Amazon. Hanya HTTP/S mendukung kebijakan khusus. Lihat Membuat kebijakan HTTP/S pengiriman.
Amazon SNS menerapkan jittering untuk pengiriman ulang pesan. Untuk informasi selengkapnya, lihat posting Exponential Backoff and Jitter (Backoff Eksponensial dan Jitter) di AWS Architecture Blog (Blog Arsitektur).
Total waktu coba ulang kebijakan untuk HTTP/S titik akhir tidak boleh lebih dari 3.600 detik. Ini adalah batas yang sulit dan tidak dapat ditingkatkan.

Jenis endpoint	Protokol pengiriman	Fase coba ulang segera (tanpa penundaan)	Pre-backoff fase	Fase backoff	Post-backoff fase	Jumlah percobaan
AWS titik akhir terkelola	¹	3 kali, tanpa penundaan	2 kali, 1 detik terpisah	10 kali, dengan backoff eksponensial, dari 1 detik sampai 20 detik	100.000 kali, terpisah 20 detik	100,015 kali, selama 23 hari
	AWS Lambda
	Amazon SQS
Endpoint yang dikelola pelanggan	SMTP	0 kali, tanpa penundaan	2 kali, 10 detik terpisah	10 kali, dengan backoff eksponensial, dari 10 detik hingga 600 detik (10 menit)	38 kali, 600 detik (10 menit) terpisah	50 percobaan, lebih dari 6 jam
	SMS
	Push seluler

¹ Untuk kesalahan pembatasan dengan protokol Firehose, Amazon SNS menggunakan kebijakan pengiriman yang sama seperti untuk titik akhir yang dikelola pelanggan.

Tahap kebijakan pengiriman

Diagram berikut menunjukkan fase kebijakan pengiriman.

Diagram sumbu x y menampilkan Waktu sebagai nilai x dan Upaya Pengiriman Awal sebagai nilai y. Kebijakan pengiriman dimulai dengan Fase Coba Kembali Segera pada sumbu y, diikuti pada sumbu x oleh Pre-Backoff Fase, Fase Backoff, dan Fase. Post-Backoff

Setiap kebijakan pengiriman terdiri dari empat fase.

Fase coba lagi segera (tanpa penundaan) — Fase ini terjadi segera setelah upaya pengiriman awal. Tidak ada penundaan antara pengiriman ulang pesan dalam fase ini.
Pre-backoff fase - Fase ini mengikuti Fase Coba Ulang Segera. Amazon SNS menggunakan fase ini untuk mencoba serangkaian pengiriman ulang pesan sebelum menerapkan fungsi backoff. Fase ini menentukan jumlah pengiriman ulang pesan dan jumlah penundaan antara mereka.
Fase backoff — Fase ini mengontrol penundaan antara percobaan ulang dengan menggunakan fungsi retry-backoff. Fase ini menetapkan penundaan minimum, penundaan maksimum, dan fungsi retry-backoff yang menentukan seberapa cepat penundaan meningkat dari penundaan minimum ke maksimum. Fungsi backoff berupa aritmatika, eksponensial, geometris, atau linier.
Post-backoff fase — Fase ini mengikuti fase backoff. Fase ini menentukan sejumlah pengiriman ulang pesan dan jumlah penundaan di antara mereka. Ini adalah fase terakhir.

Membuat kebijakan HTTP/S pengiriman

Anda dapat menentukan cara Amazon SNS mencoba ulang pengiriman pesan ke HTTP/S titik akhir menggunakan kebijakan pengiriman dengan empat fase: no-delay, pre-backoff, backoff, dan post-backoff. Kebijakan ini memungkinkan Anda untuk mengganti setelan coba ulang default dan menyesuaikannya agar sesuai dengan kapasitas server HTTP Anda.

Anda dapat menentukan kebijakan HTTP/S pengiriman sebagai objek JSON baik di tingkat topik atau langganan:

Topic-level kebijakan - Berlaku untuk semua HTTP/S langganan yang terkait dengan topik. Gunakan tindakan CreateTopicatau SetTopicAttributesAPI untuk menyetel kebijakan ini.
Subscription-level kebijakan — Berlaku hanya untuk langganan tertentu. Gunakan tindakan Subscribeatau SetSubscriptionAttributesAPI untuk menyetel kebijakan ini.

Atau, Anda juga dapat menggunakan sumber daya AWS: :SNS: :Subscription di template Anda. CloudFormation

Anda harus menyesuaikan kebijakan pengiriman berdasarkan kapasitas HTTP/S server Anda:

Server tunggal untuk semua langganan — Jika semua HTTP/S langganan dalam suatu topik menggunakan server yang sama, tetapkan kebijakan pengiriman sebagai atribut topik untuk memastikan konsistensi di semua langganan.
Server yang berbeda untuk langganan — Jika langganan menargetkan server yang berbeda, buat kebijakan pengiriman unik untuk setiap langganan, yang disesuaikan dengan kapasitas server tertentu.

Anda juga dapat mengatur Content-Type header dalam kebijakan permintaan untuk menentukan jenis media notifikasi. Secara default, Amazon SNS mengirimkan semua notifikasi ke HTTP/S titik akhir dengan jenis konten yang disetel ke. text/plain; charset=UTF-8 Namun, Anda dapat mengganti default ini menggunakan headerContentTypebidang dalam kebijakan permintaan.

Objek JSON berikut mendefinisikan kebijakan pengiriman dengan percobaan ulang yang terstruktur dalam empat fase:

No-delay fase — Coba lagi 3 kali segera.
Pre-backoff fase — Coba lagi 2 kali dengan interval 1 detik.
Fase Backoff — Coba lagi 10 kali dengan penundaan eksponensial mulai dari 1 hingga 60 detik.
Post-backoff fase — Coba lagi 35 kali dengan interval 60 detik tetap.

Amazon SNS membuat total 50 upaya untuk mengirimkan pesan sebelum membuangnya. Untuk menyimpan pesan yang tidak dapat dikirimkan setelah semua percobaan ulang, konfigurasikan langganan Anda untuk memindahkan pesan yang tidak terkirim ke antrian surat mati (DLQ). Untuk informasi selengkapnya, lihat Antrian surat mati Amazon SNS.

Amazon SNS menganggap semua kesalahan 5XX dan kesalahan 429 (terlalu banyak permintaan yang dikirim) sebagai dapat dicoba ulang. Kesalahan ini tunduk pada kebijakan pengiriman. Semua kesalahan lain dianggap sebagai kegagalan permanen dan percobaan ulang tidak akan dicoba. Namun, pesan bahwa Amazon SNS self-throttles karena maxReceivesPerSecond pengaturan tidak tunduk pada kebijakan coba lagi pengiriman. Self-throttled pesan diantrian ulang dan terus dikirimkan sesuai kapasitas memungkinkan, tanpa menggunakan upaya coba lagi.

catatan

Kebijakan pengiriman ini menggunakan maxReceivesPerSecond properti untuk membatasi lalu lintas pengiriman ke rata-rata 10 pesan per detik per langganan. Meskipun mekanisme ini membantu mencegah HTTP/S titik akhir Anda kewalahan oleh lalu lintas tinggi, mekanisme ini dirancang untuk mempertahankan tingkat pengiriman rata-rata dan tidak memberlakukan batasan yang ketat. Lonjakan lalu lintas pengiriman sesekali di atas batas yang ditentukan dapat terjadi, terutama jika tingkat penerbitan Anda secara signifikan lebih tinggi dari batas pembatasan.

Ketika lalu lintas penerbitan (inbound) melebihi tingkat pengiriman (outbound), hal itu dapat menghasilkan backlog pesan dan latensi pengiriman yang lebih tinggi. Untuk menghindari masalah seperti itu, pastikan maxReceivesPerSecond nilainya selaras dengan kapasitas HTTP/S server dan persyaratan beban kerja Anda.

Contoh kebijakan pengiriman berikut akan mengganti jenis konten default untuk HTTP/S notifikasi. application/json


{
    "healthyRetryPolicy": {
        "minDelayTarget": 1,
        "maxDelayTarget": 60,
        "numRetries": 50,
        "numNoDelayRetries": 3,
        "numMinDelayRetries": 2,
        "numMaxDelayRetries": 35,
        "backoffFunction": "exponential"
    },
    "throttlePolicy": {
        "maxReceivesPerSecond": 10
    },
    "requestPolicy": {
        "headerContentType": "application/json"
    }
}

Kebijakan pengiriman terdiri dari kebijakan coba lagi, kebijakan throttle, dan kebijakan permintaan. Secara total, ada 9 atribut dalam kebijakan pengiriman.

Kebijakan	Deskripsi	Kendala
`minDelayTarget`	Penundaan minimum untuk pengiriman ulang. Unit: Detik	1 hingga penundaan maksimum Default: 20
`maxDelayTarget`	Penundaan maksimum untuk pengiriman ulang. Unit: Detik	Minimal delay ke 3.600 Default: 20
`numRetries`	Jumlah total pengiriman ulang, termasuk pengiriman ulang langsung, pra-backoff, backoff, dan pasca-backoff.	0 hingga 100 Default: 3
`numNoDelayRetries`	Jumlah pengiriman ulang yang harus dilakukan segera, tanpa penundaan di antara mereka.	0 atau lebih Default: 0
`numMinDelayRetries`	Jumlah pengiriman ulang dalam fase pra-backoff, dengan penundaan minimum yang ditentukan di antara keduanya.	0 atau lebih Default: 0
`numMaxDelayRetries`	Jumlah pengiriman ulang dalam fase pasca-backoff, dengan penundaan maksimum di antara keduanya.	0 atau lebih Default: 0
`backoffFunction`	Model untuk backoff di antara pengiriman ulang.	Salah satu dari empat pilihan: aritmatika eksponensial geometris linier Default: linier
`maxReceivesPerSecond`	Jumlah rata-rata maksimum pengiriman pesan per detik, per langganan.	1 atau lebih Default: Tidak ada pembatasan (tidak ada batasan tingkat pengiriman)
`headerContentType`	Jenis konten notifikasi yang dikirim ke HTTP/S titik akhir.	Jika kebijakan permintaan tidak ditentukan, jenis konten akan menjadi default. `text/plain; charset=UTF-8` Saat pengiriman pesan mentah dinonaktifkan untuk langganan (default), atau saat kebijakan pengiriman ditentukan pada tingkat topik, jenis konten header yang didukung adalah dan. `application/json` `text/plain` Saat pengiriman pesan mentah diaktifkan untuk langganan, jenis konten berikut didukung: text/css text/csv text/html text/plain text/xml application/atom+xml+ application/json application/octet-aliran application/soap+xml+ application/x-www-form-urlencoded application/xhtml+xml+ application/xml

Amazon SNS menggunakan rumus berikut untuk menghitung jumlah pengiriman ulang dalam fase backoff:


numRetries - numNoDelayRetries - numMinDelayRetries - numMaxDelayRetries

Anda dapat mengontrol frekuensi percobaan ulang selama fase backoff menggunakan tiga parameter:

minDelayTarget— Menetapkan penundaan untuk upaya coba lagi pertama di fase backoff.
maxDelayTarget— Menetapkan penundaan untuk upaya coba lagi terakhir di fase backoff.
backoffFunction— Menentukan algoritma yang digunakan Amazon SNS untuk menghitung penundaan untuk semua upaya coba lagi antara percobaan ulang pertama dan terakhir. Anda dapat memilih dari empat fungsi retry-backoff yang tersedia.

Diagram berikut menggambarkan bagaimana fungsi backoff coba lagi yang berbeda mempengaruhi penundaan antara percobaan ulang selama fase backoff. Kebijakan pengiriman yang digunakan untuk contoh ini mencakup pengaturan berikut: 10 total percobaan ulang, penundaan minimum 5 detik, dan penundaan maksimum 260 detik.

Sumbu vertikal menunjukkan penundaan (dalam detik) untuk setiap upaya coba lagi.
Sumbu horizontal mewakili urutan coba lagi, mulai dari upaya pertama hingga kesepuluh.

Diagram menunjukkan bagaimana coba lagi menunda kemajuan selama 10 upaya berdasarkan empat fungsi backoff: eksponensial, aritmatika, linier, dan geometris. Setiap garis berwarna mewakili pola penundaan fungsi: Eksponensial: Meningkat dengan cepat, mencapai penundaan maksimum tercepat, Linear: Meningkat terus dengan setiap percobaan ulang, Aritmatika dan Geometris: Tunjukkan peningkatan sedang, lebih curam dari linier tetapi kurang cepat dari eksponensial. Semua baris mulai mendekati penundaan minimum 5 detik dan mendekati penundaan maksimum 260 detik dengan percobaan ulang kesepuluh.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Mengkonfigurasi pencatatan status pengiriman menggunakan CloudFormation

Antrean dead-letter