Bagikan melalui

Pengiriman push pesan dan coba lagi dengan topik namespace

  • Artikel

Pengiriman push namespace Event Grid menyediakan pengiriman yang tahan lama. Event Grid mencoba mengirimkan setiap pesan setidaknya sekali untuk setiap langganan yang cocok segera. Jika titik akhir pelanggan tidak mengakui penerimaan suatu peristiwa atau jika terjadi kegagalan, Event Grid mencoba lagi pengiriman berdasarkan jadwal coba lagi dan kebijakan coba lagi yang ditetapkan. Secara default, Event Grid mengirimkan satu per satu ke pelanggan.

Catatan

Event Grid tidak menjamin susunan untuk pengiriman acara, jadi pelanggan mungkin menerimanya tidak sesuai susunan.

Langganan peristiwa

Langganan peristiwa adalah sumber daya konfigurasi yang terkait dengan topik namespace layanan tunggal. Antara lain, Anda menggunakan langganan peristiwa untuk mengatur kriteria pemilihan peristiwa untuk menentukan koleksi peristiwa yang tersedia untuk pelanggan dari kumpulan total peristiwa yang tersedia dalam topik. Dengan menggunakan langganan peristiwa, Anda juga menentukan titik akhir tujuan tempat peristiwa dikirim. Selain itu, langganan peristiwa memungkinkan Anda mengatur properti lain, seperti jumlah coba lagi pengiriman maksimum dan waktu acara untuk ditayangkan, yang menentukan perilaku runtime pengiriman peristiwa.

Jadwal percobaan kembali

Ketika Event Grid menerima kesalahan untuk upaya pengiriman peristiwa, Event Grid memutuskan apakah event Grid harus mencoba kembali pengiriman berdasarkan jenis kesalahan.

Jika kesalahan yang dikembalikan oleh titik akhir berlangganan adalah kesalahan terkait konfigurasi yang tidak dapat diperbaiki dengan percobaan ulang, Event Grid mengirimkan peristiwa ke tujuan surat mati yang dikonfigurasi. Jika tidak ada surat mati yang dikonfigurasi, peristiwa akan dihilangkan. Misalnya, peristiwa di-dead-letter atau dihilangkan saat titik akhir yang dikonfigurasi pada langganan peristiwa tidak dapat dicapai karena dihapus. Percobaan ulang pengiriman tidak terjadi untuk kondisi dan kesalahan berikut:

Kondisi:

  • ArgumentException
  • TimeoutException
  • UnauthorizedAccessException
  • OperationCanceledException
  • SocketException |

Kode kesalahan

  • 404 - NotFound
  • 401 - Unauthorized
  • 403 - Forbidden
  • 400 -BadRequest
  • 414 RequestUriTooLong

Catatan

Jika dead-letter tidak dikonfigurasi untuk titik akhir, peristiwa akan dihilangkan saat kesalahan atau kondisi di atas terjadi. Pertimbangkan untuk mengonfigurasi dead-letter pada langganan peristiwa Jika Anda tidak ingin peristiwa semacam ini dihilangkan. Peristiwa surat mati akan dihilangkan ketika tujuan surat mati tidak ditemukan.

Jika kondisi atau kesalahan yang dikembalikan oleh titik akhir berlangganan tidak termasuk dalam daftar di atas, Event Grid mencoba kembali berdasarkan upaya dasar menggunakan jadwal coba lagi backoff eksponensial berikut:

  • 0 detik (segera coba lagi)
  • 10 detik
  • 30 detik
  • 1 menit
  • 5 menit

Setelah 5 menit, Event Grid terus mencoba lagi setiap 5 menit hingga peristiwa dikirimkan atau jumlah percobaan kembali maksimum atau waktu aktif peristiwa tercapai.

Kebijakan percobaan kembali

