Programmēšana

Kā Redis izmantot reāllaika mērīšanas lietojumprogrammām

Roshans Kumars ir Redis Labs vecākais produktu vadītājs.

Mērīšana nav tikai vienkārša skaitīšanas problēma. Mērīšanu bieži sajauc ar mērīšanu, taču tas parasti ir vairāk. Mērīšana ietver mērīšanu, bet kā nepārtrauktu procesu, parasti ar mērķi regulēt resursu izmantošanu vai plūsmu laika gaitā. Mūsdienu lietojumprogrammās mērīšana ir ietverta daudzos dažādos veidos, sākot no cilvēku, objektu vai notikumu skaitīšanas līdz lietojuma regulēšanai, piekļuves kontrolei un jaudas piešķiršanai.

Mērīšanas risinājumiem parasti jāapstrādā liels datu apjoms, vienlaikus ievērojot stingrās veiktspējas prasības. Atkarībā no risinājuma mēroga skaitīšana un mērīšana katru sekundi var ietvert tūkstošiem, ja ne miljoniem datu bāzes atjauninājumu. Datu bāzes primārās prasības, lai atbalstītu šādu risinājumu, ir liela caurlaidspēja rakstīšanas operācijām un zema (zem milisekundes) atbildes latentuma pakāpe.

Redis, atvērtā koda atmiņas datu bāzes platforma, nodrošina abus šos ieguvumus, vienlaikus arī ekonomiski izdevīgi, lietojot minimālus aparatūras resursus. Šajā rakstā mēs izskatīsim dažas Redis funkcijas, kas padara to par labu mērīšanas risinājumu izvēli, un to, kā mēs varam izmantot Redis šim nolūkam. Bet vispirms aplūkosim dažus biežākos mērīšanas veidus.

Parastās mērīšanas lietojumprogrammas

