Programovanie

Ako používať Redis na aplikácie merania v reálnom čase

Roshan Kumar je senior produktový manažér v Redis Labs.

Meranie nie je len jednoduchý problém s počítaním. Meranie je často zamieňané s meraním, ale zvyčajne to je viac. Meranie zahŕňa meranie, ale ako prebiehajúci proces, zvyčajne s cieľom regulovať využitie alebo tok zdroja v priebehu času. Moderné aplikácie obsahujú meranie rôznymi spôsobmi, od počítania ľudí, objektov alebo udalostí až po reguláciu používania, kontrolu prístupu a prideľovanie kapacity.

Meracie riešenia musia všeobecne spracovávať veľké objemy dát, pričom musia spĺňať prísne výkonnostné požiadavky. V závislosti od rozsahu riešenia môže počítanie a meranie zahŕňať každú sekundu tisíce, ak nie milióny aktualizácií databázy. Primárne požiadavky na databázu na podporu takéhoto riešenia sú vysoká priepustnosť pre operácie zápisu a nízka (pod milisekunda) latencia pre odpovede.

Redis, otvorená databázová platforma v pamäti, poskytuje obidve tieto výhody a zároveň je nákladovo efektívna z hľadiska použitia minimálnych hardvérových zdrojov. V tomto článku preskúmame určité vlastnosti Redis, ktoré z neho robia dobrú voľbu pre riešenia merania, a ako môžeme Redis na tento účel použiť. Najprv sa však pozrime na niektoré z najbežnejších použití merania.

Bežné aplikácie merania

Meranie je potrebné v každej aplikácii, ktorá musí merať využitie zdroja v priebehu času. Tu sú štyri bežné scenáre:

  1. Cenové modely založené na spotrebe. Na rozdiel od jednorazových alebo predplatných platobných modelov, cenové modely založené na spotrebe umožňujú zákazníkom platiť iba za skutočné použitie. Spotrebitelia sa tešia z väčšej flexibility, slobody a úspor nákladov, zatiaľ čo poskytovatelia si zachovávajú väčšiu mieru zachovania spotrebiteľa.

    Implementácia takýchto modelov môže byť zložitá. Merací systém musí niekedy sledovať veľa položiek použitia a veľa metrík v jednom pláne. Poskytovateľ cloudu môže napríklad nastaviť rôzne cenové úrovne pre cykly CPU, úložisko, priepustnosť, počet uzlov alebo dĺžku času, počas ktorého sa služba používa. Telekomunikačná spoločnosť môže nastaviť rôzne úrovne povolenej spotreby pre minúty, dáta alebo text. Meracie riešenie musí vynútiť obmedzenie, spoplatnenie alebo rozšírenie služieb v závislosti od typu ceny založenej na spotrebe.

  2. Obmedzenie využívania zdrojov. Každú službu na internete je možné zneužiť nadmerným používaním, pokiaľ nie je táto služba obmedzená rýchlosťou. Populárne služby ako Google AdWords API a Twitter Stream API z tohto dôvodu obsahujú obmedzenia sadzieb. Niektoré extrémne prípady zneužitia vedú k odmietnutiu služby (DoS). Aby sa zabránilo zneužitiu, služby a riešenia prístupné na internete musia byť navrhnuté s náležitými pravidlami obmedzujúcimi rýchlosť. Aj jednoduché overovacie a prihlasovacie stránky musia obmedziť počet opakovaní v danom časovom intervale.

    Ďalším príkladom, kde je nevyhnutné obmedziť využitie zdrojov, je zmena podnikových požiadaviek, keď viac zaťažujú staršie systémy, ako dokážu podporovať. Miera obmedzovania hovorov na staršie systémy umožňuje podnikom prispôsobiť sa rastúcemu dopytu bez potreby výmeny ich starších systémov.

    Okrem prevencie zneužívania a znižovania zaťaženia pomáha dobré obmedzenie rýchlosti aj pri správe scenárov dopravnej situácie. Napríklad API vynútiace metódu obmedzujúcu rýchlosť hrubej sily môže povoliť 1 000 hovorov každú hodinu. Bez zavedenej politiky formovania prenosu môže klient zavolať API 1000 krát za niekoľko sekúnd každej hodiny, čo môže presiahnuť to, čo dokáže podporiť infraštruktúra. Populárne algoritmy obmedzujúce rýchlosť, ako napríklad Token Bucket a Leaky Bucket, zabraňujú výbuchom nielen obmedzením hovorov, ale aj ich distribúciou v priebehu času.

  3. Distribúcia zdrojov. Preťaženie a oneskorenie sú bežné scenáre v aplikáciách, ktoré sa zaoberajú smerovaním paketov, správou úloh, preťažením dopravy, kontrolou davu, správami v sociálnych sieťach, zhromažďovaním údajov atď. Modely radenia ponúkajú niekoľko možností správy veľkosti frontu na základe rýchlosti príchodu a odchodu, ale implementácia týchto modelov vo veľkom meradle nie je ľahká.

    Nevybavené položky a preťaženie sú neustálymi starosťami pri práci s rýchlymi dátovými tokmi. Šikovní dizajnéri musia definovať prijateľné limity dĺžky frontu, pričom musia obsahovať sledovanie výkonu čakania v rade aj dynamické smerovanie na základe veľkostí front.

  4. Počítanie v rozsahu pre rozhodovanie v reálnom čase. Webové stránky elektronického obchodu, herné aplikácie, sociálne médiá a mobilné aplikácie priťahujú milióny každodenných používateľov. Pretože viac buliev prináša väčšie výnosy, pre podnikanie je rozhodujúce počítať návštevníkov a ich akcie presne. Počítanie je podobne užitočné pre prípady použitia, ako sú opakovanie chyby, eskalácia problému, prevencia útokov DDoS, profilovanie prenosu, pridelenie prostriedkov na požiadanie a zmiernenie podvodov.

