Ana səhifəBloqTracking API-nin miqyaslana bilməsi: Pik mövsüm həcmini, sorğu limitlərini və toplu qeydiyyatı necə idarə etmək olar

Tracking API-nin miqyaslana bilməsi: Pik mövsüm həcmini, sorğu limitlərini və toplu qeydiyyatı necə idarə etmək olar

17TRACK

Pik mövsümdə izləmə API-sini miqyaslandırmaq üçün göndərişlərin qeydiyyatını dayanıqlı növbənin arxasına keçirin, bütün işçilər arasında provayder limitlərinə əməl edin, yalnız sənədləşdirilmiş hədlər daxilində qruplaşdırma aparın və izləmə yeniləmələrini asinxron şəkildə emal edin. Qeydiyyat ötürmə qabiliyyətini, təkrar cəhd trafikini və vebhuk emalını ayrı-ayrı tutum problemləri kimi nəzərdən keçirin. Xaricə göndərilən sorğulara nəzarət etmədən daha çox işçi əlavə etmək, növbəni azaltmaq əvəzinə məhdudlaşdırmanı artıra bilər.

Tracking API Scalability How to Handle Peak Season Volume Rate

Sifarişlərin idarə edilməsi sistemini, anbar platformasını və ya e-ticarət backend-ini izləmə xidməti ilə birləşdirən mühəndislik komandaları üçün məqsəd sadəcə daha çox sorğu göndərmək deyil. Məqsəd göndərişləri müəyyən edilmiş vaxt pəncərəsi ərzində qeydiyyata almaq, trafik sıçrayışları zamanı yeniləmələri qorumaq və təkrarlanan iş yaratmadan uğursuzluqlardan bərpa olunmaqdır.

İş yükünü göndərişlər, sorğular və yeniləmələr əsasında ölçün

Gündəlik göndəriş həcmi inteqrasiyanın tutumunu müəyyənləşdirmək üçün kifayət deyil. Anbar izləmə nömrələrinin əksəriyyətini qısa göndəriş pəncərəsində buraxa bilər, status yeniləmələri isə gün ərzində daxil olur. Bu iş yüklərini ayrıca modelləşdirin.

  • Qeydiyyat daxilolmaları: İdxallar və anbar buraxılışı sıçrayışları da daxil olmaqla, saniyə və ya dəqiqə ərzində sisteminizə daxil olan yeni göndəriş qeydləri.
  • Xaricə API trafiki: Qeydiyyat sorğuları, axtarışlar, düzəlişlər, uzlaşdırma çağırışları və təkrar cəhdlər.
  • Daxil olan yeniləmə trafiki: Provayderin dəstəklədiyi hallarda vebhuk çatdırılmaları və yenidən çatdırılmalar.
  • Aşağı axın işi: Hər yeniləmə ilə işə düşən verilənlər bazasına yazılar, müştəri bildirişləri, analitika hadisələri və sifariş statusu dəyişiklikləri.

Daxili qeydiyyat məqsədi müəyyənləşdirin; məsələn, izləmə nömrəsini qəbul etdikdən onun qeydiyyatını təsdiqləyənədək məqbul olan maksimum vaxtı. Bunu izləmənin yenilənmə aktuallığından ayrı saxlayın: uğurlu qeydiyyat daşıyıcının skan məlumatının artıq mövcud olduğu demək deyil.

Effektiv qeydiyyat tutumunu hesablayın

Sorğu ilə məhdudlaşdırılan qeydiyyat endpoint-i üçün faydalı planlaşdırma əlaqəsi belədir:

Qeydiyyat tutumu = saniyədə icazə verilən sorğular × sorğu başına orta qeyd sayı × uğurlu qeydlərin payı

Bu, provayder zəmanəti deyil, planlaşdırma təxminidir. O, sorğu limitlərinin əsas məhdudiyyət olduğunu fərz edir. Qeyd əsaslı kvotalar, yük ölçüsü, gecikmə və ortaq hesab limitləri daha aşağı hədd müəyyən edə bilər.

Yalnız nümunə üçün fərz edək ki, inteqrasiyaya saniyədə iki qeydiyyat sorğusuna icazə verilir və hər sorğuda orta hesabla 30 qeyd göndərilir. Uğursuzluqlar və digər məhdudiyyətlər nəzərə alınmadan nominal tutum saniyədə 60 qeyd olur. Davamlı sıçrayış zamanı daxil olan qeydiyyatlar saniyədə orta hesabla 80 qeyddirsə, növbə saniyədə təxminən 20 qeyd sürəti ilə böyüyür. Bu rəqəmlər hipotetikdir və 17TRACK limitləri deyil.

