Как да използвам Redis за приложения за измерване в реално време

Рошан Кумар е старши продуктов мениджър в Redis Labs .

Измерването не е просто прост проблем с преброяването. Измерването често се бърка с измерването, но обикновено е повече от това. Измерването включва измерване, но като непрекъснат процес, обикновено с цел регулиране на използването или потока на ресурса във времето. Съвременните приложения включват измерване по много различни начини, вариращи от преброяване на хора, обекти или събития до регулиране на употребата, контрол на достъпа и разпределяне на капацитет.

Решенията за измерване обикновено трябва да обработват големи обеми данни, като същевременно отговарят на строги изисквания за производителност. В зависимост от мащаба на решението, преброяването и измерването може да включва хиляди, ако не и милиони актуализации на база данни всяка секунда. Основните изисквания на базата данни за поддържане на такова решение са висока производителност за операции на запис и ниска (под милисекунда) латентност за отговори.

Redis, платформата с бази данни с отворен код в паметта, предоставя и двете предимства, като същевременно е рентабилна по отношение на използването на минимални хардуерни ресурси. В тази статия ще разгледаме някои характеристики на Redis, които го правят добър избор за измервателни решения, и как можем да използваме Redis за тази цел. Но първо, нека разгледаме няколко от най-често използваните измервания.

Общи приложения за измерване

Измерването се изисква във всяко приложение, което трябва да измерва използването на ресурс във времето. Ето четири често срещани сценария:

  1. Модели за ценообразуване въз основа на потреблението . За разлика от еднократните или базирани на абонамент модели на плащане, моделите на ценообразуване въз основа на потреблението позволяват на потребителите да плащат само за реална употреба. Потребителите се радват на по-голяма гъвкавост, свобода и спестяване на разходи, докато доставчиците получават по-голямо задържане на потребителите.

    Внедряването на такива модели може да бъде сложно. Понякога измервателната система трябва да проследява много елементи на употреба и много показатели в един план. Например доставчикът на облак може да зададе различни нива на ценообразуване за процесорни цикли, съхранение, производителност, брой възли или продължителност на времето, в което се използва услуга. Телекомуникационната компания може да зададе различни нива на разрешено потребление за минути, данни или текст. Решението за измерване трябва да налага ограничаване, таксуване или разширяване на услугите в зависимост от типа ценообразуване въз основа на потреблението.

  2. Ограничаване на използването на ресурсите . Всяка услуга в Интернет може да бъде злоупотребявана чрез прекомерна употреба, освен ако тази услуга не е ограничена. Популярните услуги като Google AdWords API и Twitter Stream API включват ограничения на тарифата поради тази причина. Някои екстремни случаи на злоупотреба водят до отказ от услуга (DoS). За да се предотвратят злоупотреби, услугите и решенията, достъпни в Интернет, трябва да бъдат проектирани с правилни правила за ограничаване на тарифата. Дори обикновените страници за удостоверяване и влизане трябва да ограничат броя на опитите за даден интервал от време.

    Друг пример, когато ограничаването на използването на ресурси става необходимо, е когато променящите се бизнес изисквания поставят по-голямо натоварване на старите системи, отколкото могат да поддържат. Ограничаването на тарифите към старите системи позволява на предприятията да се адаптират към нарастващото търсене, без да е необходимо да заменят своите стари системи.

    В допълнение към предотвратяването на злоупотреби и намаляването на натоварването, доброто ограничаване на скоростта помага и при управлението на сценарии с бърз трафик. Например API, налагащ метод за ограничаване на скоростта на груба сила, може да позволи 1000 обаждания на всеки час. Без въведена политика за оформяне на трафика, клиентът може да се обади на API 1000 пъти през първите няколко секунди на всеки час, може би надхвърляйки това, което инфраструктурата може да поддържа. Популярни алгоритми за ограничаване на скоростта като Token Bucket и Leaky Bucket предотвратяват изблици, като не само ограничават разговорите, но и ги разпределят във времето.

  3. Разпределение на ресурсите . Претоварването и закъсненията са често срещани сценарии в приложения, които се занимават с маршрутизация на пакети, управление на работа, задръствания, контрол на тълпата, съобщения в социалните медии, събиране на данни и т.н. Моделите за опашки предлагат няколко опции за управление на размера на опашката въз основа на скоростта на пристигане и заминаване, но внедряването на тези модели в голям мащаб не е лесно.

    Натрупването и задръстванията са постоянни грижи при работа с бързи потоци от данни. Умните дизайнери трябва да дефинират приемливи ограничения за дължината на опашката, като същевременно включват както мониторинг на изпълнението на опашките, така и динамично маршрутизиране въз основа на размерите на опашката.

  4. Преброяване в мащаб за вземане на решения в реално време . Сайтовете за електронна търговия, приложения за игри, социални медии и мобилни приложения привличат милиони ежедневни потребители. Тъй като повече очни ябълки дават по-големи приходи, преброяването на посетителите и техните действия точно е от решаващо значение за бизнеса. Преброяването е също толкова полезно за случаи на употреба, като повторни опити за грешки, ескалация на проблеми, предотвратяване на DDoS атаки, профилиране на трафика, разпределение на ресурси при поискване и намаляване на измамите.