Výzvy na meranie

Architekti riešení musia pri vytváraní meracej aplikácie brať do úvahy veľa parametrov, počnúc týmito štyrmi:

  1. Zložitosť dizajnu. Počítanie, sledovanie a regulácia objemov údajov - najmä keď dosiahnu vysokú rýchlosť - je skutočnou výzvou. Architekti riešení môžu zvládnuť meranie na aplikačnej vrstve pomocou štruktúr programovacieho jazyka. Takýto dizajn však nie je odolný voči poruchám alebo strate údajov. Tradičné diskové databázy sú robustné a sľubujú vysoký stupeň trvanlivosti údajov pri poruchách. Ale nielenže nedosahujú požadovaný výkon, zvyšujú tiež zložitosť bez správnych dátových štruktúr a nástrojov na implementáciu merania.
  2. Latencia. Meranie zvyčajne zahŕňa početné neustále aktualizácie počtu. Latencia čítania a zápisu na sieti a disku sa zvyšuje pri práci s veľkým počtom. To by mohlo snehovou guľou viesť k hromadeniu veľkého množstva nevybavených údajov, čo by viedlo k ďalším oneskoreniam. Ďalším zdrojom latencie je návrh programu, ktorý načíta údaje o meraní z databázy do hlavnej pamäte programu a po dokončení aktualizácie počítadla zapíše späť do databázy.
  3. Súbežnosť a konzistencia. Vytvorenie riešenia na počítanie miliónov a miliárd položiek sa môže skomplikovať, keď sa udalosti zachytia v rôznych regiónoch, a všetky sa musia sústrediť na jednom mieste. Konzistencia údajov sa stáva problémom, ak veľa procesov alebo vlákien súčasne aktualizuje rovnaký počet. Zamykacie techniky zabraňujú problémom s konzistenciou a poskytujú konzistenciu na úrovni transakcií, ale spomaľujú riešenie.
  4. Trvanlivosť. Meranie ovplyvňuje počty výnosov, čo znamená, že efemérne databázy nie sú z hľadiska trvanlivosti ideálne. Úložisko dát v pamäti s možnosťami odolnosti je perfektnou voľbou.

Používanie Redis na meranie aplikácií

V nasledujúcich častiach preskúmame, ako používať Redis na počítanie a meranie. Redis má zabudované dátové štruktúry, atómové príkazy a funkcie Time-to-Live (TTL), ktoré možno použiť na prípady použitia merania spotreby. Redis beží na jednom vlákne. Preto sú všetky aktualizácie databázy serializované, čo umožňuje spoločnosti Redis fungovať ako úložisko dát bez uzamknutia. To zjednodušuje návrh aplikácie, pretože vývojári nemusia vynaložiť nijaké úsilie na synchronizáciu vlákien alebo implementáciu uzamykacích mechanizmov na zabezpečenie konzistencie údajov.

Príkazy Atomic Redis na počítanie

