Redis транзакции и дългосрочни Lua скриптове

Redis предлага два механизма за обработка на транзакции – MULTI/EXEC базирани транзакции и оценка на Lua скриптове. Redis Lua скриптовете е препоръчителният подход и е доста популярен в употреба.

Нашите клиенти на Redis™, които имат внедрени Lua скриптове, често съобщават за тази грешка – „ЗАЕТ. Redis е зает да изпълнява скрипт. Можете да извикате само SCRIPT KILL или SHUTDOWN NOSAVE “. В тази публикация ще обясним транзакционното свойство на Redis на скриптовете, за какво е тази грешка и защо трябва да бъдем особено внимателни за нея на системи, управлявани от Sentinel, които могат да преминават при отказ.

Транзакционен характер на Redis Lua скриптове

Транзакциите на Redis всъщност не са транзакции, както се разбира конвенционално – в случай на грешки няма връщане назад на записите, направени от скрипта.

„Атомарността“ на скриптовете на Redis е гарантирана по следния начин:

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

Стойността „lua-time-limit“

Силно препоръчително е скриптът да завърши в рамките на определен срок. Redis налага това по слаб начин със стойността „lua-time-limit“. Това е максималното разрешено време (в ms), през което скриптът може да се изпълнява. Стойността по подразбиране е 5 секунди. Това е наистина дълго време за дейност, свързана с процесора (скриптовете имат ограничен достъп и не могат да изпълняват команди, които имат достъп до диска).

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

Ако трябва да убиете скрипта в този момент, има две налични опции:

• УБИВАНЕ НА СКРИПТ командата може да се използва за спиране на скрипт, който все още не е записал.
• Ако скриптът вече е извършил запис на сървъра и все още трябва да бъде убит, използвайте ИЗКЛЮЧВАНЕ НА NOSAVE за да изключите напълно сървъра.

Обикновено е по-добре просто да изчакате скриптът да завърши работата си. Пълната информация за методите за прекратяване на изпълнението на скрипта и свързаното с него поведение е достъпна в документацията.

Поведение на системите за висока достъпност, наблюдавани от Sentinel

Системите с висока наличност, управлявани от Sentinel, добавят нова бръчка към това. Всъщност тази дискусия се отнася за всяка система с висока наличност, която зависи от анкетирането на сървърите Redis за здравето:

• Дългосрочните скриптове първоначално ще блокират клиентските команди. По-късно, когато „lua-time-limit“ изтече, сървърът ще започне да отговаря с грешки BUSY.
• Sentinels ще считат такъв възел за недостъпен и ако това продължи извън стойността надолу след милисекунди, конфигурирана в Sentinels, те ще определят възела да не работи.
• Ако такъв възел е главният, ще бъде инициирано преминаване при отказ. Възел-реплика може да бъде повишен и да започне да приема нови връзки от клиенти.
• Междувременно по-старият господар в крайна сметка ще завърши изпълнението на скрипта и ще се върне онлайн. Въпреки това Sentinel в крайна сметка ще го преконфигурира като реплика и ще започне да се синхронизира с новия главен. Всички данни, записани от скрипта, ще бъдат загубени.

Демонстрация

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

Стойността на lua-time-limit е зададена на 500 ms, така че да започне да отговаря на клиентите с грешки, ако скриптът се изпълнява за повече от 500 ms. Стойността надолу след милисекунди на Sentinels е зададена на 5 секунди, така че възел, който отчита грешки, се маркира НАДОЛУ след 5 секунди.

Изпълняваме следния Lua скрипт на главния:

local i =0while (true)dolocal key ="Key-" .. ilocal value ="Value-" .. iredis.call('set', key, value)i =i + 1redis.call('time ')край

Това продължава да записва записи в главния Redis. Абонираме се за събитията на един от сигналите, за да наблюдаваме поведението.

Скриптът се стартира на главния:

$ redis-cli -a --eval test.lua Предупреждение:Използването на парола с опция „-a“ или „-u“ в интерфейса на командния ред може да не е безопасно.

