Kako koristiti Redis za mjerenje u stvarnom vremenu

Roshan Kumar viši je voditelj proizvoda u Redis Labs .

Mjerenje nije samo jednostavan problem brojanja. Mjerenje se često miješa s mjerenjem, ali obično je i više od toga. Mjerenje uključuje mjerenje, ali kao trajni proces, obično s ciljem reguliranja upotrebe ili protoka resursa tijekom vremena. Suvremene aplikacije uključuju mjerenje na mnogo različitih načina, od brojanja ljudi, predmeta ili događaja do regulacije upotrebe, kontrole pristupa i dodjele kapaciteta.

Mjerna rješenja općenito moraju obrađivati ​​velike količine podataka istodobno udovoljavajući strogim zahtjevima izvedbe. Ovisno o mjerilu rješenja, brojanje i mjerenje mogu uključivati ​​tisuće, ako ne i milijune ažuriranja baze podataka svake sekunde. Primarni zahtjevi baze podataka za podršku takvom rješenju su velika propusnost za operacije pisanja i mala (sub-milisekundna) latencija odgovora.

Redis, platforma baze podataka u memoriji s otvorenim kodom, donosi obje ove prednosti, a istovremeno je isplativa u smislu korištenja minimalnih hardverskih resursa. U ovom ćemo članku ispitati određene značajke Redisa zbog kojih je dobar izbor za mjerna rješenja i kako u tu svrhu možemo koristiti Redis. Ali prvo, pogledajmo nekoliko najčešćih načina mjerenja.

Uobičajene mjere za mjerenje

Mjerenje je potrebno u bilo kojoj aplikaciji koja mora mjeriti upotrebu resursa tijekom vremena. Evo četiri uobičajena scenarija:

  1. Modeli određivanja cijena zasnovani na potrošnji . Za razliku od jednokratnih ili pretplatničkih modela plaćanja, modeli cijena zasnovani na potrošnji omogućuju potrošačima da plaćaju samo za stvarnu upotrebu. Potrošači uživaju veću fleksibilnost, slobodu i uštedu dok pružatelji usluga dobivaju veće zadržavanje potrošača.

    Primjena takvih modela može biti nezgodna. Ponekad mjerni sustav mora pratiti mnoge stavke upotrebe i mnoge mjerne podatke u jednom planu. Na primjer, pružatelj usluga u oblaku može postaviti različite razine cijena za CPU cikluse, pohranu, protok, broj čvorova ili duljinu vremena korištenja usluge. Telekomunikacijska tvrtka može postaviti različite razine dopuštene potrošnje minuta, podataka ili teksta. Mjerno rješenje mora nametnuti ograničavanje, naplatu ili proširenje usluga, ovisno o vrsti cijena na temelju potrošnje.

  2. Ograničavanje korištenja resursa . Svaka usluga na Internetu može se zloupotrijebiti pretjeranom upotrebom, osim ako ta usluga nije ograničena. Popularne usluge kao što su Google AdWords API i Twitter Stream API iz ovog razloga uključuju ograničenja brzine. Neki ekstremni slučajevi zlostavljanja dovode do uskraćivanja usluge (DoS). Da bi se spriječile zlouporabe, usluge i rješenja koja su dostupna na Internetu moraju biti dizajnirana s pravilnim pravilima o ograničenju stope. Čak i jednostavne stranice za autentifikaciju i prijavu moraju ograničiti broj ponovljenih pokušaja za određeni vremenski interval.

    Sljedeći je primjer ograničavanja korištenja resursa kada je promjena poslovnih zahtjeva veće opterećenje naslijeđenih sustava nego što oni mogu podržati. Ograničavanje brzine poziva na naslijeđene sustave omogućuje tvrtkama da se prilagode rastućoj potražnji bez potrebe za zamjenom svojih naslijeđenih sustava.

    Osim sprječavanja zlouporabe i smanjenja opterećenja, dobro ograničavanje brzine također pomaže u upravljanju brzim scenarijima prometa. Na primjer, API koji primjenjuje metodu ograničavanja brzine grube sile može dopustiti 1000 poziva svaki sat. Bez uspostavljene politike oblikovanja prometa, klijent može API-je nazvati 1000 puta u prvih nekoliko sekundi svakog sata, možda premašujući ono što infrastruktura može podržati. Popularni algoritmi za ograničavanje brzine, poput Token Bucket i Leaky Bucket, sprječavaju rafale ne samo ograničavanjem poziva, već i njihovom distribucijom tijekom vremena.

  3. Raspodjela resursa . Zagušenja i kašnjenja uobičajeni su scenarij u aplikacijama koje se bave usmjeravanjem paketa, upravljanjem poslom, zagušenjem prometa, kontrolom gužve, razmjenom poruka na društvenim mrežama, prikupljanjem podataka i tako dalje. Modeli čekanja nude nekoliko opcija za upravljanje veličinom reda na temelju stope dolaska i odlaska, ali velika primjena ovih modela nije jednostavna.

    Zaostatak i zagušenja stalna su briga pri radu s brzim tokovima podataka. Pametni dizajneri trebaju definirati prihvatljiva ograničenja duljine reda, uključujući istovremeno praćenje izvedbe redova čekanja i dinamičko usmjeravanje na temelju veličina reda.

  4. Brojanje na skali za donošenje odluka u stvarnom vremenu . Web stranice e-trgovine, aplikacije za igre, društvene mreže i mobilne aplikacije privlače milijune dnevnih korisnika. Budući da više očnih jabučica donosi veći prihod, brojanje posjetitelja i njihovo točno postupanje presudno je za poslovanje. Brojanje je na sličan način korisno za slučajeve upotrebe kao što su pokušaji pogrešaka, eskalacija problema, sprečavanje DDoS napada, profiliranje prometa, dodjela resursa na zahtjev i ublažavanje prijevara.