Anda dapat menyesuaikan kebijakan coba lagi dengan menggunakan dua properti konfigurasi langganan peristiwa berikut. Peristiwa dihilangkan (tidak ada surat mati yang dikonfigurasi) atau surat gagal jika salah satu properti mencapai batas yang dikonfigurasi.

  • Jumlah pengiriman maksimum - Nilai harus berupa bilangan bulat antara 1 dan 10. Nilai defaultnya adalah 10. Untuk pengiriman push, properti ini mendefinisikan upaya pengiriman maksimum.
  • Retensi - Properti ini juga dikenal sebagai event time to live. Nilai harus berupa nilai durasi ISO 8601 dengan presisi menit. Mulai dari waktu peristiwa diterbitkan, properti ini menentukan rentang waktu setelah pesan kedaluwarsa. Nilai minimum yang diizinkan adalah "PT1M" (1 menit). Nilai maksimum yang diizinkan adalah 7 hari atau waktu retensi topik yang mendasar, mana pun yang lebih rendah. portal Azure memberikan pengalaman pengguna sederhana di mana Anda menentukan hari, jam, dan menit sebagai bilangan bulat.

Catatan

Jika Anda mengatur Retention dan Maximum delivery count, Event Grid menggunakannya untuk menentukan kapan harus menghentikan pengiriman peristiwa. Salah satu menghentikan pengiriman peristiwa. Misalnya, jika Anda menetapkan 20 menit sebagai retensi dan 10 upaya pengiriman maksimum, itu berarti bahwa ketika peristiwa tidak dikirimkan setelah 20 menit atau tidak dikirimkan setelah 10 upaya, mana pun yang terjadi terlebih dahulu, peristiwa akan dihentikan. Namun, karena jadwal coba lagi, mengatur jumlah maksimum upaya pengiriman menjadi 10 tidak berdampak karena peristiwa akan di-dead-letter terlebih dahulu setelah 20 menit. Hal ini disebabkan oleh fakta pada menit 20, upaya pengiriman #8 (0, 10s, 30s, 1m, 5m, 10m, 15m, 20m) terjadi, tetapi pada saat itu peristiwa tersebut surat mati.

Pembuatan batch output

Saat Anda menggunakan Webhook sebagai jenis titik akhir tujuan, Event Grid default mengirimkan setiap peristiwa satu per satu ke pelanggan. Anda dapat mengonfigurasi Event Grid ke peristiwa batch untuk pengiriman untuk meningkatkan performa HTTP dalam skenario throughput tinggi. Batching dinonaktifkan secara default dan dapat diaktifkan per langganan peristiwa.

Saat menggunakan Azure Event Hubs sebagai jenis titik akhir tujuan, Event Grid selalu membuat batch peristiwa untuk efisiensi dan performa maksimum. Tidak ada konfigurasi kebijakan batch yang tersedia karena secara default Event Grid menangani perilaku batching saat mengirimkan ke Azure Event Hubs.

Kebijakan batching

Pengiriman dalam batch memiliki dua pengaturan:

  • Peristiwa maks per batch - Jumlah maksimum peristiwa yang dikirimkan Event Grid per batch. Nilai harus berupa bilangan bulat antara 1 dan 5.000. Jumlah ini tidak pernah terlampaui. Namun, lebih sedikit peristiwa dapat dikirimkan jika tidak ada lagi peristiwa yang tersedia pada saat pengiriman. Azure Event Grid tidak menunda acara untuk membuat batch jika lebih sedikit acara yang tersedia.
  • Ukuran batch pilihan dalam kilobyte - Ceiling target untuk ukuran batch dalam kilobyte. Nilai harus berupa angka antara 1 dan 1024. Mirip dengan peristiwa maks, ukuran batch mungkin lebih kecil jika peristiwa yang cukup tidak tersedia pada saat pengiriman. Ada kemungkinan bahwa batch lebih besar dari ukuran batch pilihan jika suatu acara lebih besar dari ukuran pilihan. Misalnya, jika ukuran yang disukai adalah 4Kb dan peristiwa 10Kb didorong ke Event Grid, peristiwa 10Kb dikirimkan daripada dihilangkan.

Pengiriman batch dikonfigurasi berdasarkan langganan per peristiwa melalui portal, CLI, PowerShell, atau SDK.

