Jak používat Redis pro aplikace měření v reálném čase

Roshan Kumar je senior produktový manažer ve společnosti Redis Labs.

Měření není jen problém s jednoduchým počítáním. Měření je často zaměňováno s měřením, ale obvykle je to víc než to. Měření zahrnuje měření, ale jako průběžný proces, obvykle s cílem regulovat využití nebo tok zdroje v průběhu času. Moderní aplikace zahrnují měření mnoha různými způsoby, od počítání lidí, objektů nebo událostí až po regulaci využití, řízení přístupu a přidělování kapacity.

Řešení pro měření obecně musí zpracovávat velké objemy dat při splnění přísných požadavků na výkon. V závislosti na rozsahu řešení může počítání a měření zahrnovat každou sekundu tisíce, ne-li miliony aktualizací databáze. Primárními požadavky databáze na podporu takového řešení jsou vysoká propustnost pro operace zápisu a nízká (pod milisekunda) latence pro odpovědi.

Redis, databázová platforma v paměti s otevřeným zdrojovým kódem, přináší obě tyto výhody a zároveň je nákladově efektivní z hlediska použití minimálních hardwarových prostředků. V tomto článku se budeme zabývat určitými funkcemi Redis, díky nimž je dobrou volbou pro měřicí řešení, a jak můžeme Redis pro tento účel použít. Nejprve se ale podívejme na několik běžnějších způsobů měření.

Běžné aplikace měření

Měření je vyžadováno v každé aplikaci, která musí měřit využití prostředku v čase. Tady jsou čtyři běžné scénáře:

Cenové modely založené na spotřebě. Na rozdíl od jednorázových nebo předplacených platebních modelů umožňují cenové modely založené na spotřebě spotřebitelům platit pouze za skutečné využití. Spotřebitelé mají větší flexibilitu, svobodu a úsporu nákladů, zatímco poskytovatelé získávají větší retenci spotřebitelů.
Implementace takových modelů může být obtížná. Někdy musí měřicí systém sledovat mnoho položek použití a mnoho metrik v jednom plánu. Například poskytovatel cloudu může nastavit různé cenové úrovně pro cykly CPU, úložiště, propustnost, počet uzlů nebo dobu, po kterou se služba používá. Telekomunikační společnost může nastavit různé úrovně povolené spotřeby pro minuty, data nebo text. Řešení měření musí vynucovat omezení, nabíjení nebo rozšiřování služeb v závislosti na typu cen na základě spotřeby.
Omezení využití zdrojů. Každá služba na internetu může být zneužita nadměrným používáním, pokud tato služba není omezena rychlostí. Populární služby, jako je Google AdWords API a Twitter Stream API, z tohoto důvodu obsahují omezení rychlosti. Některé extrémní případy zneužití vedou k odmítnutí služby (DoS). Aby se zabránilo zneužití, musí být služby a řešení, která jsou přístupná na internetu, navržena s náležitými pravidly omezujícími rychlost. I jednoduché ověřovací a přihlašovací stránky musí omezit počet opakování pro daný časový interval.
Dalším příkladem, kdy je nutné omezit využití zdrojů, je změna obchodních požadavků, která více zatěžuje starší systémy, než mohou podporovat. Rychlost omezující hovory na starší systémy umožňuje podnikům přizpůsobit se rostoucí poptávce, aniž by bylo nutné jejich starší systémy vyměňovat.
Kromě prevence zneužívání a snižování zatížení pomáhá dobré omezení rychlosti také se správou scénářů rušného provozu. Například API vynucující metodu omezující rychlost hrubou silou může povolit 1000 hovorů každou hodinu. Bez zavedené zásady utváření provozu může klient volat API 1000krát během prvních několika sekund každé hodiny, což možná překročí to, co může infrastruktura podporovat. Populární algoritmy omezující rychlost, jako je Token Bucket a Leaky Bucket, zabraňují výbuchům nejen omezením hovorů, ale také jejich distribucí v průběhu času.
Distribuce zdrojů. Zahlcení a zpoždění jsou běžné scénáře v aplikacích, které se zabývají směrováním paketů, správou úloh, zahlcením provozu, kontrolou davů, zasíláním sociálních médií, shromažďováním dat atd. Modely řazení do fronty nabízejí několik možností pro správu velikosti fronty na základě rychlosti příjezdu a odjezdu, ale implementace těchto modelů ve velkém měřítku není snadná.
Nevyřízené položky a přetížení jsou neustálé starosti při řešení rychlých datových proudů. Chytří designéři potřebují definovat přijatelné limity délky fronty a současně začlenit jak sledování výkonu front, tak dynamické směrování na základě velikostí front.
Počítání v měřítku pro rozhodování v reálném čase. Weby elektronického obchodování, herní aplikace, sociální média a mobilní aplikace přitahují miliony každodenních uživatelů. Protože více očních bulvy přináší vyšší příjmy, je pro podnikání důležité přesné počítání návštěvníků a jejich akcí. Počítání je podobně užitečné pro případy použití, jako jsou opakování chyb, eskalace problémů, prevence útoků DDoS, profilování provozu, přidělování prostředků na vyžádání a zmírňování podvodů.

