Mencoba lagi pengiriman SNS pesan Amazon - Amazon Simple Notification Service
Protokol dan kebijakan pengirimanTahap kebijakan pengirimanMembuat kebijakan pengiriman HTTP /S

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mencoba lagi pengiriman SNS pesan Amazon

Amazon SNS mendefinisikan kebijakan pengiriman untuk setiap protokol pengiriman. Kebijakan pengiriman menentukan cara Amazon SNS mencoba ulang pengiriman pesan saat terjadi kesalahan sisi server (saat sistem yang meng-host titik akhir berlangganan menjadi tidak tersedia). Ketika kebijakan pengiriman habis, Amazon SNS berhenti mencoba kembali pengiriman dan membuang pesan—kecuali antrian surat mati dilampirkan ke langganan. Untuk informasi selengkapnya, lihat Antrian SNS surat mati Amazon.

Protokol dan kebijakan pengiriman

catatan

  • Dengan pengecualian HTTP/S, you can't change Amazon SNS-defined delivery policies. Only HTTP/S mendukung kebijakan khusus. Lihat Membuat kebijakan pengiriman HTTP /S.

  • Amazon SNS menerapkan jittering pada percobaan ulang pengiriman. 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 titik akhir HTTP /S 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) Fase pra-backoff Fase backoff Fase pasca-backoff Jumlah percobaan
AWS titik akhir terkelola Hos Pemadam Kebakaran Data Amazon¹ 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 Lagi Segera pada sumbu y, diikuti pada sumbu x oleh Fase Pra-Backoff, Fase Backoff, dan Fase Pasca-Backoff.

Setiap kebijakan pengiriman terdiri dari empat fase.

  1. Immediate Retry Phase (No Delay) (Fase Coba Ulang Segera) (Tanpa Penundaan) – Fase ini terjadi segera setelah upaya pengiriman awal. Tidak ada penundaan antara pengiriman ulang pesan dalam fase ini.

  2. Pre-Backoff Phase (Fase Pra-Backoff) – Fase ini mengikuti Immediate Retry Phase (Fase Coba Ulang Segera). Amazon SNS menggunakan fase ini untuk mencoba serangkaian percobaan ulang sebelum menerapkan fungsi backoff. Fase ini menentukan jumlah pengiriman ulang pesan dan jumlah penundaan antara mereka.

  3. Backoff Phase (Fase Backoff) - Fase ini mengontrol penundaan antara pengiriman ulang pesan dengan menggunakan fungsi pengiriman 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.

  4. Post-Backoff Phase (Fase Pasca Backoff) - Fase ini mengikuti fase backoff. Fase ini menentukan sejumlah pengiriman ulang pesan dan jumlah penundaan di antara mereka. Ini adalah fase terakhir.

Membuat kebijakan pengiriman HTTP /S

Anda dapat menggunakan kebijakan pengiriman dan empat tahapannya untuk menentukan cara Amazon SNS mencoba ulang pengiriman pesan ke titik akhir HTTP /S. Amazon SNS memungkinkan Anda mengganti kebijakan coba ulang default untuk HTTP titik akhir ketika Anda mungkin, misalnya, ingin menyesuaikan kebijakan berdasarkan kapasitas HTTP server Anda.

Anda dapat mengatur HTTP/S delivery policy as a JSON object at the subscription or topic level. When you define the policy at the topic level, it applies to all HTTP/S langganan yang terkait dengan topik tersebut. Untuk menetapkan kebijakan pengiriman di tingkat langganan, Anda dapat menggunakan SetSubscriptionAttributesAPItindakan Subscribeatau tindakan. Untuk menetapkan kebijakan pengiriman di tingkat topik, Anda dapat menggunakan SetTopicAttributesAPItindakan CreateTopicatau tindakan. Atau, Anda juga dapat menggunakan sumber daya AWS::SNS: :Subscription di AWS CloudFormation template Anda.

Anda harus menyesuaikan kebijakan pengiriman sesuai dengan HTTP/S server's capacity. You can set the policy as a topic attribute or a subscription attribute. If all HTTP/S subscriptions in your topic target the same HTTP/S server, we recommend that you set the delivery policy as a topic attribute, so that it remains valid for all HTTP/S subscriptions in the topic. Otherwise, you must compose a delivery policy for each HTTP/S subscription in your topic, according the capacity of the HTTP/S server yang ditargetkan oleh kebijakan tersebut.

Anda juga dapat mengatur header Content-Type dalam kebijakan permintaan untuk menentukan jenis media notifikasi. Secara default, Amazon SNS mengirimkan semua notifikasi ke titik akhir HTTP /S dengan jenis konten yang disetel ketext/plain; charset=UTF-8. Amazon SNS memungkinkan Anda mengganti kebijakan permintaan default. Lihat tabel di bawah ini untuk dukungan headerContentTypedan pengekangan.

