Duplicate request — mijoz, vositachi yoki xabar yetkazish tizimi bir mantiqiy operatsiyani serverga bir necha marta yuborgan holat. So‘rovlarning baytma-bayt teng bo‘lishi shart emas: vaqt belgisi yoki transport sarlavhalari farq qilishi mumkin, ammo ular bir buyurtma, to‘lov yoki holat o‘zgarishini ifodalaydi. Dublikatni oddiy takroriy o‘qishdan ajratish muhim, chunki o‘zgartiruvchi amal ikki marta bajarilsa biznes holati buzilishi mumkin.
Paydo bo‘lish sabablari
Tarmoqda javob yo‘qolganida mijoz server so‘rovni bajargan-bajarmaganini bilmaydi. Timeoutdan keyingi retry asl so‘rov bilan birga serverga yetib borishi mumkin. Mobil ilovada tugmaning ikki marta bosilishi, reverse proxy qayta urinishi, xabar brokerining at-least-once yetkazishi yoki worker tasdiq yuborishdan oldin to‘xtashi ham dublikat hosil qiladi.
Parallel nusxalar bir-biridan keyin emas, ayni vaqtda kelishi mumkin. Shu sababli “oldin bajarilganmi” degan tekshiruv bilan “bajarildi” yozuvi orasida poyga holati mavjud. Faqat xotiradagi belgi bir nechta server instansiyasi yoki qayta ishga tushirishda yetarli emas.
Aniqlash mezonlari
Operatsiyaga mijoz yaratgan noyob identifikator berish eng aniq usullardan biridir. HTTP API da bu idempotency key, xabar tizimida event ID, biznes modelida esa tashqi buyurtma raqami bo‘lishi mumkin. Server identifikatorni foydalanuvchi yoki tenant doirasida saqlab, keyingi nusxani taniydi.
So‘rov mazmunidan hash hisoblash ba’zi hollarda yordam beradi, lekin umumiy yechim emas. Ikki qonuniy bir xil xarid bir xil hashga ega bo‘lishi, semantik jihatdan ayni operatsiya esa maydon tartibi yoki vaqt belgisi sabab boshqa hash berishi mumkin. Deduplication oynasi ham aniq belgilanishi kerak: identifikator abadiy saqlanmasa, muddati tugagach kelgan nusxa yangi so‘rov sifatida ko‘riladi.
Qayta ishlash strategiyalari
- idempotent operatsiya bir xil maqsad holatini qayta o‘rnatadi;
- unique constraint bir identifikator bilan ikkinchi yozuv yaratilishini atomik to‘xtatadi;
- server birinchi javobni saqlab, dublikatga o‘sha mantiqiy natijani qaytaradi;
- iste’molchi qayta ishlangan event ID larini deduplication jadvalida yuritadi;
- biznes kaliti, masalan invoice raqami, domen darajasidagi takrorni cheklaydi.
Tekshiruv va yozish bitta tranzaksiya yoki atomik amal ichida bajariladi. Birinchi so‘rov hali processing holatida bo‘lsa, ikkinchisiga vaqtinchalik status qaytarilishi mumkin. Birinchi jarayon muvaffaqiyatsiz tugaganida qayta bajarish mumkinmi yoki oldingi natija saqlanadimi — operatsiya semantikasiga bog‘liq.
Kuzatuv va xatolar
Jurnalda so‘rov identifikatori, birinchi qabul vaqti, qayta urinish soni va yakuniy holat saqlansa, dublikat manbai aniqlanadi. HTTP access logidagi bir xil endpointning takrori o‘zi yetarli dalil emas; kuzatuv identifikatori va domen natijasi bilan bog‘lash kerak. Dublikatlarni shunchaki xato sifatida rad etish ham har doim to‘g‘ri emas: mijoz birinchi natijani olmagan bo‘lishi mumkin. Barqaror API avvalgi muvaffaqiyatli natijani ma’noli tarzda qaytaradi.
Saqlash muddati
Deduplication yozuvi mijozning eng uzun qayta urinish davridan kam saqlanmasligi kerak. Muddati tugagach ayni identifikator yana kelishi mumkinligi API shartnomasida ko‘rsatiladi. To‘lov kabi yuqori xavfli amalda texnik kalitdan tashqari tranzaksiya raqamiga qo‘yilgan uzoq muddatli biznes cheklovi ham ishlatiladi. Kalitlar hajmi cheklangan, taxmin qilib bo‘lmaydigan formatda bo‘ladi va boshqa mijoz doirasidan qidirilmaydi. Eski yozuvlarni o‘chirish alohida audit va retention siyosati asosida bajariladi.
Bog‘liq tushunchalar
Idempotency key, Idempotent operation, Retry, Deduplication, Unique constraint, Race condition