Výzvy pro návrh měření

Architekti řešení musí při vytváření měřicí aplikace vzít v úvahu mnoho parametrů, počínaje těmito čtyřmi:

Složitost designu. Počítání, sledování a regulace objemů dat - zvláště když dosáhnou vysoké rychlosti - je skličující úkol. Architekti řešení mohou zpracovávat měření na aplikační vrstvě pomocí struktur programovacích jazyků. Takový design však není odolný vůči poruchám nebo ztrátě dat. Tradiční diskové databáze jsou robustní a slibují vysoký stupeň trvanlivosti dat při selhání. Nejenže nedosahují požadovaného výkonu, ale také zvyšují složitost bez správných datových struktur a nástrojů pro implementaci měření.
Latence. Měření obvykle zahrnuje četné neustálé aktualizace počtu. Latence čtení a zápisu na síti a disku se sčítá při řešení velkého počtu. To by mohlo sněhovou koulí vést k hromadění obrovských nevyřízených dat, což by vedlo k dalším zpožděním. Druhým zdrojem latence je návrh programu, který načte data měření z databáze do hlavní paměti programu a po dokončení aktualizace čítače zapíše zpět do databáze.
Souběžnost a konzistence. Vytvoření řešení pro počítání milionů a miliard položek může být složité, když jsou události zachyceny v různých regionech, a všechny je třeba sbírat na jednom místě. Konzistence dat se stává problémem, pokud mnoho procesů nebo vláken současně aktualizuje stejný počet. Zamykací techniky zabraňují problémům s konzistencí a dodávají konzistenci na úrovni transakcí, ale zpomalují řešení.
Trvanlivost. Měření ovlivňuje čísla výnosů, což znamená, že pomíjivé databáze nejsou z hlediska trvanlivosti ideální. Úložiště dat v paměti s možnostmi odolnosti je perfektní volbou.

Používání Redis pro aplikace měření

V následujících částech prozkoumáme, jak používat Redis pro řešení počítání a měření. Redis má vestavěné datové struktury, atomické příkazy a funkce Time-to-Live (TTL), které lze použít k případům použití měření výkonu. Redis běží na jednom vlákně. Proto jsou všechny aktualizace databáze serializovány, což umožňuje Redisu fungovat jako úložiště dat bez zámku. To zjednodušuje design aplikace, protože vývojáři nemusí vynaložit žádné úsilí na synchronizaci vláken nebo implementaci uzamykacích mechanismů pro konzistenci dat.

Atomic Redis příkazy pro počítání

Redis poskytuje příkazy pro zvyšování hodnot bez nutnosti jejich načítání do hlavní paměti aplikace.