Izazovi dizajna mjerenja

Arhitekti rješenja moraju uzeti u obzir mnoge parametre prilikom izrade mjernog programa, počevši od ova četiri:

  1. Složenost dizajna. Brojanje, praćenje i reguliranje volumena podataka - posebno kada dolaze velikom brzinom - zastrašujući je zadatak. Arhitekti rješenja mogu se nositi s mjerenjem na aplikacijskom sloju pomoću struktura programskog jezika. Međutim, takav dizajn nije otporan na kvarove ili gubitak podataka. Tradicionalne baze podataka zasnovane na disku robusne su i obećavaju visok stupanj trajnosti podataka tijekom kvarova. Ali ne samo da ne pružaju potrebne performanse, oni također povećavaju složenost bez pravih struktura podataka i alata za provedbu mjerenja.
  2. Latencija. Mjerenje obično uključuje brojna, stalna ažuriranja brojača. Mreža i kašnjenje čitanja / pisanja s diska zbrajaju se pri radu s velikim brojevima. To bi moglo stvoriti snijeg i stvoriti ogroman zaostatak podataka što bi dovelo do većih kašnjenja. Drugi izvor kašnjenja je dizajn programa koji učitava podatke mjerenja iz baze podataka u glavnu memoriju programa i upisuje natrag u bazu podataka kada ažurira brojač.
  3. Istodobnost i dosljednost. Arhitektonsko rješenje za brojanje milijuna i milijardi predmeta može postati složeno kad se događaji zabilježe u različitim regijama i svi se trebaju konvergirati na jednom mjestu. Dosljednost podataka postaje problem ako se mnogi procesi ili niti istovremeno ažuriraju isti broj. Tehnike zaključavanja izbjegavaju probleme s dosljednošću i pružaju dosljednost na razini transakcija, ali usporavaju rješenje.
  4. Izdržljivost. Mjerenje utječe na broj prihoda, što znači da efemerne baze podataka nisu idealne u smislu trajnosti. Skladište podataka u memoriji s opcijama trajnosti savršen je izbor.

Korištenje Redisa za mjerenje

U sljedećim odjeljcima ispitat ćemo kako koristiti Redis za rješenja za brojanje i mjerenje. Redis ima ugrađene podatkovne strukture, atomske naredbe i mogućnosti vremena za život (TTL) koje se mogu koristiti za napajanje mjernih slučajeva. Redis radi na jednoj niti. Stoga su sva ažuriranja baze podataka serializirana, što Redisu omogućuje rad kao spremište podataka bez zaključavanja. Ovo pojednostavljuje dizajn aplikacije jer programeri ne trebaju trošiti napor na sinkronizaciju niti ili implementaciju mehanizama zaključavanja radi dosljednosti podataka.  

