Задњи притисак није грешка: то је карактеристика за изградњу отпорних система

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

На основу онога што је горе описано, чини се да увек треба да примењујемо повратни притисак, и не би требало да буде било какве дебате о томе.Da liTrebalo bi da primenimo povratni pritisak, ali uglavnom okoKakoда идентификују праве тачке за примену бацкпресс-а и механизме за његову примену који задовољавају специфичне услуге / пословне потребе.

Задњи притисак присиљава компромис између пролаза и стабилности, што је компликовано изазовом предвиђања оптерећења.

Identifying the Backpressure Points

Find Bottlenecks/Weak Links

Замислите систем у којем велика флота података (хиљаде домаћина) зависи од мале флоте контролних авиона (мање од 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.