API ilə işləyərkən sifariş dublikatları: səbəblər və müdafiə

Niyə dublikatlar bir hərəkətdən sonra yaranır

Panel sahibi düyməni bir dəfə basa və bir neçə eyni sifariş görə bilər: abunəçilər, baxışlar, reaksiyalar və ya digər xidmət üzrə. Adətən problem klikin özündə deyil, müştəri, API, verilənlər bazası və təchizatçı arasındakı zəncirdə olur.

Server nöqteyi-nəzərindən «bir sorğu» həmişə bir deyil. Müştəri cavab ala bilməyib, göndərişi təkrarlaya bilər, halbuki ilk əməliyyat artıq yadda saxlanılıb. Bəzən sifariş panelin bazasında bir dəfə yaradılır, lakin təchizatçıya iki dəfə gedir. Bunlar fərqli ssenarilərdir və fərqli şəkildə düzəldilir.

Taymaut sifarişin yaradılmadığı anlamına gəlmir

Ən çox rast gəlinən səbəb odur ki, müştəri cavabı məhdud müddət gözləyir. Server sorğunu qəbul edir, sifarişi yaradır, lakin müəyyən edilmiş taymautdan sonra cavab verir. Müştəri əməliyyatı uğursuz hesab edir və onu yenidən göndərir.

Nəticədə ilk sifariş artıq bazadadır, ikinci sorğu isə daha birini yaradır. Bu, xüsusilə xarici API-nin yavaş cavabı, həddindən artıq yüklənmiş növbə və ya servislər arasında qeyri-sabit əlaqə zamanı tez-tez baş verir.

Taymaut yalnız cavabın olmamasından danışır, sorğunun emal olunmamasından deyil.

Müştəri tərəfində avtomatik təkrarlar

HTTP sorğuları üçün kitabxanalar, fon tapşırıqları və inteqrasiya servisləri çox vaxt sorğunu avtomatik təkrarlayır. Buna səbəb əlaqə xətası, server cavab kodu, şəbəkə qırılması və ya çox uzun cavab ola bilər.

Təkrar özlüyündə faydalıdır: müvəqqəti nasazlıqlar zamanı itirilmiş sifarişlərin sayını azaldır. Bu yanaşmanın çatışmazlığı ondadır ki, təkrar emaldan müdafiə olmadan hər hansı şəbəkə qeyri-sabitliyini dublikatlara çevirir.

• təkrar saytın və ya botun kodunda işə düşə bilər;
• tapşırığı növbə yenidən başlada bilər;
• sorğunu proksi və ya inteqrasiya modulu təkrarlaya bilər;
• operator xətadan sonra sifarişi əl ilə yenidən göndərə bilər.

Təkrar sorğu ilk cavabdan əvvəl gəlir

Bəzən iki eyni sorğu həqiqətən API-yə demək olar ki, eyni vaxtda çatır. Məsələn, istifadəçi formu iki dəfə göndərib, frontend düyməni bloklamayıb və ya fon tapşırığı birincisi bitməmiş yenidən başlayıb.

Əgər emal edən əvvəlcə sifarişin mövcudluğunu yoxlayır, sonra onu yaradırsa, iki paralel əməliyyat yoxlamadan eyni vaxtda keçə bilər. Hər biri sifarişin hələ olmadığını görəcək və hər biri yeni qeyd əlavə edəcək.

Bu vəziyyət məlumat yarışı adlanır. Kodda sadə ilkin yoxlama bundan tam qorumur. Baza səviyyəsində məhdudiyyət olmadan yoxlamanın çatışmazlığı ondadır ki, paralel yük altında pozulur.

Sifariş yazıldı, lakin API cavabı itdi

Sorğu bir neçə mərhələdən keçir: server məlumatları alır, qeyd yaradır, tapşırığı növbəyə qoyur, cavab göndərir. Nasazlıq bunlardan hər hansı biri arasında baş verə bilər. Məsələn, baza artıq sifarişin yaradılmasını təsdiqləyib, lakin cavab müştəriyə ötürülməmiş əlaqə kəsilib.

