Redis transakce a dlouhotrvající Lua skripty

Redis nabízí dva mechanismy pro zpracování transakcí – transakce založené na MULTI/EXEC a vyhodnocení skriptů Lua. Skriptování Redis Lua je doporučený přístup a je poměrně oblíbené.

Naši zákazníci Redis™, kteří mají nasazené skripty Lua, často hlásí tuto chybu – „BUSY Redis je zaneprázdněn spuštěním skriptu. Můžete volat pouze SCRIPT KILL nebo SHUTDOWN NOSAVE “. V tomto příspěvku vysvětlíme transakční vlastnost skriptů Redis, čeho se tato chyba týká a proč na ni musíme být zvlášť opatrní na systémech spravovaných Sentinelem, které mohou přepnout na selhání.

Transakční povaha skriptů Redis Lua

Redis „transakce“ nejsou ve skutečnosti transakce, jak je chápáno konvenčně – v případě chyb nedochází k žádnému vrácení zápisů provedených skriptem.

„Atomicita“ skriptů Redis je zaručena následujícím způsobem:

• Jakmile se skript začne provádět, všechny ostatní příkazy/skripty jsou zablokovány, dokud se skript nedokončí. Ostatní klienti tedy buď vidí změny provedené skriptem, nebo ne. Je to proto, že se mohou spustit pouze před skriptem nebo za skriptem.
• Redis však neprovádí vrácení zpět, takže v případě chyby ve skriptu budou všechny změny, které již skript provedl, zachovány a budoucí příkazy/skripty uvidí tyto dílčí změny.
• Vzhledem k tomu, že všichni ostatní klienti jsou během provádění skriptu blokováni, je důležité, aby skript fungoval správně a skončil včas.

Hodnota „lua-time-limit“

Důrazně doporučujeme, aby byl skript dokončen v časovém limitu. Redis to prosazuje slabým způsobem s hodnotou „lua-time-limit“. Toto je maximální povolená doba (v ms), po kterou může skript běžet. Výchozí hodnota je 5 sekund. To je opravdu dlouhá doba pro činnost vázanou na CPU (skripty mají omezený přístup a nemohou spouštět příkazy, které přistupují k disku).

Skript však není ukončen, když se spustí po uplynutí této doby. Redis znovu začne přijímat příkazy klienta, ale odpoví na ně chybou BUSY.

Pokud musíte skript v tomto okamžiku ukončit, jsou k dispozici dvě možnosti:

• ZABÍJENÍ SKRIPTU příkaz lze použít k zastavení skriptu, který ještě neprovedl žádné zápisy.
• Pokud skript již provedl zápisy na server a musí být stále ukončen, použijte SHUTDOWN NOSAVE k úplnému vypnutí serveru.

Obvykle je lepší počkat, až skript dokončí svou operaci. Úplné informace o metodách zastavení provádění skriptu a souvisejícím chování jsou k dispozici v dokumentaci.

Chování na systémech vysoké dostupnosti monitorovaných Sentinelem

Systémy vysoké dostupnosti spravované Sentinelem tomu přidávají novou vrásku. Ve skutečnosti se tato diskuse vztahuje na jakýkoli systém vysoké dostupnosti, který závisí na dotazování na stav serverů Redis:

• Dlouhotrvající skripty zpočátku blokují příkazy klienta. Později, když „lua-time-limit“ uplyne, server začne reagovat s chybami BUSY.
• Sentinely budou takový uzel považovat za nedostupný, a pokud to přetrvá i po hodnotě dolů po milisekundách nakonfigurované na Sentinelech, určí, že uzel je nedostupný.
• Pokud je takový uzel hlavní, bude zahájeno převzetí služeb při selhání. Replikovaný uzel může být povýšen a může začít přijímat nová připojení od klientů.
• Mezitím starší master nakonec dokončí provádění skriptu a vrátí se online. Sentinel jej však nakonec překonfiguruje jako repliku a začne se synchronizovat s novým masterem. Všechna data zapsaná skriptem budou ztracena.

Ukázka

Nastavili jsme citlivý systém vysoké dostupnosti, který demonstruje toto chování při selhání. Nastavení má 2 servery Redis spuštěné v konfiguraci hlavní/replika, která je monitorována kvorem se třemi hlídkami.

