Backpressure je skriveno pregovaranje između proizvođača i potrošača. Održavajte ga, a vaši sistemi graciozno skaliraju. Ignorišite ga, a oni se raspadaju pod vrhunskim opterećenjem. Backpressure je skriveno pregovaranje između proizvođača i potrošača. Održavajte ga, a vaši sistemi graciozno skaliraju. Ignorišite ga, a oni se raspadaju pod vrhunskim opterećenjem. Горе наведени цитат сугерише да чак и најтрајније и најбоље конструисане баште не могу издржати деструктивне силе неконтролисане и неконтролисане поплаве. , неконтролисани позивач често може преплавити цео систем и изазвати каскаду . Дистрибуирани систем neuspeh у а , Писао сам о томе како ретри олуја има потенцијал да одузме целу услугу ако не постоје одговарајуће страже.Овде, истражујем када услуга треба да размотри примјену повратног притиска на своје позиваче, како се може применити и шта позивачи могу учинити да се носе са њим. Prethodni članak Backpressure Бацкпресс Као што само име указује, бацк притисак је механизам у дистрибуираним системима који се односи на способност система да убрза брзину са којом се подаци конзумирају или производе како би се спречило преоптерећење самог себе или његових надолазних компоненти. Систем који примењује бацк притисак на свој позивач није увек експлицитан, као у облику убрзања или испуштања оптерећења, али понекад и имплицитан, као што је успоравање сопственог система додавањем кашњења захтевима који се служе без експлицитног знања о томе. И имплицитни и експлицитни повратни притисак намеравају да успоре позивача, било када се позивач не понаша добро или је сама услуга нездрава и треба време да се опорави. Need for Backpressure У овом примеру, ми градимо услугу контролног плана са три главне компоненте: фронтенд где се примају захтеви клијената, унутрашњи ред где су захтеви клијената буфер, и потрошачка апликација која чита поруке из редова и пише у базу података за упорност. Producer-Consumer Mismatch Неусклађеност произвођача и потрошача Размислите о сценарију у којем глумци / клијенти ударају на предњи крај са тако високом стопом да је или унутрашњи ред пун или радник који пише у базу података је заузет, што доводи до пуне редове. У том случају, захтеви се не могу укинути, тако да уместо пада захтева клијената, боље је унапред обавијестити купце. Овај неусклађеност може да се деси из различитих разлога, као што је експлозија у улазном саобраћају или мала грешка у систему где је потрошач био доле неко време, али сада мора да ради екстра да испразни бацклог акумулиран током његовог времена заустављања. Resource Constraints and Cascading Failures Ограничења ресурса и каскадни неуспеси Замислите сценарио у којем се ваш ред приближава 100% његовог капацитета, али је обично на 50%. Да бисте ускладили ово повећање у улазној стопи, повећате своју потрошачку апликацију и почните писати у базу података са већом стопом. Међутим, база података не може да се носи са овим повећањем (нпр. због лимита на писање / секунда) и разбија се. Овај слом ће срушити цео систем са њим и повећати Средње време за опоравак ( Примена бацк притиска на одговарајућим местима постаје критична у таквим сценаријама. МТР Missed SLAs Пропуштене славине Размислите о сценарију у којем се подаци написани у базу података обрађују сваких 5 минута, а друга апликација слуша да би се одржала ажурирана.Сада, ако систем није у стању да испуни тај СЛА из било ког разлога, као што је очекивање 90% пуно и потенцијално траје до 10 минута да се очисте све поруке, боље је прибегавати техникама бацкпресс-а. Možete da obavestite kupce da ćete propustiti SLA i zamolite ih da pokušaju ponovo kasnije, ili da primenite povratni pritisak tako što ćete odbaciti neurgentne zahteve iz reda kako biste zadovoljili SLA za kritične događaje / zahteve. Backpressure Challenges Backpressure izazovi На основу онога што је горе описано, чини се да увек треба да примењујемо повратни притисак, и не би требало да буде било какве дебате о томе. Trebalo bi da primenimo povratni pritisak, ali uglavnom oko да идентификују праве тачке за примену бацкпресс-а и механизме за његову примену који задовољавају специфичне услуге / пословне потребе. Da li Kako Задњи притисак присиљава компромис између пролаза и стабилности, што је компликовано изазовом предвиђања оптерећења. Identifying the Backpressure Points Find Bottlenecks/Weak Links Pronađi Bottlenecks / Slabe veze Замислите систем у којем велика флота података (хиљаде домаћина) зависи од мале флоте контролних авиона (мање од 5 домаћина) да прима конфигурације које трају у бази података, као што је истакнуто у горе наведеном дијаграму. Велика флота може лако преплавити малу флоту. У овом случају, да би се заштитила, мала флота треба да има механизме за примјену повратног притиска на позивача. Још једна уобичајена слаба веза у архитектури су централизоване компоненте које доносе одлуке о целом систему, као што су антиентропијски скенери. Use System Dynamics: Monitors/Metrics Коришћење Системска динамика: Монитори / Метрици Још један уобичајени начин за проналажење тачака за повратни притисак за ваш систем је да имате одговарајуће мониторе / метрике на месту. Континуирано пратите понашање система, укључујући дубине редова, коришћење ЦПУ / меморије и проток мреже.Користите ове податке у реалном времену да бисте идентификовали појављујуће препреке и прилагодили тачке повратног притиска. Креирање агрегатног погледа кроз метрике или посматраче као што су перформанси канарци преко различитих компоненти система је још један начин да знате да је ваш систем под стресом и треба да тврди бацк притисак на своје кориснике / позиваче. Ови перформанси канарци могу бити изоловани за различите аспекте система да би пронашли тачке удара. Такође, имати тастер у реалном времену о унутрашњој употреби ресурса је још један одличан начин да користите системску динамику да пронађете тачке од интереса и да будете проактивнији. Boundaries: The Principle of Least Astonishment Границе: Принцип најмањег изненађења Најочигледније ствари за купце су површине услуга са којима комуницирају. Ово су обично АПИ-ји које клијенти користе да би добили своје захтеве. Ово је такође место где ће клијенти бити најмање изненађени у случају повратног притиска, јер јасно истиче да је систем под стресом. То може бити у облику гутања или губитка оптерећења. Исти принцип се може применити унутар саме услуге преко различитих подкомпонента и интерфејса кроз које они комуницирају једни са другима. Ове површине су најбоља места за вршење повратног притиска. Ово може помоћи у минимизирању конфузије и учинити понашање система предвидивијим. How to Apply Backpressure in Distributed Systems Како применити Бацкпресс у дистрибуираним системима У последњем одељку, разговарали смо о томе како да пронађемо праве тачке од интереса за тврдњу повратног притиска.Када знамо те тачке, ево неких начина на које можемо тврдити овај повратни притисак у пракси: Изградите експлицитну контролу протока Идеја је да величина редова буде видљива вашим позивачима и дозволите им да контролишу стопу позива на основу тога. Знајући величину редова (или било који ресурс који је препрека у боци), они могу повећати или смањити стопу позива како би избегли преоптерећење система. Ова врста технике је нарочито корисна када више унутрашњих компоненти раде заједно и понашају се као што могу без утицаја једни на друге. Уједначење испод се може користити у било ком тренутку за израчунавање стопе позива. Напомена: Стварна стопа позива ће зависити од разних других фактора, али једначина испод треба да даје добру идеју. CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize)) CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize)) Invert Responsibilities U nekim sistemima, moguće je promeniti redosled gde pozivači ne šalju eksplicitno zahteve u uslugu, već dozvoljavaju da usluga zahteva radi sama kada je spremna za služenje. Ova vrsta tehnike daje uslugu koja prima punu kontrolu nad koliko može da uradi i može dinamički da menja veličinu zahteva na osnovu svog najnovijeg stanja. стратегија у којој примајућа услуга попуњава токен, а то говори позивачу када и колико могу послати на сервер. Токен Бакет # Service requests work if it has capacity if Tokens_available > 0: Work_request_size = min (Tokens_available, Work_request_size _max) # Request work, up to a maximum limit send_request_to_caller(Work_request_size) # Caller sends work if it has enough tokens if Tokens_available >= Work_request_size: send_work_to_service(Work_request_size) Tokens_available = Tokens_available – Work_request_size # Tokens are replenished at a certain rate Tokens_available = min (Tokens_available + Token_Refresh_Rate, Token_Bucket_size) Proactive Adjustments Понекад унапред знате да ће ваш систем ускоро бити преплављен, а ви предузимате проактивне мере као што је тражење позивача да успори волумен позива и полако га повећа. Tokom tog perioda, vi ste u redovima sa svim radom i sada ste spremni da ga ispraznite da biste zadovoljili svoje potrebe. Када га исцрпите брже од нормалне стопе, ризикујете да укинете услуге у наставку.Да бисте то решили, активно ограничавате лимите позивача или ангажујете позивача да смањи свој волумен позива и полако отворите поплаве. СЛА Throttling Ograničite broj zahteva koje usluga može da služi i odbacite zahteve iznad toga. Throttling se može primeniti na nivou usluge ili na nivou API. Ovo je direktan pokazatelj povratnog pritiska za pozivača da usporava volumen poziva. Možete to da uradite i da uradite prioriteti ili pravičnost da biste osigurali da kupci vide najmanji uticaj. Load Shedding Тхротлинг указује на одбацивање захтева када прекршите неке унапред дефинисане границе. Захтеви купаца и даље могу бити одбачени ако се служба суочи са стресом и одлучи да проактивно одбаци захтеве које је већ обећала да ће служити. Conclusion Закључак Backpressure je kritičan izazov u distribuiranim sistemima koji mogu značajno uticati na performanse i stabilnost. Razumevanje uzroka i efekata backpressure, zajedno sa efikasnim tehnikama upravljanja, ključno je za izgradnju robusnih i visokoučinkovitih distribuiranih sistema. Kada se pravilno implementira, backpressure može poboljšati stabilnost, pouzdanost i skalabilnost sistema, što dovodi do poboljšanog korisničkog iskustva. Međutim, ako se loše postupa, može da naruši poverenje kupaca, pa čak i da doprinese nestabilnosti sistema. Proaktivno rešavanje problema sa backpresom kroz pažljiv dizajn i praćenje sistema je ključ za održavanje zdravlja sistema. Dok uvođenje backpresura može da uključuje kompromise, kao što je potencijalno uticanje na prodajni kapacitet, prednosti u pogledu ukupne otpornosti sistema i zadovoljstva korisnika su značajne.