Perilaku batching

  • Semua atau tidak ada

    Event Grid beroperasi dengan semantik semua atau tidak ada. Ini tidak mendukung keberhasilan parsial dari pengiriman batch. Pelanggan harus berhati-hati untuk hanya meminta peristiwa sebanyak mungkin per batch karena dapat ditangani secara wajar dalam 30 detik.

  • Batching optimis

    Pengaturan kebijakan batching tidak terikat ketat pada perilaku batching, dan dihormati berdasarkan upaya terbaik. Pada tingkat peristiwa rendah, Anda sering mengamati ukuran batch kurang dari peristiwa maksimum yang diminta per batch.

  • Asali disetel ke NONAKTIF

    Secara default, Event Grid hanya menambahkan satu peristiwa ke setiap permintaan pengiriman. Cara mengaktifkan batching adalah dengan mengatur salah satu pengaturan yang disebutkan dalam kebijakan Batching.

  • Nilai default

    Tidak perlu menentukan kedua pengaturan (Peristiwa maksimum per batch dan Perkiraan ukuran batch dalam kilo byte) saat membuat langganan peristiwa. Jika hanya satu pengaturan yang diatur, Event Grid menggunakan nilai default. Lihat bagian berikut untuk nilai default, dan cara menggantinya.

Portal Azure

Anda melihat pengaturan ini pada tab Fitur Tambahan di halaman Langganan Peristiwa atau setelah langganan peristiwa dibuat, pada opsi menu Konfigurasi saat mengakses Langganan Peristiwa.

Cuplikan layar menabur tab Fitur Tambahan dari halaman Langganan Peristiwa dengan bagian Batching disorot.

Kejadian Surat gagal

Ketika Event Grid tidak dapat mengirimkan peristiwa dalam periode waktu tertentu atau setelah mencoba mengirimkan peristiwa beberapa kali, Event Grid mengirimkan peristiwa ke akun penyimpanan. Proses ini dikenal sebagai surat gagal. Azure Event Grid melakukan surat gagal pada suatu acara ketika salah satu kondisi berikut terpenuhi.

  • Peristiwa tidak dikirimkan dalam periode time-to-live (retensi yang ditentukan dalam langganan peristiwa).
  • Jumlah percobaan untuk mengirimkan acara telah melebihi batas.

Jika terpenuhi, peristiwa akan dihilangkan atau dihentikan. Secara default, Azure Event Grid tidak mengaktifkan surat gagal. Untuk mengaktifkannya, Anda harus menentukan akun penyimpanan untuk menyimpan acara yang tidak terkirim saat membuat langganan acara. Anda membaca peristiwa dari akun penyimpanan ini untuk menyelesaikan pengiriman.

Azure Event Grid mengirimkan acara ke lokasi surat gagal ketika telah mencoba semua upaya coba lagi. Jika Azure Event Grid menerima kode respons 400 (Permintaan Buruk) atau 413 (Meminta Entitas yang Terlalu Besar), Azure Event Grid tersebut akan segera menjadwalkan acara untuk surat gagal. Kode respons ini menunjukkan pengiriman acara tidak akan pernah berhasil.

Kedaluwarsa time-to-live HANYA dicentang pada pengiriman terjadwal berikutnya. Jadi, bahkan jika time-to-live kedaluwarsa sebelum upaya pengiriman terjadwal berikutnya, kedaluwarsa acara hanya dicentang pada saat pengiriman berikutnya dan kemudian disurat-gagalkan.

Ada penundaan lima menit antara upaya terakhir untuk menyampaikan suatu peristiwa dan saat peristiwa dikirim ke lokasi dead-letter. Penundaan ini dimaksudkan untuk mengurangi jumlah operasi penyimpanan Blob. Jika lokasi surat gagal tidak tersedia selama empat jam, acara akan dihapuskan.

Sebelum mengatur lokasi surat gagal, Anda harus memiliki akun penyimpanan dengan kontainer. Anda memberikan titik akhir untuk kontainer ini saat membuat langganan acara. Titik akhir tersebut menggunakan format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Anda mungkin ingin diberitahu ketika sebuah acara telah dikirim ke lokasi surat gagal. Untuk menggunakan Azure Event Grid guna merespons acara yang terkirim, buat langganan acara untuk penyimpanan blob surat gagal. Setiap kali penyimpanan blob surat gagal menerima acara yang tidak terkirim, Azure Event Grid memberi tahu penghandel Anda. Penghandel merespons dengan tindakan yang ingin Anda lakukan untuk menyesuaikan acara yang tidak terkirim.