Mērīšana ir nepieciešama visās lietojumprogrammās, kurām laika gaitā jāmēra resursu izmantošana. Šeit ir četri izplatīti scenāriji:

  1. Uz patēriņu balstīti cenu modeļi. Atšķirībā no vienreizējiem vai uz abonēšanu balstītiem maksājumu modeļiem, uz patēriņu balstīti cenu modeļi ļauj patērētājiem maksāt tikai par faktisko lietojumu. Patērētāji bauda lielāku elastību, brīvību un izmaksu ietaupījumus, savukārt pakalpojumu sniedzēji saglabā lielāku patērētāju paturēšanu.

    Šādu modeļu ieviešana var būt sarežģīta. Dažreiz mērīšanas sistēmai vienā plānā ir jāseko daudzām lietojuma vienībām un daudziem rādītājiem. Piemēram, mākoņa nodrošinātājs var iestatīt dažādus cenu līmeņus CPU cikliem, krātuvei, caurlaidspējai, mezglu skaitam vai pakalpojuma izmantošanas ilgumam. Telekomunikāciju uzņēmums var noteikt dažādus atļautā patēriņa līmeņus minūtēm, datiem vai tekstam. Mērīšanas risinājumam jāpiespiež pakalpojumu maksimālā noteikšana, iekasēšana vai paplašināšana atkarībā no uz patēriņu balstītas cenas veida.

  2. Resursu izmantošanas ierobežošana. Ikvienu pakalpojumu internetā var ļaunprātīgi izmantot, ja to lieto pārmērīgi, ja vien šī pakalpojuma cena nav ierobežota. Šī iemesla dēļ tādos populāros pakalpojumos kā Google AdWords API un Twitter Stream API ir iekļauti tarifu ierobežojumi. Daži ārkārtēji ļaunprātīgas izmantošanas gadījumi noved pie pakalpojumu atteikšanas (DoS). Lai novērstu ļaunprātīgu izmantošanu, pakalpojumiem un risinājumiem, kas ir pieejami internetā, jābūt izstrādātiem ar atbilstošiem likmju ierobežošanas noteikumiem. Pat vienkāršām autentifikācijas un pieteikšanās lapām ir jāierobežo atkārtotu mēģinājumu skaits noteiktā laika intervālā.

    Vēl viens piemērs, kad ir nepieciešams ierobežot resursu izmantošanu, ir tas, ka, mainot uzņēmējdarbības prasības, mantotajām sistēmām ir lielāka slodze, nekā tās var atbalstīt. Likme, ierobežojot zvanus uz mantotajām sistēmām, ļauj uzņēmumiem pielāgoties pieaugošajam pieprasījumam, bez nepieciešamības nomainīt savas mantotās sistēmas.

    Papildus ļaunprātīgas izmantošanas novēršanai un slodzes samazināšanai laba ātruma ierobežošana palīdz pārvaldīt arī pārsprāgtās satiksmes scenārijus. Piemēram, API, kas ievieš brutālu spēku ātruma ierobežošanas metodi, var atļaut 1000 zvanu katru stundu. Ja nav ieviesta satiksmes veidošanas politika, klients var izsaukt API 1000 reizes katras stundas pirmajās sekundēs, iespējams, pārsniedzot to, ko infrastruktūra var atbalstīt. Populāri ātrumu ierobežojoši algoritmi, piemēram, Token Bucket un Leaky Bucket, novērš pārrāvumus, ne tikai ierobežojot zvanus, bet arī sadalot tos laika gaitā.

  3. Resursu sadale. Sastrēgumi un kavējumi ir izplatīti scenāriji lietojumprogrammās, kas nodarbojas ar pakešu maršrutēšanu, darba pārvaldību, satiksmes sastrēgumiem, pūļa kontroli, sociālo mediju ziņojumapmaiņu, datu vākšanu un tā tālāk. Rindu modeļi piedāvā vairākas rindas lieluma pārvaldīšanas iespējas, pamatojoties uz ierašanās un aizbraukšanas ātrumu, taču šo modeļu ieviešana lielā mērā nav vienkārša.

    Neizpildīts darbs un pārslodze ir pastāvīgas bažas, strādājot ar ātru datu plūsmu. Gudriem dizaineriem ir jādefinē pieņemami rindas garuma ierobežojumi, vienlaikus iekļaujot gan rindu veiktspējas uzraudzību, gan dinamisko maršrutēšanu, pamatojoties uz rindu lielumiem.

  4. Skaitīšana mērogā reāllaika lēmumu pieņemšanai. E-komercijas vietnes, spēļu lietojumprogrammas, sociālie mediji un mobilās lietotnes katru dienu piesaista miljoniem lietotāju. Tā kā vairāk acu ābolu dod lielākus ienākumus, precīzi jāaplūko apmeklētāji un viņu darbības biznesam. Skaitīšana ir līdzīgi noderīga arī tādos lietošanas gadījumos kā kļūdu mēģinājumi, problēmu eskalācija, DDoS uzbrukumu novēršana, trafika profilēšana, resursu sadalīšana pēc pieprasījuma un krāpšanas mazināšana.

Mērīšanas projektēšanas izaicinājumi