JSONObjek berikut menunjukkan kebijakan pengiriman yang menginstruksikan Amazon SNS untuk mencoba kembali upaya pengiriman HTTP /S yang gagal, sebagai berikut:

  1. 3 kali segera dalam fase tanpa penundaan

  2. 2 kali (1 detik terpisah) dalam fase pra-backoff

  3. 10 kali (dengan backoff eksponensial dari 1 detik hingga 60 detik)

  4. 35 kali (60 detik terpisah) dalam fase pasca-backoff

Dalam kebijakan pengiriman sampel ini, Amazon SNS melakukan total 50 upaya sebelum membuang pesan. Untuk menyimpan pesan setelah percobaan ulang yang ditentukan dalam kebijakan pengiriman habis, konfigurasikan langganan Anda untuk memindahkan pesan yang tidak terkirim ke antrean huruf mati (). DLQ Untuk informasi selengkapnya, lihat Antrian SNS surat mati Amazon.

catatan

Kebijakan pengiriman ini juga menginstruksikan Amazon SNS untuk membatasi pengiriman hingga tidak lebih dari 10 per detik, menggunakan properti. maxReceivesPerSecond Tingkat self-throttling ini dapat menghasilkan lebih banyak pesan yang dipublikasikan (lalu lintas masuk) daripada yang dikirim (lalu lintas keluar). Jika lalu lintas masuk lebih banyak daripada lalu lintas keluar, langganan Anda dapat mengakumulasi simpanan pesan yang besar, yang dapat menyebabkan latensi pengiriman pesan menjadi tinggi. Dalam kebijakan pengiriman Anda, pastikan untuk menentukan nilai untuk maxReceivesPerSecond yang tidak berdampak buruk pada beban kerja Anda.

catatan

Kebijakan pengiriman ini mengesampingkan tipe konten default untuk notifikasi HTTP /S. 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 maksimum pengiriman per detik, per langganan. 1 atau lebih

Default: Tidak ada throttling
headerContentType

Jenis konten notifikasi yang dikirim ke titik akhir HTTP /S.

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:

  • teks/css

  • teks/csv

  • teks/html

  • teks/polos

  • teks/xml

  • aplikasi/atom+xml+

  • aplikasi/json

  • aplikasi/oktet-aliran

  • aplikasi/sabun+xml+

  • aplikasi/ x-www-form-urlencoded

  • aplikasi/xhtml+xml+

  • aplikasi/xml

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

numRetries - numNoDelayRetries - numMinDelayRetries - numMaxDelayRetries

Anda dapat menggunakan tiga parameter untuk mengontrol frekuensi pengiriman ulang dalam fase backoff.

  • minDelayTarget — Menetapkan penundaan terkait dengan pengiriman ulang dalam fase backoff.

  • maxDelayTarget — Menetapkan penundaan terkait dengan pengiriman ulang terakhir dalam fase backoff.

  • backoffFunction— Mendefinisikan algoritme yang SNS digunakan Amazon untuk menghitung penundaan yang terkait dengan semua upaya coba lagi antara percobaan ulang pertama dan terakhir di fase backoff. Anda dapat menggunakan salah satu dari empat fungsi retry-backoff.

Diagram berikut menunjukkan bagaimana setiap fungsi backoff pengiriman ulang mempengaruhi penundaan terkait dengan pengiriman ulang selama fase backoff: Kebijakan pengiriman dengan jumlah total pengiriman ulang diatur ke 10, penundaan minimum diatur ke 5 detik, dan penundaan maksimum diatur ke 260 detik. Sumbu vertikal mewakili penundaan dalam detik yang terkait dengan masing-masing 10 kali pengiriman ulang. Sumbu horizontal mewakili jumlah pengiriman ulang, dari pengiriman ulang pertama hingga kesepuluh.

Waktu tunda untuk percobaan ulang selama fase backoff dari kebijakan pengiriman, diplot lebih dari 10 upaya coba lagi. Empat fungsi backoff yang berbeda—eksponensial, aritmatika, linier, dan geometrik—diilustrasikan dengan garis berwarna yang berbeda, masing-masing menunjukkan bagaimana penundaan meningkat dengan setiap percobaan ulang. Fungsi backoff eksponensial menunjukkan kenaikan paling curam, mencapai penundaan maksimum lebih cepat daripada yang lain, sedangkan fungsi linier meningkat pada tingkat yang stabil. Fungsi aritmatika dan geometris menunjukkan peningkatan keterlambatan yang moderat tetapi lebih curam daripada model linier. Setiap baris dimulai sekitar penundaan minimum 5 detik dan berlanjut menuju penundaan maksimum 260 detik dengan percobaan ulang kesepuluh.