Басты бетБлогБақылау API-інің масштабталуы: маусымдық шыңдағы көлемді, сұрау жиілігі шектеулерін және жаппай тіркеуді қалай басқаруға болады

Бақылау API-інің масштабталуы: маусымдық шыңдағы көлемді, сұрау жиілігі шектеулерін және жаппай тіркеуді қалай басқаруға болады

17TRACK

Ең жоғары маусымдағы жүктемеге бейімделу үшін tracking API жүйесінде жөнелтілімдерді тіркеуді сенімді кезекке орналастырыңыз, барлық worker арасында провайдер лимиттерін сақтаңыз, құжатталған шектер аясында ғана топтап өңдеңіз және tracking жаңартуларын асинхронды түрде өңдеңіз. Тіркеу өткізу қабілетін, қайталама сұраулар трафигін және webhook өңдеуін бөлек сыйымдылық мәселелері ретінде қарастырыңыз. Сыртқа жіберілетін сұрауларды бақыламай, worker санын көбейту кезектегі тапсырмаларды азайтудың орнына throttling деңгейін арттыруы мүмкін.

Tracking API Scalability How to Handle Peak Season Volume Rate

Тапсырыстарды басқару жүйесін, қойма платформасын немесе ecommerce backend жүйесін tracking қызметіне қосатын инженерлік командалар үшін мақсат жай ғана көбірек сұрау жіберу емес. Мақсат — жөнелтілімдерді белгіленген уақыт аралығында тіркеу, трафик күрт артқан кезде жаңартуларды сақтау және қайталанатын жұмысты тудырмай, қателерден қалпына келу.

Жұмыс көлемін жөнелтілімдер, сұраулар және жаңартулар бойынша есептеңіз

Интеграция көлемін есептеу үшін күнделікті жөнелтілім саны жеткіліксіз. Қойма tracking нөмірлерінің басым бөлігін қысқа жөнелту кезеңінде беруі мүмкін, ал мәртебе жаңартулары күні бойы келіп тұрады. Бұл жұмыс көлемдерін бөлек модельдеңіз.

  • Тіркеу келіп түсуі: импорттар мен қоймадан босату кезіндегі жүктеме толқындарын қоса алғанда, жүйеңізге секундына немесе минутына түсетін жаңа жөнелтілім жазбалары.
  • Сыртқа шығатын API трафигі: тіркеу сұраулары, іздеулер, түзетулер, салыстырып тексеру қоңыраулары және қайталама сұраулар.
  • Кіріс жаңарту трафигі: провайдер қолдаған жағдайда webhook жеткізілімдері мен қайта жеткізілімдері.
  • Кейінгі жұмыс: әр жаңарту іске қосатын дерекқорға жазу, клиенттерге хабарламалар, аналитикалық оқиғалар және тапсырыс мәртебесінің өзгерістері.

Тіркеудің ішкі мақсатын белгілеңіз, мысалы tracking нөмірін алған сәттен бастап оның тіркелгенін растауға дейінгі ең ұзақ рұқсат етілетін уақыт. Мұны tracking жаңалығы көрсеткішінен бөлек ұстаңыз: тіркеудің сәтті болуы тасымалдаушы сканерлеуі қолжетімді дегенді білдірмейді.

Тіркеудің тиімді сыйымдылығын есептеңіз

Сұраулармен шектелетін тіркеу endpoint-і үшін жоспарлауда мына қатынасты қолдануға болады:

Тіркеу сыйымдылығы = секундына рұқсат етілген сұраулар × бір сұраудағы орташа жазбалар саны × сәтті жазбалар үлесі

Бұл — провайдердің кепілдігі емес, жоспарлауға арналған бағалау. Ол негізгі шектеу сұраулар лимиті деп есептейді. Жазбаларға негізделген квоталар, payload көлемі, кідіріс және ортақ есептік жазба лимиттері бұдан төмен шекті белгілеуі мүмкін.

Тек мысал ретінде, интеграцияға секундына екі тіркеу сұрауына рұқсат беріліп, әр сұрауда орта есеппен 30 жазба жіберіледі делік. Сәтсіздіктер мен басқа шектеулерді есептемегендегі номиналды сыйымдылық секундына 60 жазбаны құрайды. Егер тұрақты жүктеме кезінде кіріс тіркеулер орта есеппен секундына 80 жазба болса, кезек шамамен секундына 20 жазбаға өседі. Бұл сандар гипотетикалық, олар 17TRACK лимиттері емес.