Hodnota lua-time-limit byla nastavena na 500 ms, aby klientům začala reagovat chybami, pokud skript běží déle než 500 ms. Hodnota down-after-milisekundy na Sentinelech je nastavena na 5 sekund, takže uzel, který hlásí chyby, je po 5 sekundách označen DOWN.

Na hlavním serveru spustíme následující skript Lua:

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

Tím se budou nadále zapisovat položky do hlavního serveru Redis. Přihlašujeme se k odběru událostí na jedné z hlídek, abychom sledovali chování.

Skript se spouští na hlavním serveru:

$ redis-cli -a --eval test.lua Upozornění:Použití hesla s volbou '-a' nebo '-u' v rozhraní příkazového řádku nemusí být bezpečné.

Zde je zkrácená posloupnost aktivit na Sentinelu:

3) "+vote-for-leader"4) "9096772621089bb885eaf7304a011d9f46c5689f 1"1) "pmessage"2) "*"3) "+sdown" << 4) "hlavní test 172.31.2.48 6379"1) "pmessage"2) "*"3) "+odown"4) "master test 172.31.2.48 6379 #quorum 3/2"1) "pmessage"2) "* "3) "-role-change" < 4) "slave 172.31.28.197:6379 172.31.28.197 6379 @ test 172.31.2.48 6379 nová nahlášená role je master"1) "pmessage"2) "*"3) "+config-update-from"91.28.197 6379" "+config-update-from"990968520909608909090997bb72 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.238.197" pre 
Později, když je stará předloha uvedena online, změní se na repliku:
 
3) "-role-change"4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379 nová nahlášená role je master"1) "pmessage"2) "*"3) "- sdown"4) "otrok 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379"1) "pmessage"2) "*"3) "+role-change"4) "slave.172392.3. .2.48 6379 @ test 172.31.28.197 6379 nová nahlášená role je slave"
 
Všechna data zapsaná do staré předlohy pomocí skriptu jsou ztracena.
 
Doporučení
 
 
Před nasazením vašich dlouho běžících skriptů do produkce musíte předem znát vlastnosti svých dlouhodobých skriptů.
 
Pokud váš skript pravidelně porušuje časový limit lua, musíte skript důkladně zkontrolovat, aby bylo možné provést optimalizaci. Můžete jej také rozdělit na části, které dokončí v přijatelném trvání.
 
Pokud musíte spouštět skripty, které porušují časový limit lua, zvažte naplánování těchto skriptů na období, kdy bude aktivita ostatních klientů nízká.
 
Hodnotu limitu lua-time-limit lze také zvýšit. To by bylo přijatelné řešení, pokud jiné klientské aplikace, které se spouštějí paralelně se skriptem, mohou tolerovat příjem extrémně zpožděných odpovědí místo chyby BUSY a opakování později.
 
 
Další úvahy o systémech vysoké dostupnosti monitorovaných Sentinelem:
 
 
Pokud skripty provádějí pouze operace čtení a máte k dispozici repliky, můžete tyto skripty přesunout do replik.
 
 
Změňte parametr Sentinel dolů po milisekundách na hodnotu, která zajistí, že nedojde k inicializaci převzetí služeb při selhání. Musíte to udělat pouze po pečlivém zvážení, protože drastické zvýšení hodnoty ohrozí charakteristiky vysoké dostupnosti vašeho systému. To by také mohlo způsobit, že budou ignorována skutečná selhání serveru.
 

 
 
 
 
 
Další tipy pro vás
 
Seznamte se s databází Redis:Iterace přes klíče
 
Schopnost levně iterovat přes klíčový prostor Redis je velmi důležitá pro seznámení se s obsahem databáze. Naučte se různé možnosti iterace klíčového prostoru dostupné v Redis. Další informace
 
Nejčastější případy použití Redis podle typů základních datových struktur
 
Redis může fungovat jako databáze, mezipaměť nebo zprostředkovatel zpráv a neukládá data do dobře definovaných databázových schémat, která tvoří tabulky, řádky a sloupce. Místo toho Redis ukládá data do datových struktur, díky čemuž je použití velmi flexibilní. Další informace
 
6 zásadních monitorovacích metrik Redis, které musíte sledovat
 
Jak zajistíte, že vaše nasazení Redis je zdravé a splňuje vaše požadavky? Potřebujete vědět, které monitorovací metriky sledovat, a nástroj pro monitorování těchto důležitých serverových metrik, abyste zajistili jeho stav. Další informace