Müştəri sifarişin qəbul edilib-edilmədiyini bilmir və əməliyyatı təkrarlayır. Ayrı yoxlama mexanizmi olmayan API sorğunu yeni kimi qəbul edir. Jurnalda bu, çox vaxt servisin iki sifarişi «özü» yaratdığı kimi görünür, halbuki ona iki daxil olan müraciət olub.

Sifariş yaratmaq üçün idempotent açar

Yaratma əməliyyatları üçün unikal idempotentlik açarı lazımdır. Müştəri onu ilk göndərişdən əvvəl yaradır və sifariş parametrləri ilə birlikdə ötürür. Taymaut və ya xəta səbəbindən təkrar zamanı eyni açardan istifadə olunur.

API açarı emal nəticəsi ilə birlikdə saxlayır. Əgər artıq məlum olan açarla sorğu gəlirsə, server yeni sifariş yaratmır, ilk müraciətin nəticəsini qaytarır: sifarişin identifikatorunu, statusunu və ya əvvəlcədən formalaşdırılmış xətanı.

Bir açar bir biznes əməliyyatına uyğun olmalıdır, bir HTTP bağlantısına deyil.

Metodun çatışmazlığı ondadır ki, açarları saxlamaq, qaydalara uyğun təmizləmək və API tərəfində yoxlamaq lazımdır. Əgər hər təkrar zamanı yeni açar yaradılarsa, müdafiə işləməyəcək. Əgər müxtəlif sifarişlər üçün bir açar istifadə olunarsa, yeni əməliyyatların bir hissəsi səhvən rədd ediləcək.

Unikallıq verilənlər bazası tərəfindən nəzarət edilməlidir

İdempotentliyi bazada unikallıq məhdudiyyəti ilə tamamlamaq daha yaxşıdır. Bunun üçün sifarişi birmənalı təsvir edən kombinasiya seçilir: müştərinin daxili identifikatoru, idempotentlik açarı, xidmət növü və digər lazımi sahələr.

Verilənlər bazası ikinci qeydi rədd etməlidir, hətta iki emal edən eyni vaxtda yaratmağa çatsa belə. Konfliktdən sonra API izahatsız xəta deyil, mövcud sifarişi qaytarır.

Sərt unikal məhdudiyyətin çatışmazlığı ondadır ki, onu yalnız link və ya username üzərində qurmaq olmaz. Müştəri eyni kanala bir xidməti qəsdən bir neçə dəfə sifariş edə bilər. Çox geniş məhdudiyyət normal təkrar alışları bloklayacaq.

Növbə tapşırığı birdən çox dəfə çatdıra bilər

Tapşırıq növbələri çox vaxt «ən azı bir dəfə çatdırma» prinsipi ilə işləyir. Əgər işçi tapşırığı emal edib, lakin onun yerinə yetirilməsini təsdiqləməyə vaxt tapmayıbsa, növbə həmin tapşırığı başqa işçiyə təkrar verə bilər.

Növbə üçün bu, tapşırığı itirməməyin normal üsuludur. İdempotentlik olmadan sifariş yaratmaq üçün isə dublikat mənbəyidir. Tapşırığın identifikatoru və ya ayrı əməliyyat açarı son emal edənə, o cümlədən sifarişin təchizatçıya göndərilməsi moduluna ötürülməlidir.

Təkrar çatdırmanın söndürülməsinin çatışmazlığı ondadır ki, işçi sıradan çıxanda sifarişlərin bir hissəsi itə bilər. Mümkün təkrarları qəbul etmək və emal edəni onlara davamlı etmək daha təhlükəsizdir.

Dublikatlar panel və təchizatçı arasında yaranır

Daxili sifariş bir dəfə yaradıla bilər, lakin xarici API-yə sorğu iki dəfə göndərilə bilər. Səbəb eynidir: panel təchizatçıdan cavab almayıb və göndərişi təkrarlamaq qərarına gəlib. Əgər təchizatçı ilk sorğunu qəbul etməyə çatıbsa, onun tərəfində iki eyni müraciət görünəcək.