Risinājumu arhitektiem, veidojot mērīšanas lietojumprogrammu, ir jāņem vērā daudzi parametri, sākot ar šiem četriem:

  1. Dizaina sarežģītība. Datu apjomu skaitīšana, izsekošana un regulēšana - it īpaši, ja tie sasniedz lielu ātrumu - ir biedējošs uzdevums. Risinājumu arhitekti var apstrādāt mērīšanu lietojumprogrammas slānī, izmantojot programmēšanas valodas struktūras. Tomēr šāds dizains nav izturīgs pret kļūmēm vai datu zudumu. Tradicionālās uz diska balstītās datubāzes ir stabilas un sola augstu datu izturības pakāpi kļūmju laikā. Bet ne tikai tie nespēj nodrošināt nepieciešamo veiktspēju, bet arī palielina sarežģītību bez pareizām datu struktūrām un rīkiem mērīšanas ieviešanai.
  2. Latentums. Mērīšana parasti ietver daudzus, pastāvīgus skaitīšanas atjauninājumus. Tīkla un diska lasīšanas / rakstīšanas latentums summējas, strādājot ar lieliem skaitļiem. Tas varētu radīt lielu datu uzkrāšanos, kas novestu pie vairāk kavēšanās. Otrs latentuma avots ir programmas dizains, kas mērierīces datus no datu bāzes ielādē programmas galvenajā atmiņā un pēc tam, kad tiek atjaunināts skaitītājs, ieraksta atpakaļ datu bāzē.
  3. Vienlaicīgums un konsekvence. Miljonu un miljardu vienību skaitīšanas risinājuma izveide var kļūt sarežģīta, ja notikumi tiek fiksēti dažādos reģionos, un tiem visiem ir jāsaplūst vienā vietā. Datu konsekvence kļūst par problēmu, ja daudzi procesi vai pavedieni vienlaicīgi atjaunina to pašu skaitu. Bloķēšanas paņēmieni ļauj izvairīties no konsekvences problēmām un nodrošina darījumu līmeņa konsekvenci, bet palēnina risinājumu.
  4. Izturība. Mērīšana ietekmē ieņēmumu skaitu, kas nozīmē, ka īslaicīgas datubāzes nav ideālas izturības ziņā. Ideāla izvēle ir atmiņā ievietota datu glabātuve ar izturības opcijām.

Redis izmantošana mērīšanas lietojumprogrammām

Nākamajās sadaļās mēs pārbaudīsim, kā Redis izmantot skaitīšanas un mērīšanas risinājumiem. Redis ir iebūvētas datu struktūras, atomu komandas un laiks līdz dzīvošanai (TTL), kuras var izmantot enerģijas mērīšanas lietojuma gadījumos. Redis darbojas pa vienu pavedienu. Tāpēc visi datu bāzes atjauninājumi tiek sērijveidoti, ļaujot Redis darboties kā bez bloķēšanas datu krātuvē. Tas vienkāršo lietojumprogrammas dizainu, jo izstrādātājiem nav jāpieliek pūles, lai sinhronizētu pavedienus vai ieviestu bloķēšanas mehānismus, lai nodrošinātu datu konsekvenci.

Atomic Redis komandas skaitīšanai

Redis nodrošina komandas vērtību palielināšanai, neprasot tās nolasīt lietojumprogrammas galvenajā atmiņā.

KomandaApraksts
INCR taustiņuPalieliniet atslēgas veselu skaitli par vienu
INCRBY taustiņa pieaugumsPalieliniet atslēgas veselu skaitli ar norādīto skaitli
INCRBYFLOAT taustiņa pieaugumsPalieliniet atslēgas peldošo vērtību par norādīto summu
DECR taustiņuSamaziniet atslēgas veselu skaitli par vienu
NOLIEKUMS atslēgas samazināšanaSamaziniet atslēgas veselu skaitli par norādīto skaitli
HINCRBY atslēgas lauka pieaugumsPalieliniet jaukta lauka veselu skaitli ar norādīto skaitli
HINCRBYFLOAT atslēgas lauka pieaugumsPalieliniet jaucējlauka peldošo vērtību par norādīto summu

Redis glabā veselus skaitļus kā bāzes 10 64 bitu parakstītus skaitļus. Tāpēc vesela skaitļa maksimālais ierobežojums ir ļoti liels skaitlis: 263 - 1 = 9,223,372,036,854,775,807.

Iebūvēts Time-to-live (TTL) uz Redis taustiņiem

Viens no mērīšanas biežāk izmantotajiem gadījumiem ir izsekot lietojumu laika ziņā un ierobežot resursus pēc laika beigām. Redisā taustiņiem var iestatīt laiku līdz dzīvošanai. Pēc noteiktā taimauta Redis automātiski atspējos taustiņus. Šajā tabulā ir uzskaitītas vairākas atslēgu derīguma termiņa beigu metodes.

