Detail kebijakan dan ambang batas throttling - Simple Message Queue (formerly MNS)

Simple Message Queue (formerly MNS) menerapkan kebijakan throttling terhadap permintaan yang melebihi ambang batas untuk mencegah tekanan berlebihan pada sumber daya dasar. Memahami kebijakan ini membantu Anda merencanakan frekuensi pengiriman dan penerimaan pesan secara wajar serta mengambil tindakan tepat saat throttling dipicu.

Perilaku throttling

Saat lalu lintas mendekati atau mencapai ambang batas throttling, server secara otomatis dan elastis menyesuaikan ambang tersebut berdasarkan penggunaan sumber daya secara real-time. Dalam sebagian besar skenario, penyesuaian ini secara dinamis mendukung permintaan konkuren yang lebih tinggi tanpa disadari pengguna. Jika throttling sementara dipicu—misalnya karena lonjakan lalu lintas mendadak atau bottleneck sumber daya kluster—sistem memulihkan kapasitas pemrosesan lalu lintas dan secara sinkron menaikkan ambang batas setelah proses scale-out otomatis selesai.

Ketika throttling dipicu, sistem mengaktifkan mekanisme backpressure. Permintaan yang melebihi ambang batas akan ditahan sejenak di server, lalu mengembalikan error 429 (TooManyRequests). Durasi penahanan disesuaikan secara dinamis oleh server berdasarkan beban real-time, biasanya antara 10 hingga 500 milidetik, dengan maksimum 5 detik. Hal ini mencegah sistem kelebihan beban yang dapat memengaruhi kinerja dan stabilitas keseluruhan.

Kode kesalahan

Saat kebijakan throttling dipicu, server Simple Message Queue (formerly MNS) mengembalikan kode kesalahan berikut.

Kode status HTTPS	Kode kesalahan	Pesan kesalahan
429	TooManyRequests	The request is denied by cluster flow limiter for too many requests.

Ambang batas throttling

Kebijakan throttling konsumsi tidak normal dalam mode konsumsi antrian

Dalam pola konsumsi antrian standar, setelah klien berhasil memproses sebuah pesan, klien tersebut harus mengirim permintaan ke server untuk menghapus pesan tersebut. Jika klien berulang kali menunjukkan perilaku tidak standar berupa "menerima pesan tanpa mengirim permintaan penghapusan", sistem akan menandai hal ini sebagai konsumsi tidak normal dan memicu mekanisme throttling guna menjaga stabilitas sistem. Setelah throttling diterapkan, laju penerimaan pesan baru oleh klien tersebut akan berkurang secara signifikan.

Throttling dipicu ketika salah satu kondisi berikut terpenuhi:

Durasi: Konsumsi tidak normal berlangsung lebih dari 30 menit.
Jumlah pesan: Jumlah kumulatif pesan yang diterima namun tidak dihapus mencapai 5.000.
Laju trafik: Laju instan pesan yang diterima namun tidak dihapus melebihi 1.000 TPS.

Kebijakan throttling untuk permintaan bertrafik tinggi

Ambang batas throttling default per Akun Alibaba Cloud per wilayah adalah 20.000 TPS. Jika lalu lintas Anda melebihi 20.000 TPS, masuklah ke Konsol Quota Center untuk mengajukan peningkatan batas maksimum TPS per wilayah. Untuk langkah-langkah detail, lihat Submit an application to increase a quota.

Aturan penghitungan jumlah permintaan:

Setiap panggilan API dihitung sebagai satu permintaan.
Perhitungan TPS dalam skenario pengiriman batch: Saat Anda memanggil operasi BatchSendMessage terhadap sebuah antrian, TPS BatchSendMessage = jumlah aktual permintaan BatchSendMessage per detik × jumlah pesan per permintaan. Misalnya, jika BatchSendMessage dipanggil 100 kali per detik dan setiap panggilan berisi 10 pesan, maka TPS yang dikonsumsi oleh satu antrian = 100 × 10 = 1.000.
Perhitungan TPS dalam skenario konsumsi batch: Saat Anda memanggil operasi BatchReceiveMessage terhadap sebuah antrian, TPS BatchReceiveMessage = jumlah aktual permintaan BatchReceiveMessage per detik (tidak bergantung pada jumlah pesan per batch). Misalnya, jika BatchReceiveMessage dipanggil 100 kali per detik dan setiap panggilan berisi 10 pesan, maka TPS yang dikonsumsi oleh satu antrian = 100.

Hindari dampak throttling

Untuk menghindari dampak kebijakan throttling terhadap bisnis Anda, fokuslah pada dua aspek berikut:

Rencanakan lalu lintas dengan cermat dan komunikasikan lalu lintas puncak sebelumnya: Jika Anda memperkirakan pertumbuhan lalu lintas skala besar dan TPS melebihi nilai maksimum yang dapat diajukan di Konsol Quota Center, submit a ticket untuk menghubungi dukungan teknis guna memesan lebih banyak sumber daya dan menghindari pemicuan throttling.
Monitoring dan Peringatan: Kami menyarankan Anda mengintegrasikan Simple Message Queue (formerly MNS) dengan Create an alert rule. Pantau penggunaan TPS real-time setiap antrian atau topik di Konsol CloudMonitor (CloudMonitor console > Cloud Service Monitoring > Message Service MNS) untuk mendeteksi saat ambang batas throttling mulai didekati.

FAQ

Apakah layanan hanya mendukung 20.000 TPS?

Tidak. 20.000 TPS adalah nilai jaminan default. TPS aktual yang didukung bisa lebih tinggi, tergantung pada beban kluster dan kemampuan skalabilitas elastis.

Mengapa throttling kadang terjadi di atas 20.000 TPS namun tidak selalu?

Saat menentukan apakah akan memicu throttling, server menyediakan margin elastis tertentu. Sebagai contoh, dengan ambang batas throttling default 20.000 TPS, QPS aktual yang memicu throttling tidak selalu tepat 20.000, melainkan bisa sedikit lebih tinggi (misalnya, 20.000 hingga 20.200; rentang ini hanya ilustratif—rentang aktual disesuaikan secara dinamis). Namun, margin elastis ini bukan nilai tetap. Saat beban kluster tinggi, margin tersebut secara otomatis menyempit, dan dalam kasus ekstrem bahkan bisa berkurang hingga 0, sehingga throttling langsung dipicu begitu ambang batas tercapai.

Kami sangat menyarankan Anda mengonfigurasi peringatan berdasarkan nilai maksimum API atau watermark API untuk menghindari pemicuan throttling yang dapat memengaruhi bisnis melalui kegagalan pengiriman/penerimaan pesan. Referensi: Create an alert rule

API QPS maksimum per menit	MaxApiQpsPerUser
Persentase watermark API QPS	WatermarkOfApiQps
QPS maksimum Console API per menit	MaxConsoleApiQpsPerUser
Persentase watermark API QPS Konsol	WatermarkOfConsoleApiQps

Apakah throttling memengaruhi bisnis?

Throttling adalah mekanisme proteksi overload sistem yang dirancang untuk mencegah kluster kelebihan beban akibat lonjakan lalu lintas mendadak yang dapat memengaruhi stabilitas keseluruhan. Kami menyarankan klien menerapkan strategi retry eksponensial (exponential backoff) saat menerima error 429 (misalnya, interval bertahap 1d, 2d, dan 4d) untuk menghindari retry skala besar secara langsung yang justru memperparah tekanan.