Redis poskytuje príkazy na zvyšovanie hodnôt bez potreby ich čítania do hlavnej pamäte aplikácie.

VeleniePopis
INCR kľúčZvýši celočíselnú hodnotu kľúča o jednu
INCRBY kľúčový prírastokZvýši celočíselnú hodnotu kľúča o dané číslo
INCRBYFLOAT kľúčový prírastokZvyšuje floatovanú hodnotu kľúča o danú hodnotu
DECR kľúčZnížiť celočíselnú hodnotu kľúča o jednu
DECRBY zníženie kľúčaZnížiť celočíselnú hodnotu kľúča o dané číslo
HINCRBY prírastok kľúčového poľaZvýši celočíselnú hodnotu hash poľa o dané číslo
HINCRBYFLOAT prírastok kľúčového poľaZvýši float hodnotu hašovacieho poľa o dané množstvo

Redis ukladá celé čísla ako 64-bitové celé číslo so znamienkom so základom 10. Preto je maximálny limit pre celé číslo veľmi veľké číslo: 263 - 1 = 9 223 372 036 854 775 807.

Vstavaná funkcia Time-to-Live (TTL) na klávesoch Redis

Jedným z bežných prípadov použitia v meraní je sledovanie používania v čase a obmedzenie zdrojov po uplynutí času. V systéme Redis je možné nastaviť časovú hodnotu pre život kľúčov. Redis automaticky deaktivuje kľúče po uplynutí nastaveného časového limitu. V nasledujúcej tabuľke je uvedených niekoľko spôsobov vypršania platnosti kľúčov.

VeleniePopis
VYPRŠAŤ kľúčové sekundyNastaviť čas kľúča tak, aby žil v sekundách
EXPIREAT kľúčová časová pečiatkaNastavte expiráciu kľúča ako časovú značku Unixu
PEXPIRE kľúčové milisekundyNastaviť čas kľúča na život v milisekundách
PEXPIREAT kľúčová časová pečiatkaNastavte vypršanie platnosti kľúča ako časovú značku UNIX v milisekundách
NASTAVIŤ hodnota kľúča [EX sekúnd] [PX milisekundy]Nastavte hodnotu reťazca na kľúč spolu s voliteľným časom života

Nasledujúce správy vám poskytnú čas, ktorý musíte prežiť na klávesoch, v sekundách a milisekundách.

VeleniePopis
TTL kľúčZískajte čas žiť pre kľúč
PTTL kľúčZískajte čas na život pre kľúč v milisekundách

Redis dátové štruktúry a príkazy pre efektívne počítanie

Redis je obľúbený pre svoje dátové štruktúry, ako sú zoznamy, množiny, zoradené množiny, hash a hyperloglogy. Mnoho ďalších je možné pridať prostredníctvom rozhrania API Redis.

Redis Labs

Dátové štruktúry Redis prichádzajú so zabudovanými príkazmi, ktoré sú optimalizované na vykonávanie s maximálnou účinnosťou v pamäti (priamo tam, kde sú dáta uložené). Niektoré dátové štruktúry vám pomôžu dosiahnuť oveľa viac ako počítanie objektov. Napríklad dátová štruktúra Set zaručuje jedinečnosť všetkých prvkov.

Zoradená sada ide o krok ďalej, pretože zaisťuje, že sa do sady pridávajú iba jedinečné prvky, a umožňuje vám objednať prvky na základe skóre. Ak napríklad zoradíte svoje prvky podľa času v dátovej štruktúre zoradenej množiny, ponúkne vám databázu časových radov. Pomocou príkazov Redis môžete získať svoje prvky v určitom poradí alebo odstrániť položky, ktoré už nepotrebujete.

Hyperloglog je ďalšia špeciálna dátová štruktúra, ktorá odhaduje počty miliónov jedinečných položiek bez nutnosti ukladania samotných objektov alebo ovplyvňovania pamäte.

Dátová štruktúraVeleniePopis
ZoznamLLEN kľúčZískajte dĺžku zoznamu
NastaviťSCARD kľúčZískajte počet členov v sade (mohutnosť)
Zoradená sadaZCARD kľúčZískajte počet členov v zoradenej množine
Zoradená sadaZLEXCOUNT kľúč min. maxSpočítajte počet členov v zoradenej množine medzi daným lexikografickým rozsahom
HashHLEN kľúčZískajte počet polí v hashe
HyperloglogPFCOUNT kľúčZískajte približnú mohutnosť množiny pozorovanú dátovou štruktúrou Hyperloglogu
BitmapaBITCOUNT kľúč [začiatok koniec]Počty nastavených bitov v reťazci