Bərpa tutumunu da hesablayın. Yeni daxilolmalar λ sürəti ilə davam edirsə və effektiv emal tutumu μ-dürsə, mövcud B qeydlik növbənin boşaldılması, μ > λ olduqda, təxminən B / (μ − λ) saniyə çəkir. Emal tutumu daxilolmaları üstələmirsə, həmin şərtlər altında növbə boşalmayacaq.

Provayderin əslində nəyi məhdudlaşdırdığını təsdiqləyin

Sürət limiti və istifadə icazəsi fərqli problemləri həll edir. Sürət limiti sorğuların və ya qeydlərin nə qədər tez göndərilə biləcəyinə nəzarət edir. İstifadə icazəsi isə hesabın ödəniş və ya səlahiyyət müddəti ərzində nə qədər izləmə fəaliyyətindən istifadə edə biləcəyini məhdudlaşdıra bilər. Birinin altında qalmaq digərinə uyğunluğu təsdiq etmir.

İşçi sayını müəyyənləşdirməzdən əvvəl provayderin sənədlərinə və hesab şərtlərinizə əsasən aşağıdakıları təsdiqləyin:

  • Limitlərin hesab, API açarı, endpoint, IP ünvanı və ya başqa əhatə dairəsi üzrə tətbiq olunması.
  • Hesablanan vahidin sorğu, izləmə qeydi və ya başqa əməliyyat olması.
  • Endpoint-lərin ümumi limit paylaşması və ya müstəqil icazələrə malik olması.
  • Bir sorğuda icazə verilən maksimum qeyd sayı və yük ölçüsü.
  • Dublikat göndərişlərin, etibarsız qeydlərin və təkrar cəhdlərin istifadəyə necə təsir etməsi.
  • Cavabların məhdudlaşdırma məlumatını və ya təkrar cəhd təlimatını təqdim edib-etməməsi.
  • Kvotanın tükənməsinin müvəqqəti məhdudlaşdırmadan necə fərqlənməsi.

17TRACK inteqrasiyası üçün bu konfiqurasiyanın başlanğıc nöqtələri kimi rəsmi Tracking API səhifəsindən və API sənədlərindən istifadə edin. Yerləşdirmədən əvvəl tətbiq olunan endpoint davranışını və hesab limitlərini təsdiqləyin. Bu təlimatdakı nümunə tutumlar arxitektura təsvirləridir; 17TRACK səlahiyyətləri, qruplaşdırma ölçüləri və ya xidmət zəmanətləri barədə bəyanat deyil.

Sifariş emalı ilə qeydiyyat arasında dayanıqlı növbə yerləşdirin

Ödəniş prosesinin və ya anbar tamamlanmasının izləmə provayderinin qeydiyyatı qəbul etməsini gözləməsinə yol verməyin. Göndərişi lokal olaraq saxlayın, qeydiyyat tapşırığını dayanıqlı şəkildə qeydə alın və göndərişi arxa plan işçilərinin idarə etməsinə imkan verin.

Praktik axın belədir:

  1. Göndərişi və onun qeydiyyat niyyətini yadda saxlayın. Sifarişi yadda saxlayarkən arxa plan tapşırığını itirməmək üçün tranzaksiyalı outbox və ya ekvivalent dizayndan istifadə edin.
  2. Daxilolmaları yoxlayın və normallaşdırın. Başdakı sıfırlar da daxil olmaqla, izləmə nömrələrini sətir kimi qoruyun. Daşıyıcıya xas normallaşdırmanı yalnız əsaslandırıldığı halda tətbiq edin.
  3. Mövcud qeydiyyatı yoxlayın. Provayderə və məlumat modelinizə uyğun sabit identifikatordan istifadə edin.
  4. Uyğun qeydləri növbəyə əlavə edin. Cəhd sayını, növbəti uyğun təkrar cəhd vaxtını və diaqnostika üçün kifayət qədər konteksti saxlayın.
  5. Ortaq məhdudlaşdırıcı vasitəsilə göndərin. Tutumu xaricə sorğu göndərilməzdən dərhal əvvəl əldə edin.
  6. Qeyd səviyyəsində nəticələri saxlayın. Təsdiqlənmiş uğuru, təkrar cəhd edilə bilən uğursuzluğu, daimi rəddi və qeyri-müəyyən nəticələri ayırın.

Növbə sıçrayışı udur, lakin provayder tutumu yaratmır. Ən köhnə uyğun qeyd getdikcə köhnəlirsə, sadəcə işçi sayını artırmaq əvəzinə daxilolma sürəti ilə emal tutumu arasındakı fərqi araşdırın.