KomandaApraksts
DZĪVOT taustiņu sekundesIestatiet atslēgas laiku, lai dzīvotu sekundēs
EXPIREAT galvenais laika zīmogsIestatiet atslēgas derīguma termiņu kā Unix laika zīmogu
PEXPIRE atslēga milisekundesIestatiet atslēgas laiku, lai dzīvotu milisekundēs
PEXPIREAT galvenais laika zīmogsIestatiet atslēgas derīguma termiņu kā UNIX laika zīmogu milisekundēs
SET atslēgas vērtība [EX sekundes] [PX milisekundes]Iestatiet virknes vērtību atslēgai kopā ar izvēles laiku dzīvošanai

Zemāk redzamie ziņojumi sniedz laiku, lai dzīvotu uz taustiņiem sekundēs un milisekundēs.

KomandaApraksts
TTL taustiņuIegūstiet laiku, lai dzīvotu pēc atslēgas
PTTL taustiņuIegūstiet laiku, lai dzīvotu par atslēgu milisekundēs

Redis datu struktūras un komandas efektīvai skaitīšanai

Redis ir iecienīts tādu datu struktūru dēļ kā saraksti, kopas, sakārtoti komplekti, hašiši un hiperlogi. Daudz vairāk var pievienot, izmantojot Redis moduļu API.

Redis Labs

Redis datu struktūras nāk ar iebūvētām komandām, kas ir optimizētas izpildei ar maksimālu efektivitāti atmiņā (tieši tur, kur dati tiek glabāti). Dažas datu struktūras palīdz sasniegt daudz vairāk nekā objektu skaitīšana. Piemēram, kopas datu struktūra garantē visu elementu unikalitāti.

Kārtotais kopa iet vēl soli tālāk, nodrošinot, ka komplektam tiek pievienoti tikai unikāli elementi, un ļaujot pasūtīt elementus, pamatojoties uz partitūru. Piemēram, pasūtot elementus pēc laika sakārtotas kopas datu struktūrā, tiks piedāvāta laika sēriju datu bāze. Ar Redis komandu palīdzību jūs varat iegūt elementus noteiktā secībā vai izdzēst vairs nevajadzīgus vienumus.

Hyperloglog ir vēl viena īpaša datu struktūra, kas aprēķina miljonu unikālu priekšmetu skaitu, bez nepieciešamības uzglabāt objektus vai ietekmēt atmiņu.

Datu struktūraKomandaApraksts
SarakstsLLEN taustiņuIegūstiet saraksta garumu
IestatietSCARD taustiņuIegūstiet dalībnieku skaitu komplektā (kardinalitāte)
Kārtots komplektsZCARD taustiņuIegūstiet dalībnieku skaitu sakārtotā komplektā
Kārtots komplektsZLEXCOUNT taustiņš min. maksSaskaitiet dalībnieku skaitu sakārtotā komplektā starp norādīto leksikogrāfisko diapazonu
HashHLEN taustiņuIegūstiet jauktajā lauku skaitu
HiperloglogsPFCOUNT taustiņuIegūstiet aptuveno kopas kardinalitāti, ko novēro Hyperloglog datu struktūra
BitkarteBITCOUNT taustiņš [sākuma beigas]Skaita virknes iestatītos bitus

Atkārtoti noturība un atmiņā atkārtošanās

Mērīšanas lietojuma gadījumi, piemēram, maksājumi, ietver uzņēmumiem kritiskas informācijas glabāšanu un atjaunināšanu. Datu zaudēšana tieši ietekmē ieņēmumus. Tas var arī iznīcināt norēķinu ierakstus, kas bieži vien ir atbilstības vai pārvaldības prasības.

Redis konsekvenci un izturību var pielāgot, pamatojoties uz datu prasībām. Ja jums ir nepieciešams pastāvīgs pieraksts par jūsu mērīšanas datiem, jūs varat sasniegt izturību, izmantojot Redis noturības iespējas. Redis atbalsta AOF (tikai pielikuma fails), kas kopē rakstīšanas komandas uz disku, kad tās notiek, un momentuzņēmumu, kas datus vienā brīdī uzņem un tos ieraksta diskā.