Қалпына келу сыйымдылығын да есептеңіз. Егер жаңа келіп түсулер λ жылдамдығымен жалғасып, тиімді өңдеу сыйымдылығы μ болса, B жазбадан тұратын бар кезек μ > λ болған жағдайда шамамен B / (μ − λ) секундта босайды. Егер өңдеу сыйымдылығы келіп түсулерден аспаса, мұндай жағдайларда кезек босамайды.

Провайдер нақты нені шектейтінін растаңыз

Rate limit пен пайдалану рұқсаты әртүрлі мәселелерді шешеді. Rate limit сұрауларды немесе жазбаларды қаншалықты жылдам жіберуге болатынын басқарады. Пайдалану рұқсаты есептік немесе құқық берілген кезең ішінде есептік жазба қанша tracking әрекетін тұтына алатынын шектеуі мүмкін. Бір шектен төмен болу екіншісіне сәйкестікті білдірмейді.

Worker санын белгілемес бұрын провайдердің құжаттамасы мен есептік жазба шарттарына сүйене отырып, мыналарды растаңыз:

  • Лимиттер есептік жазбаға, API кілтіне, endpoint-ке, IP мекенжайына немесе басқа ауқымға қатысты ма.
  • Есептелетін бірлік сұрау, tracking жазбасы немесе басқа операция ма.
  • Endpoint-тер бір лимитті бөлісе ме, әлде олардың рұқсаттары бөлек пе.
  • Бір сұрауда рұқсат етілетін жазбалар саны мен payload көлемі қанша.
  • Қайталанатын жіберулер, жарамсыз жазбалар және қайталама сұраулар пайдалануға қалай әсер етеді.
  • Жауаптар throttling туралы ақпаратты немесе қайталап көру жөніндегі нұсқауды бере ме.
  • Квотаның таусылуы уақытша throttling-тен несімен ерекшеленеді.

17TRACK интеграциясы үшін осы конфигурацияның бастапқы нүктесі ретінде ресми Tracking API бетін және API құжаттамасын пайдаланыңыз. Орналастыру алдында тиісті endpoint әрекетін және есептік жазба лимиттерін растаңыз. Бұл нұсқаулықтағы мысалдық сыйымдылықтар — архитектуралық иллюстрациялар; олар 17TRACK құқықтары, batch өлшемдері немесе қызмет кепілдіктері туралы мәлімдеме емес.

Тапсырыстарды өңдеу мен тіркеу арасына сенімді кезек қойыңыз

Checkout немесе қоймадағы аяқтау процесін tracking провайдері тіркеуді қабылдағанша күттірмеңіз. Жөнелтілімді жергілікті түрде сақтаңыз, тіркеу тапсырмасын сенімді түрде жазып қойыңыз және жіберуді фондық worker-лерге тапсырыңыз.

Практикалық ағым:

  1. Жөнелтілім мен оны тіркеу ниетін сақтаңыз. Тапсырысты сақтап, фондық тапсырманы жоғалтып алмау үшін transactional outbox немесе соған балама дизайн қолданыңыз.
  2. Кірістерді тексеріп, қалыпқа келтіріңіз. Tracking нөмірлерін бастапқы нөлдерін қоса жол ретінде сақтаңыз. Тасымалдаушыға тән қалыпқа келтіруді тек негіз болған кезде қолданыңыз.
  3. Бұрыннан бар тіркеуді тексеріңіз. Провайдерге және деректер моделіңізге сәйкес келетін тұрақты бірегейлікті пайдаланыңыз.
  4. Жарамды жазбаларды кезекке қойыңыз. Әрекет санын, келесі жарамды қайталау уақытын және диагностикаға жеткілікті контексті сақтаңыз.
  5. Ортақ limiter арқылы жіберіңіз. Сыртқа шығатын сұраудың дәл алдында сыйымдылықты алыңыз.
  6. Жазба деңгейіндегі нәтижелерді сақтаңыз. Расталған сәттілікті, қайталауға болатын қатені, тұрақты қабылдамауды және белгісіз нәтижелерді бөліңіз.

Кезек жүктеме толқынын сіңіреді, бірақ провайдердің сыйымдылығын жасамайды. Егер жарамды ең ескі жазба үнемі ескіріп бара жатса, worker санын жай ғана көбейтудің орнына келіп түсу жылдамдығы мен өңдеу сыйымдылығы арасындағы алшақтықты зерттеңіз.