Предизвикателства при измерването

Архитектите на решения трябва да вземат предвид много параметри при изграждането на приложение за измерване, започвайки с тези четири:

  1. Сложност на дизайна. Преброяването, проследяването и регулирането на обеми от данни - особено когато те достигат с висока скорост - е обезсърчаваща задача. Архитектите на решения могат да се справят с измерването на приложния слой чрез използване на езикови структури за програмиране. Подобен дизайн обаче не е устойчив на повреди или загуба на данни. Традиционните базирани на дискове бази данни са здрави и обещават висока степен на трайност на данните по време на откази. Но те не само не успяват да осигурят необходимата производителност, но и увеличават сложността без подходящите структури от данни и инструменти за прилагане на измерване.
  2. Латентност. Измерването обикновено включва многобройни постоянни актуализации на броя. Закъснението при четене / запис в мрежата и диска се увеличава при работа с големи числа. Това може да създаде огромно изоставане от данни, което да доведе до повече закъснения. Другият източник на латентност е програмен дизайн, който зарежда измервателните данни от база данни в основната памет на програмата и записва обратно в базата данни, когато приключи с актуализирането на брояча.
  3. Съвместимост и последователност. Архитектирането на решение за преброяване на милиони и милиарди елементи може да се усложни, когато събитията се заснемат в различни региони и всички те трябва да се сближат на едно място. Съгласуваността на данните става проблем, ако много процеси или нишки актуализират едновременно същия брой. Техниките за заключване избягват проблеми с последователността и осигуряват последователност на транзакционното ниво, но забавят решението.
  4. Устойчивост. Измерването засяга броя на приходите, което предполага, че ефимерните бази данни не са идеални по отношение на трайността. Хранилището с данни с памет с опции за трайност е перфектен избор.

Използване на Redis за приложения за измерване

В следващите раздели ще разгледаме как да използваме Redis за решения за отчитане и измерване. Redis има вградени структури от данни, атомни команди и възможности за изживяване (TTL), които могат да се използват за използване на случаи на измерване. Redis работи на една нишка. Следователно всички актуализации на базата данни са сериализирани, което позволява на Redis да работи като хранилище за данни без заключване. Това опростява дизайна на приложението, тъй като разработчиците не трябва да харчат никакви усилия за синхронизиране на нишките или прилагане на заключващи механизми за съгласуваност на данните.  

Атомни команди Redis за броене

Redis предоставя команди за увеличаване на стойностите, без да се изисква четенето им в основната памет на приложението.

Команда Описание
INCR ключ Увеличаване на целочислената стойност на ключ по един
INCRBY увеличение на клавиша Увеличаване на целочислената стойност на ключ с дадено число
INCRBYFLOAT увеличение на клавиша Увеличете плаващата стойност на ключ с дадената сума
DECR ключ Намалете целочислената стойност на ключ по един
DECRBY декрет на ключ Намалете целочислената стойност на ключ с даденото число
HINCRBY увеличение на ключовото поле Увеличаване на целочислената стойност на хеш поле с даденото число
HINCRBYFLOAT увеличение на ключовото поле Увеличете плаващата стойност на хеш поле с дадената сума

Redis съхранява цели числа като базово 10 64-битово подписано цяло число. Следователно максималното ограничение за цяло число е много голямо число: 263 - 1 = 9 223 372 036 854 775 807.

Вградено време за живот (TTL) на клавишите Redis

Един от често срещаните случаи на използване при измерването е проследяване на употребата спрямо времето и ограничаване на ресурсите след изтичане на времето. В Redis можете да зададете стойност за времето на живот за ключовете. Redis автоматично ще деактивира клавишите след зададено време за изчакване. Следващата таблица изброява няколко метода на изтичащите ключове.

Команда Описание
EXPIRE ключови секунди Задайте времето на клавиша да живее в секунди
EXPIREAT ключова времева марка Задайте изтичането за ключ като Unix времева марка
PEXPIRE ключови милисекунди Задайте времето на ключ да живее в милисекунди
PEXPIREAT ключова времева марка Задайте изтичането на даден ключ като UNIX времева марка в милисекунди
SET ключова стойност [EX секунди] [PX милисекунди] Задайте стойност на низа на ключ заедно с незадължителното време за живот

Съобщенията по-долу ви дават време за живот на клавишите по отношение на секунди и милисекунди.

Команда Описание
TTL ключ Намерете време да живеете за ключ
PTTL ключ Намерете време за живот за ключ за милисекунди

Redis структури от данни и команди за ефективно преброяване

Redis е обичан заради своите структури от данни като Списъци, Набори, Сортирани набори, Хешове и Хиперлоги. Много повече могат да се добавят чрез Redis API модули.

Лаборатории Redis

