Visibility timeout — message queue’dan consumer olgan xabar boshqa consumerlarga vaqtincha ko‘rinmay turadigan muddatdir. Consumer shu vaqt ichida ishni tugatib, xabarni o‘chirishi yoki acknowledgement berishi kerak. Muddat tugasa va xabar yakunlanmagan bo‘lsa, u qayta ko‘rinib, boshqa consumer tomonidan yana olinishi mumkin.
Yetkazib berish modeli
Ko‘plab bulut navbatlari at-least-once yetkazib berishga yaqin ishlaydi. Xabar olingani uning muvaffaqiyatli qayta ishlanganini anglatmaydi. Consumer jarayoni qulash, tarmoq uzilishi yoki timeout sabab tasdiq bera olmasa, visibility timeout xabarni abadiy yo‘qolishdan saqlaydi. Buning evaziga bitta xabar bir necha marta bajarilishi ehtimoli mavjud.
Muddat juda qisqa bo‘lsa, birinchi consumer hali ishlayotgan paytda xabar qayta ko‘rinadi. Ikki consumer bir xil vazifani parallel bajarishi, resurslar ortiqcha sarflanishi yoki takroriy yon ta’sir yuz berishi mumkin. Juda uzun muddatda esa qulagan consumer olgan xabar qayta ishlanish uchun uzoq kutadi. Qiymat ish davomiyligi taqsimoti, xato aniqlash va tiklanish talabiga mos tanlanadi.
Muddatni uzaytirish
Davomiyligi oldindan noma’lum ishlar heartbeat yoki change visibility amali orqali muddatni uzaytirishi mumkin. Consumer vaqti-vaqti bilan egalikni yangilaydi, lekin umumiy maksimal vaqt va yangilash xatolari nazorat qilinadi. Jarayon osilib qolsa, cheksiz yangilash xabarni doim yashirin saqlab qo‘ymasligi kerak.
Uzoq ishni kichik, checkpoint qilinadigan bosqichlarga ajratish ko‘pincha yaxshiroq. Har bosqich natijasi saqlanadi va keyingi xabar yaratiladi. Shunda qayta urinish butun katta ishni emas, oxirgi tugallanmagan bosqichni takrorlaydi. Tashqi xizmat chaqirig‘i uchun alohida deadline visibility timeoutdan qisqaroq bo‘ladi va acknowledgement yuborishga vaqt qoldiradi.
Idempotency va kuzatuv
Consumer takroriy yetkazishni normal holat sifatida qabul qiladi. Ma’lumotlar bazasida xabar identifikatori bo‘yicha unique constraint, idempotency record yoki atomik holat o‘tishi qo‘llanadi. “Avval tekshir, keyin yoz” ikki alohida amal bo‘lsa race condition qoladi; deduplication tranzaksiya yoki shartli yozuv bilan bajariladi.
Metrikalarda delivery count, visibility muddatini uzaytirish, qayta ko‘ringan xabarlar, qayta ishlash vaqti va eng eski xabar yoshi kuzatiladi. Belgilangan urinishlardan keyin doimiy xato qilgan xabar dead-letter queue’ga o‘tkaziladi. Operator xabar mazmunidagi maxfiy ma’lumotni jurnalga to‘liq yozmasdan sababni tahlil qila olishi uchun trace identifikatori va xato turi saqlanadi.
+## Clock va receipt handle
Visibility muddati odatda klient soatiga emas, queue xizmatining qabul vaqti hamda server holatiga asoslanadi. Xabar har olinganda yangi receipt handle berilishi mumkin; eski handle bilan delete yuborish rad etiladi yoki eng yangi delivery’ni o‘chirmaydi. Consumer aynan joriy handle’ni ish kontekstida saqlaydi. Batch receive’da har xabarning ishlash muddati turlicha bo‘lsa, ularning visibility yangilanishi alohida boshqariladi. Jarayon graceful shutdown paytida yangi xabar olishni to‘xtatib, faol ishlarni tasdiqlashga urinadi; vaqt yetmasa lease’ni qisqartirib tezroq qayta ko‘rinishga imkon berishi mumkin. Queue semantikasi mahsulot hujjatida tekshiriladi.
Queue FIFO kafolat bersa ham, xabar qayta ko‘ringanda message group bloklanishi mumkin. Bitta sekin vazifa shu guruhdagi keyingi ishlarni ushlab turadi. Group kaliti yetarlicha taqsimlanadi, ammo bir obyektga tegishli amallar tartibi buzilmaydi.
Queue emulatori va haqiqiy xizmat semantikasi release sinovida alohida taqqoslanadi.
Bog‘liq tushunchalar
Message queue, Acknowledgement, At-least-once delivery, Idempotency, Dead-letter queue, Retry, Lease