Příkaz	Popis
`INCR` klíč	Zvýší celočíselnou hodnotu klíče o jednu
`INCRBY` klíčový přírůstek	Zvýší celočíselnou hodnotu klíče o dané číslo
`INCRBYFLOAT` klíčový přírůstek	Zvýší float hodnotu klíče o danou částku
`DECR` klíč	Snižte celočíselnou hodnotu klíče o jednu
`DECRBY` snížení klíče	Snižte celočíselnou hodnotu klíče o dané číslo
`HINCRBY` přírůstek pole klíče	Zvýší celočíselnou hodnotu hash pole o dané číslo
`HINCRBYFLOAT` přírůstek pole klíče	Zvýší float hodnotu hash pole o danou částku

Redis ukládá celá čísla jako 64bitové celé číslo se znaménkem se základnou 10. Proto je maximální limit pro celé číslo velmi velké číslo: 263 - 1 = 9 223 372 036 854 775 807.

Vestavěný Time-to-Live (TTL) na klávesách Redis

Jedním z běžných případů použití v měření je sledování využití v čase a omezení prostředků po vypršení času. V Redisu lze pro klíče nastavit hodnotu doby životnosti. Redis automaticky deaktivuje klíče po nastaveném časovém limitu. V následující tabulce je uvedeno několik metod vypršení platnosti klíčů.

Příkaz	Popis
`EXPIRE` klíčové sekundy	Nastavte čas klíče tak, aby žil v sekundách
`EXPIREAT` klíčové časové razítko	Nastavte dobu platnosti klíče jako časové razítko Unixu
`PEXPIRE` klíčové milisekundy	Nastavit čas klíče na život v milisekundách
`PEXPIREAT` klíčové časové razítko	Nastavte dobu platnosti klíče jako časové razítko UNIX v milisekundách
`SOUBOR` klíčová hodnota [EX sekund] [PX milisekundy]	Nastavte hodnotu řetězce na klíč spolu s volitelným časem života

Níže uvedené zprávy vám poskytnou čas k životu na klávesách v sekundách a milisekundách.

Příkaz	Popis
`TTL` klíč	Získejte čas žít pro klíč
`PTTL` klíč	Získejte čas na život za klíč v milisekundách

Redis datové struktury a příkazy pro efektivní počítání

Redis je oblíbený pro své datové struktury, jako jsou seznamy, sady, seřazené sady, hash a hyperloglogy. Mnoho dalších lze přidat prostřednictvím rozhraní API modulů Redis.

Redis Labs

Datové struktury Redis přicházejí s vestavěnými příkazy, které jsou optimalizovány pro provádění s maximální efektivitou v paměti (přesně tam, kde jsou data uložena). Některé datové struktury vám pomohou dosáhnout mnohem více než počítání objektů. Například datová struktura Set zaručuje jedinečnost všem prvkům.

Seřazená sada jde o krok dále tím, že zajišťuje, že do sady jsou přidány pouze jedinečné prvky, a umožňuje vám objednat prvky na základě skóre. Řazení prvků podle času v datové struktuře seřazené sady vám například nabídne databázi časových řad. Pomocí příkazů Redis můžete získat své prvky v určitém pořadí nebo odstranit položky, které již nepotřebujete.

Hyperloglog je další speciální datová struktura, která odhaduje počty milionů jedinečných položek, aniž by bylo nutné ukládat samotné objekty nebo ovlivňovat paměť.

Datová struktura	Příkaz	Popis
Seznam	`LLEN` klíč	Zjistěte délku seznamu
Soubor	`SCARD` klíč	Získejte počet členů v sadě (mohutnost)
Seřazená sada	`ZCARD` klíč	Získejte počet členů v seřazené sadě
Seřazená sada	`ZLEXCOUNT` klíč min. max	Spočítejte počet členů v seřazené sadě mezi daným lexikografickým rozsahem
Hash	`HLEN` klíč	Zjistěte počet polí v hash
Hyperloglog	`PFCOUNT` klíč	Získejte přibližnou mohutnost sady pozorovanou datovou strukturou Hyperloglogu
Rastrový obrázek	`BITCOUNT` klíč [začátek konec]	Počítá sadu bitů v řetězci