Atomske Redis naredbe za brojanje

Redis pruža naredbe za povećanje vrijednosti bez potrebe za čitanjem u glavnu memoriju aplikacije.

Naredba Opis
INCR ključ Povećajte cjelobrojnu vrijednost ključa za jedan
INCRBY prirast tipke Povećajte cjelobrojnu vrijednost ključa za zadani broj
INCRBYFLOAT prirast tipke Povećajte plutajuću vrijednost ključa za zadani iznos
DECR ključ Smanjite cjelobrojnu vrijednost ključa za jedan
DECRBY smanjenje ključa Smanji cjelobrojnu vrijednost ključa za zadani broj
HINCRBY prirast polja ključa Povećajte cjelobrojnu vrijednost hash polja za zadani broj
HINCRBYFLOAT prirast polja ključa Povećajte plutajuću vrijednost hash polja za zadani iznos

Redis pohranjuje cijele brojeve kao osnovni 10 64-bitni potpisani cijeli broj. Stoga je maksimalno ograničenje za cijeli broj vrlo velik broj: 263 - 1 = 9.223.372.036.854.775.807.

Ugrađeni TTL na tipkama Redis

Jedan od uobičajenih slučajeva upotrebe u mjerenju je praćenje upotrebe s vremenom i ograničavanje resursa nakon isteka vremena. U Redisu se može postaviti vrijednost vremena života za tipke. Redis će automatski onemogućiti tipke nakon zadanog vremenskog ograničenja. Sljedeća tablica navodi nekoliko metoda isteka ključeva.

Naredba Opis
EXPIRE ključne sekunde Postavite vrijeme ključa da živi u sekundama
EXPIREAT ključna vremenska oznaka Istek ključa postavite kao vremensku oznaku Unixa
PEXPIRE ključne milisekunde Postavite vrijeme ključa da živi u milisekundama
PEXPIREAT ključna vremenska oznaka Istek ključa postavite kao UNIX vremensku oznaku u milisekundama
SET vrijednost ključa [EX sekunde] [PX milisekunde] Postavite vrijednost niza na ključ zajedno s neobaveznim vremenom za život

Donje poruke daju vam vrijeme za život na tipkama u sekundama i milisekundama.

Naredba Opis
TTL ključ Nađite vremena za život za ključ
PTTL ključ Nađite vremena za život za ključ u milisekundama

Redis strukture podataka i naredbe za učinkovito brojanje

Redis je omiljen zbog svojih struktura podataka kao što su popisi, skupovi, razvrstani skupovi, hashovi i hiperlogi. Mnogo više se može dodati putem API-ja Redis modula.

Redis laboratoriji

Redisove podatkovne strukture dolaze s ugrađenim naredbama koje su optimizirane za izvršavanje s maksimalnom učinkovitošću u memoriji (upravo tamo gdje su podaci pohranjeni). Neke strukture podataka pomažu vam da postignete mnogo više od brojanja objekata. Na primjer, struktura podataka Set jamči jedinstvenost svih elemenata.

Sortirani set ide korak dalje osiguravajući da se u skup dodaju samo jedinstveni elementi i omogućava vam da redoslijedite elemente na temelju rezultata. Naručivanje vaših elemenata po vremenu u strukturi podataka Sortirani niz ponudit će vam, na primjer, bazu podataka vremenskih serija. Pomoću naredbi Redis mogli ste svoje elemente dobiti u određenom redoslijedu ili izbrisati stavke koje vam više nisu potrebne.

Hyperloglog je još jedna posebna struktura podataka koja procjenjuje brojeve milijuna jedinstvenih predmeta bez potrebe za pohranom samih predmeta ili utjecajem na memoriju.

Struktura podataka Naredba Opis
Popis LLEN ključ Doznajte duljinu popisa
Postavi SCARD ključ Dohvatite broj članova u skupu (kardinalnost)
Razvrstani set ZCARD ključ Doznajte broj članova u razvrstanom skupu
Razvrstani set ZLEXCOUNT tipka min maks Broji broj članova u razvrstanom skupu između određenog leksikografskog raspona
Hash HLEN ključ Doznajte broj polja u hashu
Hiperloglog PFCOUNT ključ Dobijte približnu kardinalnost skupa koju promatra struktura podataka Hyperloglog
Bitmapa BITCOUNT tipka [početak i kraj] Broji postavljene bitove u nizu