Worker-лер арасындағы лимиттерді үйлестіріңіз

Жеке worker-лер әрқайсысы есептік жазбаның бүкіл рұқсат етілген көлемін пайдалана аламын деп есептемеуі тиіс. Үйлестірілген rate limiter немесе ортақ сұрау бюджетін бөлетін dispatcher қолданыңыз. Жоспарланған импорттарды, операциялық скрипттерді және салыстырып тексеру тапсырмаларын да осы бюджетке қосыңыз.

Rate пен concurrency — әртүрлі басқару құралдары. Limiter сұраулардың қаншалықты жиі басталатынын басқарады, ал concurrency шегі бір уақытта қанша сұраудың орындалып жатқанын басқарады. Провайдердің кідірісі өскенде екеуі де пайдалы. Concurrency-ді арттыру кідіріске тәуелді жұмысқа көмектесуі мүмкін, бірақ ол сыртқа шығатын rate limit-ті айналып өте алмайды.

Жазбалар деңгейіндегі бақылауды жоғалтпай bulk тіркеуді пайдаланыңыз

Endpoint бір сұрауда бірнеше жазбаны қолдаса, batch қолдану сұрау үстеме шығынын азайтуы мүмкін. Ол міндетті түрде жазбаларға негізделген пайдалануды азайтпайды, ал рұқсат етілген ең үлкен batch әрдайым операциялық тұрғыдан ең жақсы таңдау бола бермейді.

Batch-терді екі триггер арқылы құрыңыз: жазбалардың ең көп саны және күтудің ең көп уақыты. Екеуінің бірі орындалғанда жіберіңіз. Бұл қарбалас кезеңдерде batch-терді тиімді толтыруға мүмкіндік береді және аз көлемдегі трафикті шексіз күттірмейді.

  • Жазбалар санымен қатар payload лимиттерін де сақтаңыз. Қосымша метадеректер көлемі бірдей batch-тердің байт бойынша өте әртүрлі болуына әкелуі мүмкін.
  • Ішкі batch манифестін жүргізіңіз. Қай жергілікті жөнелтілім бірегейліктері жіберілгенін жазып, қайтарылған әр нәтижені тиісті жазбамен байланыстырыңыз.
  • Қолданбалық деңгейдегі нәтижелерді тексеріңіз. HTTP сәтті жауабының өзі әр жазбаның қабылданғанын дәлелдемейді.
  • Қайталауды қажет ететін жазбаларды ғана қайталаңыз. Сәтті жазбаларды қайта ойнату қажетсіз трафик тудырады және пайдалану салдары болуы мүмкін.
  • Тұрақты валидация қателерін түзетуге бағыттаңыз. Өзгермеген жарамсыз payload retry кезегі арқылы айналмауы тиіс.

Timeout ерекше маңызды: клиент жауап алмаса да, провайдер сұрауды қабылдап қойған болуы мүмкін. Мұндай нәтижені белгісіз деп белгілеңіз. Оны қолдау көрсетілетін idempotency механизмі, құжатталған қайталама тіркеу ережесі немесе қолжетімді болса, салыстырып тексеру арқылы анықтаңыз. Timeout болған жазу әрекеті сәтсіз болды деп есептемеңіз.

Нақты уақыттағы трафикті тарихи импорттардан бөліңіз

Backfill жаңадан жөнелтілген жөнелтілімдерге қажет барлық сыйымдылықты пайдаланбауы тиіс. Салмақталған жоспарлауы немесе сыйымдылықтың нақты резервтері бар бөлек кезектерді пайдаланыңыз. Импорттарға бос сыйымдылықты пайдалануға мүмкіндік беріңіз, бірақ нақты уақыттағы тіркеулер үшін ең төменгі үлесті сақтаңыз. Төмен басымдықтағы жазбалар ақырында өңделуі үшін aging немесе басқа әділдік ережесін қолданыңыз.

Қайталауларды бақыланатын, кешіктірілген және шектеулі етіңіз

HTTP 429 — “Too Many Requests” дегенді білдіреді. RFC 6585 құжатына сәйкес, 429 жауабында Retry-After тақырыбы болуы мүмкін. RFC 9110 бұл тақырып мәнін HTTP күні немесе секундпен берілген кідіріс ретінде анықтайды. Клиент бүтін сан әрдайым қайтарылады деп есептемей, екі пішінді де талдауы тиіс.