Ето съкратена последователност от дейности, както се вижда в Sentinel:

3) "+vote-for-leader"4) "9096772621089bb885eaf7304a011d9f46c5689f 1"1) "pmessage"2) "*"3) "+sdown" << 4) "основен тест 172.31.2.48 6379"1) "pmessage"2) "*"3) "+odown"4) "основен тест 172.31.2.48 6379 #quorum 3/2"1) "pmessage"2) "* „3) „-role-change“ <<започна промяна на роля 4) "подчинен 172.31.28.197:6379 172.31.28.197 6379 @ test 172.31.2.48 6379 нова отчетена роля е главен"1) "pmessage"2) "*"3) "+config-update-frome18f080808787878798f968f98f98f08f98f96f08f98f08f98f08f96f96f98f96f98f807 172.31.2.48 26379 @ test 172.31.2.48 6379"1) "pmessage"2) "*"3) "+switch-master"4) "test 172.31.2.48 6379 172.31.28.197"> 
По-късно, когато старият мастер бъде въведен онлайн, той се променя на реплика:
 
3) "-role-change"4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379 новата отчетена роля е главен"1) "pmessage"2) "*"3) "- sdown"4) "подчинен 172.31.2.48:6379 172.31.2.48 6379 @ тест 172.31.28.197 6379"1) "pmessage"2) "*"3) "+промяна на роля"4) "подчинен 1272.31.272. .2.48 6379 @ тест 172.31.28.197 6379 нова отчетена роля е подчинена"
 
Всички данни, записани на стария главен код чрез скрипта, се губят.
 
Препоръки
 
 
Трябва да знаете характеристиките на вашите дългосрочни скриптове предварително, преди да ги внедрите в производството.
 
Ако вашият скрипт редовно нарушава lua-времево ограничение, трябва да прегледате скрипта внимателно за възможни оптимизации. Можете също да го разделите на части, които завършват за приемлива продължителност.
 
Ако трябва да изпълнявате скриптове, които нарушават времевия лимит на lua, помислете за планиране на тези скриптове през периоди, когато активността на други клиенти ще бъде ниска.
 
Стойността на lua-time-limit също може да бъде увеличена. Това би било приемливо решение, ако други клиентски приложения, които се изпълняват паралелно със скрипта, могат да понасят получаването на изключително забавени отговори, а не грешка BUSY и повторен опит по-късно.
 
 
Допълнителни съображения относно системите с висока наличност, наблюдавани от Sentinel:
 
 
Ако скриптовете извършват само операции за четене и имате налични реплики, можете да преместите тези скриптове в репликите.
 
 
Променете параметъра Sentinel down-after-milliseconds на стойност, която ще гарантира, че няма да се инициират откази. Трябва да направите това само след внимателно обмисляне, защото увеличаването на стойността драстично ще компрометира характеристиките за висока наличност на вашата система. Това също може да доведе до игнориране на истински грешки в сървъра.
 

 
 
 
 
 
Още съвети за вас
 
Запознайте се с базата данни Redis:Итерация по ключове
 
Възможността за евтина итерация в ключовото пространство на Redis е много важна за запознаване със съдържанието на базата данни. Научете различните опции за итерация на ключово пространство, налични в Redis. Научете повече
 
Водещи случаи на използване на Redis по основни типове структура на данни
 
Redis може да действа като база данни, кеш или посредник на съобщения и не съхранява данни в добре дефинирани схеми на база данни, които представляват таблици, редове и колони. Вместо това Redis съхранява данни в структури от данни, което го прави много гъвкав за използване. Научете повече
 
6 важни показатели за мониторинг на Redis, които трябва да наблюдавате
 
Как гарантирате, че внедряването на Redis е здравословно и отговаря на вашите изисквания? Трябва да знаете кои показатели за наблюдение да гледате и инструмент за наблюдение на тези критични показатели на сървъра, за да гарантирате неговото здраве. Научете повече