Структурите на данни Redis се предлагат с вградени команди, които са оптимизирани за изпълнение с максимална ефективност в паметта (точно там, където се съхраняват данните). Някои структури от данни ви помагат да постигнете много повече от броенето на обекти. Например, структурата от данни Set гарантира уникалност на всички елементи.

Сортираният набор отива още една стъпка напред, като гарантира, че към него се добавят само уникални елементи и ви позволява да подреждате елементите въз основа на резултат. Подреждането на вашите елементи по време в Сортирана структура от данни, например, ще ви предложи база данни с времеви редове. С помощта на командите Redis можете да получите елементите си в определен ред или да изтриете елементи, които вече не са ви необходими.

Hyperloglog е друга специална структура от данни, която изчислява милиони уникални елементи, без да е необходимо да съхранявате самите обекти или да въздействате върху паметта.

Структура на данни Команда Описание
Списък LLEN ключ Вземете дължината на списък
Комплект SCARD ключ Вземете броя на членовете в даден набор (мощност)
Сортиран комплект ZCARD ключ Вземете броя на членовете в сортиран набор
Сортиран комплект ZLEXCOUNT ключ мин. макс Пребройте броя на членовете в сортиран набор между даден лексикографски диапазон
Хеш HLEN ключ Получете броя на полетата в хеш
Хиперлог PFCOUNT ключ Получете приблизителната мощност на набора, наблюдавана от структурата на данните на Hyperloglog
Растерно изображение BITCOUNT ключ [начало край] Брои зададени битове в низ

Redis постоянство и репликация в паметта

Случаите на използване на измерване, като плащания, включват съхраняване и актуализиране на информация, която е от решаващо значение за бизнеса. Загубата на данни има пряко въздействие върху приходите. Той може също така да унищожи записи за фактури, които често са изискване за съответствие или управление.

Можете да настроите последователността и трайността в Redis въз основа на вашите изисквания за данни. Ако имате нужда от постоянно доказателство за запис на вашите измервателни данни, можете да постигнете трайност чрез възможностите на Redis за устойчивост. Redis поддържа AOF (файл само за добавяне), който копира команди за запис на диск, както се случват, и моментна снимка, която взема данните, каквито съществуват в даден момент и ги записва на диск.

Вградена архитектура Redis без заключване

Обработката на Redis е с една резба; това гарантира целостта на данните, тъй като всички команди за запис автоматично се сериализират. Тази архитектура освобождава разработчиците и архитектите от тежестта на синхронизирането на нишки в многонишкова среда.

В случай на популярно потребителско мобилно приложение, хиляди, а понякога и милиони потребители могат да имат достъп до приложението едновременно. Да приемем, че приложението измерва използваното време и двама или повече потребители могат да споделят минути едновременно. Паралелните нишки могат да актуализират един и същ обект, без да налагат допълнителна тежест за осигуряване на целостта на данните. Това намалява сложността на дизайна на приложението, като същевременно гарантира бързина и ефективност.

Реализации на измервателни измервания Redis

Нека да разгледаме примерния код. Няколко от сценариите по-долу ще изискват много сложни внедрения, ако използваната база данни не е Redis.

Блокиране на множество опити за влизане

За да се предотврати неоторизиран достъп до акаунти, уебсайтовете понякога блокират потребителите да правят множество опити за влизане в рамките на определен период от време. В този пример ние ограничаваме потребителите да правят повече от три опита за влизане в рамките на един час, използвайки проста ключова функционалност за време на живот.

Ключът за съхраняване на броя опити за влизане:

user_login_attempts:

Стъпки:

Получете текущия брой опити:

ВЗЕМЕТЕ user_login_attempts:

Ако е нула, задайте ключа с времето на изтичане в секунди (1 час = 3600 секунди):

Задайте user_login_attempts: 1 3600

Ако не е нула и ако броят е по-голям от 3, тогава изхвърлете грешка:

Ако не е нула и ако броят е по-малък или равен на 3, увеличете броя:

INCR user_login_attempts:

При успешен опит за влизане ключът може да бъде изтрит, както следва:

DEL user_login_attempts:

Плащайте по пътя

Структурата на данни Redis Hash осигурява лесни команди за проследяване на използването и фактурирането. В този пример, нека приемем, че данните за фактуриране на всеки клиент се съхраняват в хеш, както е показано по-долу:

customer_billing:

     използване

     цена

     .

     .

Да предположим, че всяка единица струва два цента, а потребителят консумира 20 единици. Командите за актуализиране на използването и фактурирането са:

hincrby клиент: използване 20

клиент на hincrbyfloat: цена .40

Както може би сте забелязали, вашето приложение може да актуализира информацията в базата данни, без да изисква да зарежда данните от базата данни в собствената си памет. Освен това можете да модифицирате отделно поле на Hash обект, без да четете целия обект.

Моля, обърнете внимание: Целта на този пример е да се покаже как да използвате hincrbyи hincrbyfloatкоманди. При добър дизайн избягвате да съхранявате излишна информация, като например употреба и разходи.