Жарамды қайталау кідірісі берілсе, оның мерзімі біткенше қайталамаңыз. Қайталау нұсқауы болмаса, jitter бар шектелген экспоненциалды backoff қолданыңыз: әрекеттер арасындағы кідірісті біртіндеп арттырып, worker-лердің бәрі бір уақытта қайталамауы үшін кездейсоқтық қосыңыз. Қайталаулар алғашқы әрекеттер сияқты сыртқа шығатын сол limiter арқылы өтуі тиіс.

Қайталаудан бұрын қателерді жіктеңіз:

  • Throttling: Зардап шеккен жұмысты кейінге қалдырып, тиісті лимит ауқымындағы жіберу қысымын азайтыңыз.
  • Уақытша желі немесе сервер қателері: Белгісіз жазу нәтижелерін ескере отырып, шектелген саясат бойынша қайталаңыз.
  • Аутентификация немесе авторизация қателері: Тіркелгі деректері немесе рұқсаттар түзетілгенше хабарлап, зардап шеккен жұмысты тоқтатыңыз.
  • Валидация қателері: Жазбаны өзгеріссіз қайта жіберудің орнына оны түзетіңіз немесе оқшаулаңыз.
  • Рұқсат етілген көлемнің таусылуы: Оны қысқа мерзімді трафик толқыны ретінде қарастырмай, құжатталған есептік жазба шешімін орындаңыз.

Әрекеттер санының лимитін де, қайталаудың ең ұзақ жасын да белгілеңіз. Шегі біткен элементтерді себебі, жауапты иесі және қайта ойнату процедурасы көрсетілген dead-letter кезегіне ауыстырыңыз. Әйтпесе ескі қателер жаңа жөнелтілімдерге арналған сыйымдылықты үнсіз тұтынуы мүмкін.

Webhook қабылдауын бөлек масштабтаңыз

Провайдер қолайлы webhook ұсынса, олар мәртебені қайталап сұрау қажеттілігін азайтады. Сонымен қатар олар жаңартулар күрт көбейген кезде қолжетімді болып қалуы тиіс бөлек кіріс жұмыс көлемін тудырады.

Қабылдау endpoint-ін негізгі міндеттерге бағыттаңыз: провайдердің құжатталған механизмі арқылы сұрауды тексеріңіз, оқиғаны сенімді түрде сақтаңыз және қажетті растауды қайтарыңыз. Тапсырыс өзгерістерін, аналитиканы және клиент хабарламаларын асинхронды түрде өңдеңіз. Оқиғаны сенімді қабылдау жоғалту қаупін тудырса, оны берік сақтамай тұрып қабылданғанын растауға болмайды.

Провайдер келісімінде өзгеше нақты көрсетілмесе, consumer-лерді қайталанатын жеткізілімдерге төзімді етіп жасаңыз. Дедупликация үшін құжатталған тұрақты оқиға идентификаторын таңдаңыз. Ондай идентификатор болмаса, құрамдас бірегейлікті мұқият жобалап, сынаңыз: тек мәртебе белгісін пайдалану әртүрлі оқиғаларды бір оқиғаға біріктіріп жіберуі мүмкін.

Сонымен қатар ретсіз келген жаңартулардан қорғаңыз. Оқиғалар тарихын туынды ағымдағы жөнелтілім күйінен бөлек сақтаңыз. Қолжетімді болған жағдайда құжатталған оқиға уақыт белгілері мен ауысу ережелерін қолданыңыз; келу реті оқиға реті деп немесе жөнелтілім мәртебелері әмбебап түрде өсе береді деп есептемеңіз.

Салыстырып тексеруді мақсатты және rate limit арқылы жүргізіңіз. Ол жеткізілімдегі күдікті үзілістерді немесе белгісіз тіркеулерді зерттей алады, бірақ әр жөнелтілімді агрессивті түрде сұрау webhook-тер болдырмауға тиіс болған сыртқа шығатын жүктемені қайта тудыруы мүмкін.

Тек ең жоғары өткізу қабілетін емес, қалпына келуді де сынаңыз