Znova si vyskúšajte vytrvalosť a replikáciu v pamäti

Príklady použitia merania, ako sú platby, zahŕňajú ukladanie a aktualizáciu informácií, ktoré sú pre podniky kritické. Strata údajov má priamy vplyv na príjmy. Môže tiež zničiť fakturačné záznamy, ktoré sú často požiadavkou na zhodu alebo správu.

Konzistenciu a trvanlivosť v Redis môžete vyladiť na základe vašich požiadaviek na údaje. Ak potrebujete trvalý dôkaz o zaznamenaní svojich údajov o meraní, životnosť môžete dosiahnuť pomocou schopností spoločnosti Redis pretrvávať. Redis podporuje AOF (súbor iba na pridanie), ktorý kopíruje príkazy na zápis na disk tak, ako sa dejú, a snapshotting, ktorý v jednom okamihu vezme dáta tak, ako existujú, a zapíše ich na disk.

Vstavaná architektúra Redis bez uzamknutia

Spracovanie Redis je s jedným vláknom; To zaisťuje integritu údajov, pretože všetky príkazy na zápis sú automaticky serializované. Táto architektúra zbavuje vývojárov a architektov záťaže synchronizácie vlákien vo viacvláknovom prostredí.

V prípade populárnej spotrebiteľskej mobilnej aplikácie môžu k aplikácii pristupovať súčasne tisíce a niekedy aj milióny používateľov. Povedzme, že aplikácia meria použitý čas a dvaja alebo viacerí používatelia môžu zdieľať minúty súčasne. Paralelné vlákna môžu aktualizovať ten istý objekt bez toho, aby predstavovali ďalšie bremeno zabezpečenia integrity údajov. To znižuje zložitosť návrhu aplikácie a zaisťuje rýchlosť a efektívnosť.

Redis meranie implementácie vzorky

Pozrime sa na ukážkový kód. Niektoré z nižšie uvedených scenárov by vyžadovali veľmi zložité implementácie, ak použitá databáza nebola Redis.

Blokovanie viacerých pokusov o prihlásenie

Webové stránky niekedy zabraňujú niekoľkým pokusom o prihlásenie v stanovenom časovom období, aby zabránili neoprávnenému prístupu k účtom. V tomto príklade obmedzujeme používateľov v uskutočňovaní viac ako troch pokusov o prihlásenie za hodinu pomocou jednoduchej kľúčovej funkcie Time-to-Live.

Kľúč na zadržanie počtu pokusov o prihlásenie:

user_login_attempts:

Kroky:

Získajte aktuálny počet pokusov:

ZÍSKAŤ user_login_attempts:

Ak je hodnota null, nastavte kľúč s časom vypršania platnosti v sekundách (1 hodina = 3 600 sekúnd):

SET user_login_attempts: 1 3600

Ak nie je null a ak je počet väčší ako 3, urobte chybu:

Ak nie je null a ak je počet menší alebo rovný 3, zvýšte počet:

INCR user_login_attempts:

Po úspešnom pokuse o prihlásenie môže byť kľúč vymazaný nasledovne:

DEL user_login_attempts:

Plaťte priebežne

Dátová štruktúra Redis Hash poskytuje jednoduché príkazy na sledovanie používania a fakturácie. V tomto príklade predpokladajme, že každý zákazník má svoje fakturačné údaje uložené v haši, ako je uvedené nižšie:

fakturácia zákazníka:

použitie

náklady

     .

     .

Predpokladajme, že každá jednotka stojí dva centy a používateľ spotreboval 20 jednotiek. Príkazy na aktualizáciu použitia a fakturácie sú:

hincrby customer: usage 20

hincrbyfloat zákazník: cena 0,40

Ako ste si mohli všimnúť, vaša aplikácia môže aktualizovať informácie v databáze bez toho, aby vyžadovala načítanie údajov z databázy do vlastnej pamäte. Ďalej môžete upraviť jednotlivé pole objektu Hash bez prečítania celého objektu.

Poznámka: Účelom tohto príkladu je ukázať, ako používať hincrby a hincrbyfloat príkazy. V dobrom dizajne sa vyhnete ukladaniu nadbytočných informácií, ako sú napríklad použitie a náklady.

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