İşçilər arasında limitləri koordinasiya edin

Müstəqil işçilərin hər biri hesab üzrə tam icazədən istifadə edə biləcəyini düşünməməlidir. Koordinasiyalı sürət məhdudlaşdırıcısından və ya ortaq sorğu büdcəsi ayıran dispetçerdən istifadə edin. Planlaşdırılmış idxalları, əməliyyat skriptlərini və uzlaşdırma tapşırıqlarını da bu büdcəyə daxil edin.

Sürət və paralellik fərqli nəzarətlərdir. Məhdudlaşdırıcı sorğuların nə qədər tez başladığını, paralellik həddi isə eyni anda neçə sorğunun icrada qaldığını idarə edir. Provayder gecikməsi artdıqda hər ikisi faydalıdır. Paralelliyi artırmaq gecikmə ilə məhdudlaşan iş yükünə kömək edə bilər, lakin xaricə sorğu sürəti limitini aşa bilməz.

Qeyd səviyyəsində nəzarəti itirmədən toplu qeydiyyatdan istifadə edin

Endpoint bir sorğuda bir neçə qeydi dəstəkləyirsə, qruplaşdırma sorğu üzrə əlavə xərcləri azalda bilər. Bu, qeyd əsaslı istifadəni mütləq azaltmır və icazə verilən ən böyük qrup həmişə əməliyyat baxımından ən yaxşı seçim deyil.

Qrupları iki tətikdən istifadə etməklə yaradın: maksimum qeyd sayı və maksimum gözləmə müddəti. Bunlardan biri çatdıqda göndərin. Bu, sıx dövrlərdə qrupların səmərəli doldurulmasına, az həcmli trafikin isə qeyri-müəyyən müddət gözləməməsinə imkan verir.

  • Qeyd sayı ilə yanaşı yük limitlərinə də əməl edin. İstəyə bağlı metadata eyni ölçülü qrupları bayt baxımından çox fərqləndirə bilər.
  • Daxili qrup manifestini saxlayın. Hansı lokal göndəriş identifikatorlarının göndərildiyini qeydə alın və qaytarılan hər nəticəni düzgün əlaqələndirin.
  • Tətbiq səviyyəli nəticələri yoxlayın. HTTP uğur cavabı öz-özlüyündə hər qeydin qəbul edildiyini sübut etmir.
  • Yalnız təkrar cəhd tələb edən qeydləri yenidən göndərin. Uğurlu qeydlərin təkrar göndərilməsi lazımsız trafik yaradır və istifadəyə təsir göstərə bilər.
  • Daimi yoxlama uğursuzluqlarını düzəlişə yönləndirin. Dəyişdirilməmiş etibarsız yük təkrar cəhd növbəsində dövr etməməlidir.

Vaxt aşımı xüsusilə vacibdir: müştəriniz cavabı almasa da, provayder sorğunu qəbul etmiş ola bilər. Bu nəticəni qeyri-müəyyən kimi işarələyin. Mövcud olduğu halda, bunu dəstəklənən idempotentlik mexanizmi, sənədləşdirilmiş dublikat qeydiyyat qaydası və ya uzlaşdırma axtarışı ilə həll edin. Vaxtı bitmiş yazının uğursuz olduğunu düşünməyin.

Canlı trafiki tarixi idxallardan ayırın

Geri doldurma yeni göndərilmiş göndərişlər üçün lazım olan bütün tutumu istifadə etməməlidir. Çəkililəndirilmiş planlaşdırma və ya açıq tutum rezervləri ilə ayrı növbələrdən istifadə edin. Canlı qeydiyyatlar üçün minimum payı qoruyaraq idxalların boş tutumdan istifadəsinə icazə verin. Aşağı prioritetli qeydlərin nəhayət emal olunması üçün yaşlanma və ya başqa ədalət qaydasını tətbiq edin.

Təkrar cəhdləri idarə olunan, gecikdirilmiş və məhdud edin

HTTP 429 “Too Many Requests” deməkdir. RFC 6585 429 cavabının Retry-After başlığını ehtiva edə biləcəyini müəyyən edir. RFC 9110 bu başlığın dəyərini ya HTTP tarixi, ya da saniyələrlə gecikmə kimi müəyyən edir. Müştəri tam ədədin həmişə qaytarıldığını fərz etmək əvəzinə hər iki formu təhlil etməlidir.