Redis persistence and in-memory replication

Případy použití měření, jako jsou platby, zahrnují ukládání a aktualizaci informací, které jsou pro podniky zásadní. Ztráta dat má přímý dopad na příjmy. Může také zničit fakturační záznamy, které jsou často požadavkem na dodržování předpisů nebo správu.

Konzistenci a trvanlivost v Redis můžete vyladit na základě vašich požadavků na data. Pokud potřebujete trvalý důkaz o záznamu svých údajů o měření, můžete dosáhnout trvanlivosti díky schopnostem Redisovy perzistence. Redis podporuje AOF (soubor pouze pro připojení), který kopíruje příkazy pro zápis na disk, jak k nim dochází, a snímek, který bere data tak, jak existují, v jednom okamžiku a zapisuje je na disk.

Integrovaná architektura Redis bez zámku

Zpracování Redis je jedno vlákno; Tím je zajištěna integrita dat, protože všechny příkazy pro zápis jsou automaticky serializovány. Tato architektura zbavuje vývojáře a architekty zátěže synchronizace vláken v prostředí s více vlákny.

V případě populární spotřebitelské mobilní aplikace mohou k aplikaci přistupovat současně tisíce a někdy i miliony uživatelů. Řekněme, že aplikace měří použitý čas a dva nebo více uživatelů může sdílet minuty současně. Paralelní vlákna mohou aktualizovat stejný objekt bez uložení další zátěže zajištění integrity dat. To snižuje složitost designu aplikace a zajišťuje rychlost a efektivitu.

Redis měření implementace vzorku

Podívejme se na ukázkový kód. Několik níže uvedených scénářů by vyžadovalo velmi složité implementace, pokud by použitá databáze nebyla Redis.

Blokování více pokusů o přihlášení

Aby se zabránilo neoprávněnému přístupu k účtům, webové stránky někdy blokují uživatele ve více pokusech o přihlášení ve stanovené lhůtě. V tomto příkladu omezujeme uživatele v provádění více než tří pokusů o přihlášení za hodinu pomocí jednoduché klíčové funkce Time-to-Live.

Klíč k zadržení počtu pokusů o přihlášení:

user_login_attempts:

Kroky:

Získejte aktuální počet pokusů:

ZÍSKAT user_login_attempts:

Pokud je null, pak nastavte klíč s časem vypršení platnosti v sekundách (1 hodina = 3600 sekund):

SET user_login_attempts: 1 3600

Pokud není null a pokud je počet větší než 3, proveďte chybu:

Pokud není null a pokud je počet menší nebo roven 3, zvyšte počet:

INCR user_login_attempts:

Po úspěšném pokusu o přihlášení může být klíč odstraněn následujícím způsobem:

DEL user_login_attempts:

Plaťte průběžně

Datová struktura Redis Hash poskytuje snadné příkazy ke sledování využití a fakturace. V tomto příkladu předpokládejme, že každý zákazník má své fakturační údaje uložené v hash, jak je uvedeno níže:

fakturace zákazníka:

používání

náklady

Předpokládejme, že každá jednotka stojí dva centy a uživatel spotřeboval 20 jednotek. Příkazy k aktualizaci využití a fakturace jsou:

hincrby customer: usage 20

hincrbyfloat zákazník: cena 0,40

Jak jste si možná všimli, vaše aplikace může aktualizovat informace v databázi, aniž by musela načítat data z databáze do své vlastní paměti. Kromě toho můžete upravit jednotlivé pole objektu Hash bez přečtení celého objektu.

Poznámka: Účelem tohoto příkladu je ukázat, jak používat hincrby a hincrbyfloat příkazy. V dobrém designu se vyhnete ukládání nadbytečných informací, jako je využití a cena.