Провайдер симуляторы арқылы өз компоненттеріңізге жүктеме сынақтарын жүргізіңіз. Нақты провайдерге елеулі трафик жіберетін сынақтарды үйлестіріп, рұқсат етілген лимиттерден аспаңыз. Сәтті сынақ жүйенің үлкен жүктемені қабылдайтынын ғана емес, іркілістен кейін қалыпты күйге оралатынын да көрсетуі тиіс.

  • Қоймаға тән жүктеме толқынын, одан кейінгі қалыпты үздіксіз трафикті қайталаңыз.
  • Throttling жауаптарын, жоғарылаған кідірісті және уақытша сервер қателерін енгізіңіз.
  • Batch-тің ішінара қабылданбауын және сервер қабылдағаннан кейінгі timeout жағдайын модельдеңіз.
  • Қайталанатын және ретсіз webhook оқиғаларын жеткізіңіз.
  • Дерекқорға қолжетімділікті үзіп, қабылданбаған оқиғалардың қате расталмайтынын тексеріңіз.
  • Backfill-ді нақты уақыттағы тіркеулермен қатар жүргізіп, әділдікті тексеріңіз.
  • Dead-letter элементтерін rate control-дерді айналып өтпей қайта ойнатыңыз.

Жарамды тіркеулердің ең ескі жазбасының жасын, қабылдау кідірісін, жазба деңгейіндегі сәттілік деңгейін, throttling жиілігін, қайталау көлемін, webhook өңдеу кідірісін және dead-letter өсуін бақылаңыз. Кезек тереңдігінің өзі жеткіліксіз: үлкен кезек тез босатылуы мүмкін, ал шағын кезекте бірнеше рет сәтсіздікке ұшырайтын, бірақ бизнес үшін маңызды жөнелтілімдер болуы мүмкін.

Ең жоғары маусымға дейін операциялық жауапкершілікті бөліңіз. Engineering жіберу басқару элементтері мен қалпына келтіру құралдарына жауап берсін; интеграция иесі провайдер құқықтарын растауы тиіс; operations қай жөнелтілімдерге басымдық берілетінін анықтауы керек. Импорттарды қашан тоқтату, қосымша сыйымдылықты қашан сұрау немесе жоғалған жаңартуларды қашан зерттеу керегін құжаттаңыз. Ең мықты дизайн — трафик өзінің дереу өңдеу сыйымдылығынан асқанда да болжамды болып қалатын дизайн.

FAQ

API кілттерін қосу өткізу қабілетін арттыра ма?

Міндетті түрде емес. Бірнеше кілт есептік жазба деңгейіндегі ортақ рұқсатты пайдалануы мүмкін. Лимит ауқымын және рұқсат етілген масштабтау тәсілін провайдермен растаңыз. Шектеулерді айналып өту үшін кілттерді алмастырып пайдаланбаңыз.

Әр тіркеуде мүмкін болатын ең үлкен batch қолданылуы керек пе?

Жоқ. Үлкен batch сұрау тиімділігін арттыруы мүмкін, бірақ оларды толтыруды күту аз көлемде кідірісті арттырады. Құжатталған өлшем шегін және flush таймерін қолданыңыз, содан кейін нақты өлшенген қабылдау кідірісі мен қателер сипатына қарай реттеңіз.

Timeout-тан кейін қайталанатын тіркеулерді қалай болдырмауға болады?

Тұрақты жергілікті жөнелтілім бірегейлігін және провайдердің құжатталған idempotency немесе қайталануларды өңдеу әрекетін пайдаланыңыз. Нәтиже әлі де белгісіз болса, қайта ойнатудан бұрын қолдау көрсетілсе, оны салыстырып тексеріңіз. Жергілікті дедупликацияның өзі қашықтағы сұраудың сәтті болғанын дәлелдей алмайды.

Тіркеудің сәтті болуы tracking ақпаратының жаңартылғанын білдіре ме?

Жоқ. Тіркеуді қабылдау, тасымалдаушы оқиғасының қолжетімді болуы, провайдер өңдеуі және өзіңіздің жаңарту өңдеуіңіз — бөлек кезеңдер. Кешіккен тасымалдаушы сканерлеуін тіркеу кезегінің өсуі деп қателеспеу үшін оларды бөлек өлшеңіз.

Команда провайдерден қосымша сыйымдылықты қашан сұрауы керек?

Болжанған келіп түсулер мен қажетті қалпына келу уақыты болдырмауға болатын қайталауларды, қайталанатын жіберулерді және тиімсіз batch жасауды алып тастағаннан кейін тексерілген қолжетімді сыйымдылықтан асқанда сұраңыз. Үлкенірек рұқсат бұғатталған consumer немесе дерекқор тар жер мәселесін шешпейді, сондықтан алдымен шектеуші факторды анықтаңыз.

Sources

Loading