Etibarlı təkrar cəhd gecikməsi təqdim edildikdə, müddət bitməmiş yenidən cəhd etməyin. Təkrar cəhd təlimatı yoxdursa, təsadüfilik əlavə edilmiş məhdudlaşdırılmış eksponensial geri çəkilmədən istifadə edin: cəhdlər arasındakı gecikməni tədricən artırın və işçilərin hamısının eyni anda təkrar cəhd etməməsi üçün təsadüfilik əlavə edin. Təkrar cəhdlər ilk cəhdlərlə eyni xarici məhdudlaşdırıcıdan keçməlidir.

Təkrar cəhd etməzdən əvvəl uğursuzluqları təsnif edin:

  • Məhdudlaşdırma: Təsirə məruz qalan işi gecikdirin və müvafiq limit əhatəsində göndəriş təzyiqini azaldın.
  • Müvəqqəti şəbəkə və ya server uğursuzluqları: Qeyri-müəyyən yazı nəticələrini nəzərə alaraq məhdudlaşdırılmış siyasət çərçivəsində təkrar cəhd edin.
  • Autentifikasiya və ya avtorizasiya uğursuzluqları: Etimadnamələr və ya icazələr düzəldilənədək xəbərdarlıq edin və təsirə məruz qalan işi dayandırın.
  • Yoxlama uğursuzluqları: Qeydi dəyişdirmədən yenidən göndərmək əvəzinə onu düzəldin və ya təcrid edin.
  • Tükənmiş istifadə icazəsi: Bunu qısa trafik sıçrayışı kimi qəbul etmək əvəzinə, sənədləşdirilmiş hesab həllinə əməl edin.

Həm cəhd limitini, həm də maksimum təkrar cəhd yaşını müəyyənləşdirin. Tükənmiş elementləri səbəb, məsul şəxs və yenidən oynatma proseduru ilə birlikdə ölü məktub növbəsinə köçürün. Əks halda köhnə uğursuzluqlar yeni göndərişlər üçün nəzərdə tutulan tutumu səssizcə istehlak edə bilər.

Vebhuk qəbulunu müstəqil şəkildə miqyaslandırın

Provayder uyğun vebhuklar təqdim edirsə, onlar təkrarlanan status sorğularını azalda bilər. Bununla yanaşı, yeniləmə sıçrayışları zamanı əlçatan qalmalı olan ayrıca daxil olan iş yükü yaradırlar.

Qəbul endpoint-ini məqsədyönlü saxlayın: provayderin sənədləşdirilmiş mexanizmindən istifadə etməklə sorğunu yoxlayın, hadisəni dayanıqlı şəkildə saxlayın və tələb olunan təsdiqi qaytarın. Sifariş dəyişikliklərini, analitikanı və müştəri mesajlarını asinxron emal edin. Hadisəni itirmək riski yaranacaqsa, dayanıqlı qəbuldan əvvəl qəbul təsdiqi verməyin.

Provayder müqaviləsində açıq şəkildə başqa cür müəyyən edilməyibsə, istehlakçıları dublikat çatdırılmaya dözümlü dizayn edin. Deduplykasiya üçün sənədləşdirilmiş sabit hadisə identifikatoruna üstünlük verin. Belə identifikator yoxdursa, kompozit identikliyi diqqətlə dizayn və test edin: yalnız status etiketindən istifadə fərqli hadisələri bir hadisədə birləşdirə bilər.

Həmçinin hadisələrin düzgün ardıcıllıqda gəlməməsindən qorunun. Hadisə tarixçəsini törədilmiş cari göndəriş vəziyyətindən ayrı saxlayın. Mövcud olduğu halda sənədləşdirilmiş hadisə vaxt möhürlərini və keçid qaydalarını tətbiq edin; gəlmə ardıcıllığının hadisə ardıcıllığı olduğunu və ya göndəriş statuslarının universal olaraq artan sıra təşkil etdiyini düşünməyin.

Uzlaşdırmanı məqsədyönlü və sürət məhdudiyyətli saxlayın. O, şübhəli çatdırılma boşluqlarını və ya qeyri-müəyyən qeydiyyatları araşdıra bilər, lakin hər göndərişi aqressiv şəkildə sorğulamaq vebhukların qarşısını almaq üçün nəzərdə tutulmuş xarici yükü yenidən yarada bilər.

Yalnız maksimum ötürmə qabiliyyətini deyil, bərpanı da test edin