Saat mengonfigurasi dead-lettering, Anda perlu menambahkan identitas terkelola ke peran kontrol akses berbasis peran (RBAC) yang sesuai pada akun Azure Storage yang akan menyimpan peristiwa surat gagal. Untuk informasi selengkapnya, lihat Tujuan yang didukung dan peran Azure.

Format pengiriman acara

Bagian ini memberi Anda contoh peristiwa dan peristiwa surat gagal menggunakan skema CloudEvents 1.0, format metadata pesan yang didukung dalam topik namespace layanan.

Skema CloudEvents 1.0

Kejadian

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Kejadian Surat gagal

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Masa Percobaan

Langganan peristiwa dimasukkan ke dalam masa percobaan oleh Event Grid selama beberapa waktu jika pengiriman peristiwa ke tujuan mulai gagal. Waktu percobaan berbeda untuk kesalahan lain yang ditampilkan oleh titik akhir tujuan. Jika langganan peristiwa sedang dalam masa percobaan, peristiwa mungkin akan gagal atau dibatalkan bahkan tanpa mencoba pengiriman, bergantung pada kode kesalahan yang menyebabkannya dalam masa percobaan.

Kesalahan Durasi Masa Percobaan
Sibuk 10 detik
NotFound 5 menit
SocketError 30 detik
ResolutionError 5 menit
Nonaktif 5 menit
Penuh 5 menit
TimedOut 10 detik
Tidak diizinkan 5 menit
Terlarang 5 menit
InvalidAzureFunctionDestination 10 menit

Catatan

Event Grid menggunakan masa percobaan untuk manajemen pengiriman yang lebih baik dan durasinya mungkin dapat berubah di masa mendatang.

Status pengiriman pesan

Event Grid menggunakan kode respons HTTP untuk menyetujui penerimaan acara.

Kode keberhasilan

Azure Event Grid hanya mempertimbangkan kode respons HTTP berikut sebagai pengiriman yang berhasil. Semua kode status lainnya dianggap sebagai pengiriman yang gagal dan akan dicoba kembali atau di-dead-letter sebagaimana mewajibkan. Saat menerima kode status yang berhasil, Event Grid menganggap pengiriman selesai.

  • 200 OK
  • 201 - Dibuat
  • 202 Diterima
  • 203 Informasi Non-Otoritatif
  • 204 Tidak Ada Konten

Kode kegagalan

Semua kode lain yang tidak ada dalam set di atas (200-204) dianggap gagal dan akan dicoba kembali, jika diperlukan. Beberapa memiliki kebijakan percobaan kembali khusus yang terkait dengan kebijakan yang diuraikan di bawah ini, yang lain mengikuti jadwal coba lagi standar. Penting untuk diingat bahwa karena sifat arsitektur Azure Event Grid yang sangat paralel, perilaku percobaan ulang bersifat non-deterministik.

Kode status Perilaku percobaan kembali
400 Permintaan Buruk Tidak dicoba
401 Tidak Sah Percobaan ulang setelah 5 menit atau lebih untuk Titik Akhir Sumber Daya Azure
403 Dilarang Tidak dicoba
404 Tidak ditemukan Percobaan ulang setelah 5 menit atau lebih untuk Titik Akhir Sumber Daya Azure
408 Waktu Permintaan Habis Percobaan ulang setelah 2 menit atau lebih
Entitas Permintaan 413 Terlalu Besar Tidak dicoba
503 Layanan Tidak Tersedia Percobaan ulang setelah 30 detik atau lebih
Semua lainnya Percobaan ulang setelah 10 detik atau lebih

Properti pengiriman kustom

Langganan kejadian memungkinkan Anda menyiapkan header HTTP yang disertakan dalam kejadian terkikis. Kapabilitas ini memungkinkan Anda untuk mengatur header kustom yang diperlukan oleh tujuan. Anda bisa menyiapkan hingga 10 header saat membuat langganan kejadian. Setiap nilai header tidak boleh lebih besar dari 4.096 (4K) byte. Anda bisa mengatur header kustom pada kejadian yang dikirimkan ke tujuan berikut:

  • Webhook
  • Azure Event Hubs

Langkah berikutnya