Iebūvēta bez slēdzenes Redis arhitektūra

Redis apstrāde ir ar vienu vītni; tas nodrošina datu integritāti, jo visas rakstīšanas komandas tiek automātiski sērijveida. Šī arhitektūra atbrīvo izstrādātājus un arhitektus no sloga sinhronizēt pavedienus daudzvītņu vidē.

Populāras patērētāju mobilās lietojumprogrammas gadījumā tūkstošiem un dažkārt miljoniem lietotāju vienlaikus var piekļūt lietojumprogrammai. Pieņemsim, ka lietojumprogramma mēra izmantoto laiku, un divi vai vairāki lietotāji vienlaikus var kopīgot minūtes. Paralēlie pavedieni var atjaunināt to pašu objektu, neuzliekot papildu slogu datu integritātes nodrošināšanai. Tas samazina lietojumprogrammas dizaina sarežģītību, vienlaikus nodrošinot ātrumu un efektivitāti.

Redis mērīšanas paraugu ieviešana

Apskatīsim koda paraugu. Vairākiem no tālāk minētajiem scenārijiem būtu nepieciešama ļoti sarežģīta ieviešana, ja izmantotā datu bāze nebūtu Redis.

Bloķējot vairākus pieteikšanās mēģinājumus

Lai novērstu nesankcionētu piekļuvi kontiem, vietnes dažkārt bloķē lietotājus vairākkārtīgi mēģināt pieteikties noteiktā laika periodā. Šajā piemērā mēs ierobežojam lietotājus stundas laikā veikt vairāk nekā trīs pieteikšanās mēģinājumus, izmantojot vienkāršu galvenās funkcionalitātes laiku līdz darbam.

Atslēga, lai saglabātu pieteikšanās mēģinājumu skaitu:

lietotāja_login_ mēģinājumi:

Soļi:

Iegūstiet pašreizējo mēģinājumu skaitu:

IEGŪT lietotāja_login_ mēģinājumus:

Ja vērtība ir nulle, iestatiet atslēgu ar derīguma termiņu sekundēs (1 stunda = 3600 sekundes):

SET lietotāja pieteikšanās_mēģinājumi: 1 3600

Ja tas nav nulle un ja skaits ir lielāks par 3, tad mest kļūdu:

Ja tas nav nulle un ja skaits ir mazāks vai vienāds ar 3, palieliniet skaitli:

INCR lietotāja_login_ mēģinājumi:

Pēc veiksmīga pieteikšanās mēģinājumu atslēgu var izdzēst šādi:

DEL lietotāja pieteikšanās_mēģinājumi:

Maksājiet, kā jums iet

Redis Hash datu struktūra nodrošina vienkāršas komandas lietojuma un rēķinu izsekošanai. Šajā piemērā pieņemsim, ka katram klientam norēķinu dati tiek glabāti hash, kā parādīts zemāk:

klienta norēķini:

izmantošana

izmaksas

     .

     .

Pieņemsim, ka katra vienība maksā divus centus, un lietotājs patērēja 20 vienības. Lietošanas un rēķinu atjaunināšanas komandas ir šādas:

hincrby klients: izmantošana 20

hincrbyfloat klients: izmaksas 0,40

Kā jūs, iespējams, pamanījāt, jūsu lietojumprogramma var atjaunināt informāciju datu bāzē, nepieprasot tai ielādēt datus no datu bāzes savā atmiņā. Turklāt jūs varētu modificēt atsevišķu Hash objekta lauku, nelasot visu objektu.

Lūdzu, ņemiet vērā: Šī piemēra mērķis ir parādīt, kā lietot hinkrbijs un hincrbyfloat komandas. Labā dizainā jūs izvairāties no liekas informācijas, piemēram, lietošanas un izmaksu, glabāšanas.

$config[zx-auto] not found$config[zx-overlay] not found