Provayder simulyatorundan istifadə etməklə öz komponentlərinizə qarşı yük testləri aparın. Canlı provayderə əhəmiyyətli trafik göndərən testləri koordinasiya edin və səlahiyyət verilmiş limitlər daxilində qalın. Uğurlu test yalnız sistemin böyük sıçrayışı qəbul etdiyini deyil, pozuntudan sonra normal vəziyyətə qayıtdığını da göstərməlidir.

  • Anbar tipli sıçrayışı, ardınca davam edən normal trafiki təkrar yaradın.
  • Məhdudlaşdırma cavablarını, artmış gecikməni və müvəqqəti server uğursuzluqlarını daxil edin.
  • Qrupun qismən rədd edilməsini və server tərəfdə qəbuldan sonra baş verən vaxt aşımını simulyasiya edin.
  • Dublikat və düzgün ardıcıllıqda olmayan vebhuk hadisələri çatdırın.
  • Verilənlər bazasına çıxışı kəsin və qəbul edilməmiş hadisələrin yanlış təsdiqlənmədiyini yoxlayın.
  • Canlı qeydiyyatlarla yanaşı geri doldurma aparın və ədaləti yoxlayın.
  • Ölü məktub elementlərini sürət nəzarətlərini keçmədən yenidən oynadın.

Ən köhnə uyğun qeydiyyatın yaşını, qəbul gecikməsini, qeyd səviyyəsində uğur faizini, məhdudlaşdırma tezliyini, təkrar cəhd həcmini, vebhuk emal gecikməsini və ölü məktub artımını izləyin. Yalnız növbə dərinliyi kifayət deyil: böyük növbə sürətlə boşala bilər, kiçik növbədə isə dəfələrlə uğursuz olan bir neçə biznes baxımından kritik göndəriş ola bilər.

Pik mövsümdən əvvəl əməliyyat məsuliyyətini müəyyənləşdirin. Mühəndislik komandası göndəriş nəzarətlərinə və bərpa alətlərinə cavabdeh olmalıdır; inteqrasiya sahibi provayder səlahiyyətlərini təsdiqləməlidir; əməliyyatlar hansı göndərişlərə prioritet veriləcəyini müəyyən etməlidir. İdxalları nə vaxt dayandırmağı, əlavə tutum tələb etməyi və ya çatışmayan yeniləmələri araşdırmağı sənədləşdirin. Ən güclü dizayn trafik dərhal emal tutumunu aşdıqda belə proqnozlaşdırıla bilən olaraq qalan dizayndır.

FAQ

API açarlarının əlavə edilməsi ötürmə qabiliyyətini artıracaq?

Mütləq deyil. Bir neçə açar hesab səviyyəsində eyni icazəni paylaşa bilər. Limitin əhatə dairəsini və icazə verilən miqyaslandırma yanaşmasını provayderlə təsdiqləyin. Məhdudiyyətləri keçmək üçün açar rotasiyasından istifadə etməyin.

Hər qeydiyyatda mümkün olan ən böyük qrupdan istifadə edilməlidir?

Xeyr. Daha böyük qruplar sorğu səmərəliliyini artıra bilər, lakin onları doldurmağı gözləmək az həcmdə gecikməni artırır. Sənədləşdirilmiş ölçü həddi və boşaltma taymerindən istifadə edin, sonra ölçülmüş qəbul gecikməsinə və uğursuzluq davranışına əsasən tənzimləyin.

Vaxt aşımından sonra dublikat qeydiyyatların qarşısı necə alınır?

Dayanıqlı lokal göndəriş identikliyindən və provayderin sənədləşdirilmiş idempotentlik və ya dublikatların idarə olunması davranışından istifadə edin. Nəticə qeyri-müəyyən qalırsa, yenidən oynatmazdan əvvəl dəstəklənən yerdə uzlaşdırın. Yalnız lokal deduplikasiya uzaq sorğunun uğurlu olub-olmadığını sübut edə bilməz.

Uğurlu qeydiyyat izləmə məlumatlarının aktual olması deməkdir?

Xeyr. Qeydiyyatın qəbul edilməsi, daşıyıcı hadisəsinin əlçatanlığı, provayder emalı və öz yeniləmə emalınız ayrı mərhələlərdir. Onları ayrıca ölçün ki, gecikmiş daşıyıcı skanı qeydiyyat növbəsi ilə səhv salınmasın.

Komanda nə vaxt daha çox provayder tutumu tələb etməlidir?

Proqnozlaşdırılan daxilolmalar və tələb olunan bərpa müddəti qarşısı alına bilən təkrar cəhdlər, dublikat göndərişlər və səmərəsiz qruplaşdırma aradan qaldırıldıqdan sonra təsdiqlənmiş istifadə edilə bilən tutumu aşdıqda bunu tələb edin. Daha böyük icazə bloklanmış istehlakçını və ya verilənlər bazası darboğazını düzəltməyəcək, buna görə əvvəlcə əsas məhdudiyyəti müəyyənləşdirin.

Mənbələr

Loading