Simple Message Queue (formerly MNS)：Pesan terurut

Definisi fitur

Pesan terurut dalam Simple Message Queue (formerly MNS) menyediakan pengiriman first-in, first-out (FIFO) untuk pesan dalam kelompok yang sama, sehingga memastikan pesan diproses sesuai urutan yang dibutuhkan oleh skenario bisnis Anda.

Skenario

Pesan terurut ideal untuk skenario bisnis yang memerlukan pengurutan pesan secara ketat:

• Transisi status pesanan

  Dalam sistem pesanan e-commerce, status seperti pembuatan pesanan, pembayaran, pengiriman, dan konfirmasi penerimaan harus diproses secara kronologis agar status bisnis tetap akurat.

• Pemrosesan transaksi keuangan

  Dalam sistem perdagangan sekuritas dan saham, jika pesanan perdagangan memiliki harga penawaran yang sama, pesanan tersebut harus diproses berdasarkan prinsip penawaran pertama, perdagangan pertama. Sistem downstream harus memproses pesanan-pesanan ini sesuai urutan pemasukannya.

• Sinkronisasi database

  Database upstream melakukan operasi create, update, dan delete. Operasi tersebut dikirim sebagai log operasi biner dalam bentuk pesan ke sistem downstream. Sistem downstream menerapkan operasi ini dari pesan untuk memperbarui statusnya dan mencegah inkonsistensi data.

• Pencatatan log bisnis

  Log untuk operasi bisnis kritis harus disimpan dalam urutan kronologis yang ketat guna memudahkan audit dan troubleshooting di masa depan.

Konsep utama

• MessageGroupId: Pengidentifikasi untuk kelompok pesan. Sistem menggunakan ID kelompok ini untuk menjamin urutan pesan. Dalam MessageGroupId yang sama, pesan diproses secara berurutan ketat. Pesan dari kelompok berbeda dapat diproses secara paralel.

• Visibility Timeout: Setelah pesan berhasil ditarik, pesan tersebut menjadi tidak terlihat oleh konsumen lain hingga periode timeout berakhir. Ini mencegah pesan diproses oleh beberapa konsumen secara bersamaan. Jika pesan tidak dikonfirmasi untuk dihapus, pesan akan kembali terlihat setelah timeout berakhir.

• Mekanisme penguncian kelompok: Dalam antrian terurut, setelah pesan dengan MessageGroupId tertentu ditarik, pesan tersebut masuk ke status tidak terlihat dan memblokir pesan berikutnya yang memiliki MessageGroupId yang sama. Hal ini memastikan urutan konsumsi yang ketat. Pesan berikutnya dalam kelompok yang sama hanya dapat ditarik setelah pesan saat ini dihapus atau timeout visibilitasnya berakhir.

Perbedaan dari pesan normal

• Semantik pengurutan:

  • Pesan normal (antrian/topik standar): Menyediakan pengiriman at-least-once. Urutan tidak dijamin secara default.

  • Pesan terurut (antrian/topik terurut): Dalam MessageGroupId yang sama, pesan harus dikonsumsi dalam urutan ketat sesuai kedatangannya di server. Pesan hanya dapat dikonsumsi setelah pesan sebelumnya selesai diproses.

• Model konkurensi:

  • Pesan normal: Tidak ada batasan kelompok. Menekankan throughput keseluruhan.

  • Pesan terurut: Menggunakan MessageGroupId sebagai unit konkurensi. Pesan diproses secara serial dalam satu kelompok dan secara paralel antar kelompok.

• Persyaratan pesan:

  • Saat mengirim pesan terurut, Anda harus menentukan MessageGroupId. Aturan ini berlaku baik untuk antrian maupun topik.

Memulai

Instruksi API

Batasan

• Fitur ini saat ini tersedia di wilayah China (Shenzhen), China (Shanghai), dan China (Hangzhou). Untuk menggunakan pesan terurut di wilayah lain, submit a ticket.

• Group ID wajib: Saat mengirim pesan ke antrian atau topik terurut, Anda harus menyertakan MessageGroupId.

• Pencocokan tipe:

  • Antrian surat mati (DLQ): DLQ harus memiliki tipe yang sama dengan antrian sumbernya. Misalnya, antrian terurut hanya dapat disambungkan ke DLQ terurut, dan antrian standar hanya dapat disambungkan ke DLQ standar.

  • Langganan: Langganan untuk topik standar hanya dapat mendorong pesan ke antrian standar. Untuk memastikan urutan pesan, langganan untuk topik terurut harus mendorong pesan ke antrian terurut.

• Peek tidak didukung: Antrian terurut tidak mendukung API PeekMessage.

Praktik terbaik

• Desain kelompok:

  • Gunakan MessageGroupId yang stabil dan terdistribusi merata, seperti ID pesanan, untuk menghindari bottleneck performa akibat beberapa kelompok hot spot.

  • Untuk bisnis dengan hot spot ekstrem, pertimbangkan untuk membagi kelompok lebih lanjut di lapisan bisnis guna meningkatkan tingkat konkurensi.

• Visibility timeout: Atur timeout berdasarkan waktu pemrosesan aktual. Hal ini memastikan operasi bisnis selesai dan dikonfirmasi sebelum timeout berakhir, sehingga mengurangi kemungkinan pengiriman ulang.

• Idempotensi dan retry: Terapkan pemrosesan idempoten dan mekanisme retry pada konsumen untuk memastikan konsistensi end-to-end.

• Penarikan batch: Tingkatkan nilai numOfMessages untuk meningkatkan throughput, sekaligus memastikan penundaan pemrosesan untuk satu pesan tetap dapat diterima.

FAQ