Daxili sifarişin xaricinə ayrıca bağlantı lazımdır: göndəriş identifikatoru, idempotentlik açarı və ya saxlanılmış təchizatçı cavabı. Hesab etmək olmaz ki, öz panelinə girişdə müdafiə avtomatik olaraq gedən çağırışları qoruyacaq.

Xarici API ilə tutuşdurmanın çatışmazlığı ondadır ki, hər təchizatçı xarici açar üzrə axtarışı dəstəkləmir. Onda göndəriş cəhdlərini qeyd etmək və qeyri-müəyyən statusları ayrıca araşdırmaq lazım gəlir.

Vebhuk yeni sifariş yaratmamalıdır

Vebhuklar dəyişikliklər barədə məlumat verir: sifariş qəbul edilib, işə salınıb, yerinə yetirilib, ləğv edilib və ya yoxlama tələb edir. Xəta o zaman yaranır ki, vebhuk emal edəni bildirişi sifarişi yenidən yaratmaq əmri kimi qəbul edir.

Eyni vebhuk təkrar gələ bilər. Göndərən təsdiq almadıqda çatdırmanı təkrarlayır, bəzən isə bildirişlər sıra ilə gəlmir. Emal edən mövcud sifarişi xarici identifikator üzrə tapmalı və statusu yeniləməlidir.

Vebhukları yalnız alma vaxtına görə emal etməyin çatışmazlığı ondadır ki, gec gələn bildiriş aktual statusu köhnə ilə üzərinə yaza bilər. Hadisə identifikatoru, status versiyası və ya aydın keçid qaydaları lazımdır.

Hansı qeydlər dublikatların mənbəyini tapmağa kömək edəcək

Araşdırma üçün yalnız iki sifariş nömrəsini görmək kifayət deyil. Emalın hər mərhələsi barədə məlumat lazımdır: sorğunun vaxtı, idempotentlik açarı, müştərinin identifikatoru, sifariş parametrləri, fon tapşırığının nömrəsi, xarici API-nin cavabı və təkrar göndəriş cəhdləri.

• dublikatları yalnız linkə görə deyil, əməliyyat açarına görə tutuşdurun;
• daxil olan API jurnalında eyni sorğuların olub-olmadığını yoxlayın;
• tapşırığın növbədə təkrarlanıb-təkrarlanmadığına baxın;
• daxili sifarişin yaradılmasını təchizatçıya göndərişdən ayırın;
• xarici müraciətin identifikatorunu cavab alınan kimi saxlayın.

Çox qısa loqların çatışmazlığı ondadır ki, problemin mənbəyi araşdırılmağa çatmamış yox olur. Həddindən artıq loqlaşdırmanın çatışmazlığı isə qeydə tokenlərin, şəxsi məlumatların və digər həssas sahələrin düşə bilməsidir, ona görə onları maskalamaq lazımdır.

Sorğunun qeyri-müəyyən nəticəsini necə emal etmək olar

Taymautdan sonra sifarişi dərhal yeni məlumatlarla təkrar yaratmaq olmaz. Əvvəlcə API əməliyyatı idempotentlik açarı və ya müştəri identifikatoru üzrə yoxlamalıdır. Əgər sifariş tapılarsa, onun cari vəziyyəti qaytarılır. Əgər emal hələ davam edirsə, müştəri gözləmə statusu alır.

1. Əməliyyat açarını ilk sorğudan əvvəl yaradın.
2. Hər təkrar zamanı eyni açarı göndərin.
3. Açarı və sifarişi verilənlər bazasının bir qorunan əməliyyatında saxlayın.
4. Əməliyyatın identifikatorunu növbəyə və xarici API-yə ötürün.
5. Təkrar müraciət zamanı əvvəlcədən yaradılmış sifarişi qaytarın.

Belə ssenari API-nin və müştəri inteqrasiyasının təkmilləşdirilməsini tələb edir. Onun çatışmazlığı ondadır ki, sazlama daha mürəkkəbdir və sifariş halları daha çoxdur, lakin sorğunun təkrar çatdırılması artıq avtomatik olaraq təkrar alış demək deyil.