Redis perzistentnost i replikacija u memoriji

Slučajevi mjerenja, poput plaćanja, uključuju pohranu i ažuriranje podataka koji su presudni za tvrtke. Gubitak podataka izravno utječe na prihod. Također može uništiti evidenciju naplate, koja je često zahtjev za usklađivanjem ili upravljanjem.

U Redisu možete prilagoditi dosljednost i trajnost na temelju svojih podataka. Ako vam je potreban trajni dokaz o vašim mjernim podacima, trajnost možete postići zahvaljujući Redisovim mogućnostima postojanosti. Redis podržava AOF (datoteka samo za dodavanje), koja kopira naredbe za pisanje na disk čim se dogode, i snimanje fotografija, koje podatke uzima u postojanju u jednom trenutku i zapisuje na disk.

Ugrađena Redis arhitektura bez zaključavanja

Redis obrada je s jednim navojem; to osigurava cjelovitost podataka, jer se sve naredbe za pisanje automatski serializiraju. Ova arhitektura oslobađa programere i arhitekte tereta sinkronizacije niti u višenitnom okruženju.

U slučaju popularne potrošačke mobilne aplikacije, tisuće, a ponekad i milijuni korisnika možda istovremeno pristupaju aplikaciji. Recimo da aplikacija mjeri utrošeno vrijeme, a dva ili više korisnika istodobno mogu dijeliti minute. Paralelne niti mogu ažurirati isti objekt bez nametanja dodatnog tereta osiguranja integriteta podataka. To smanjuje složenost dizajna aplikacije, istovremeno osiguravajući brzinu i učinkovitost.

Redis mjere implementacije uzorka

Pogledajmo uzorak koda. Nekoliko scenarija u nastavku zahtijevalo bi vrlo složene implementacije da korištena baza podataka nije Redis.

Blokiranje višestrukih pokušaja prijave

Kako bi spriječili neovlašteni pristup računima, web stranice ponekad blokiraju korisnike u više pokušaja prijave unutar određenog vremenskog razdoblja. U ovom primjeru ograničavamo korisnike da izvrše više od tri pokušaja prijave u satu koristeći jednostavnu ključnu funkcionalnost vremena za aktiviranje.

Ključ za zadržavanje broja pokušaja prijave:

user_login_attempts:

Koraci:

Dohvatite trenutni broj pokušaja:

GET user_login_attempts:

Ako je nula, postavite ključ s vremenom isteka u sekundama (1 sat = 3600 sekundi):

POSTAVITE user_login_attempts: 1 3600

Ako nije null i ako je broj veći od 3, izbacite pogrešku:

Ako nije null i ako je brojanje manje ili jednako 3, povećajte brojanje:

INCR user_login_attempts:

Nakon uspješnog pokušaja prijave, ključ se može izbrisati na sljedeći način:

DEL user_login_attempts:

Plati kako ideš

Struktura podataka Redis Hash pruža jednostavne naredbe za praćenje upotrebe i naplate. U ovom primjeru pretpostavimo da svaki kupac ima podatke o naplati pohranjene u hashu, kao što je prikazano u nastavku:

customer_billing:

     upotreba

     trošak

     .

     .

Pretpostavimo da svaka jedinica košta dva centa, a korisnik je potrošio 20 jedinica. Naredbe za ažuriranje upotrebe i naplate su:

hincrby kupac: upotreba 20

kupac hincrbyfloat: trošak, 40

Kao što ste možda primijetili, vaša aplikacija može ažurirati podatke u bazi podataka bez potrebe da učitava podatke iz baze podataka u vlastitu memoriju. Uz to, možete izmijeniti pojedinačno polje Hash objekta bez čitanja cijelog objekta.

Napomena: Svrha ovog primjera je da pokaže kako se koriste hincrbyi hincrbyfloatnaredbe. U dobrom dizajnu izbjegavate pohranjivanje suvišnih podataka poput upotrebe i troškova.