Транзакциите в рамките на Redis Cluster са различна история от транзакциите с Redis Standalone.
TL;DR;
Това е по-скоро концептуален проблем по отношение на гаранциите и компромисите, отколкото клиентски проблем.
Обяснение
В Redis Cluster конкретен възел е главен за един или повече хеш-слота, това е схемата за разделяне за разделяне на данни между множество възли. Един хеш-слот, изчислен от ключовете, използвани в командата, живее на един възел. Командите с множество ключове са ограничени до един и същ хеш-слот. В противен случай те се отхвърлят. Такива съзвездия се наричат кръстосани прорези.
Транзакциите изглежда са решението за изпълнение на команди към кръстосани слотове, но в определен момент човек ще напусне обхвата на един възел и ще се нуждае от друг възел, за да продължи транзакцията. Това може да бъде, ако единият ключ живее на един възел, а другият ключ живее на друг възел. Все още няма координация на транзакциите и това понякога може да бъде проблем за проблемите с Redis Cluster.
API на високо ниво, осигуряващ транзакционна поддръжка за Redis Cluster, се сблъсква с множество проблеми и досега има две стратегии, как да се справяме с транзакциите в Redis Cluster:
Поддържащи транзакции, ако всички ключове са разположени на един възел
Тази опция позволява пълнофункционални транзакции. От клиентската библиотека се изисква да следи възела, в който транзакцията се изпълнява, и да забранява ключове извън обхвата на слотовете за времето, когато транзакцията е в ход. Тъй като слотът може да бъде определен само чрез използване на команда, съдържаща ключ, клиентът трябва да зададе транзакционен флаг и при първата команда, съдържаща ключ, трябва да се издаде MULTI команда, точно преди първата команда в транзакцията. Ограничението тук очевидно е изискването всички ключове да са разположени на един възел.
Разпределени транзакции
В този случай се стартират множество транзакции на всички възли, които се присъединяват към разпределената транзакция. Тази разпределена транзакция може да включва ключове от всички главни възли. След като транзакцията бъде изпълнена, клиентската библиотека задейства изпълнението на транзакцията, библиотеката събира всички резултати (за да поддържа реда на резултатите от командите) и ги връща на повикващия.
Този стил на транзакции е прозрачен за клиента. Веднага щом ключът на конкретен възел бъде поискан и възелът все още не е част от транзакцията, MULTI се издава команда за присъединяване на възела към транзакцията. Недостатъкът тук е, че транзакциите вече не могат да бъдат условни (WATCH ). Отделните транзакции нямат информация дали ключът е променен на различен възел и така една транзакция може да бъде върната назад, докато другите транзакции биха успели. Звучи малко като двуфазно извършване.
Заключение
Redis Transactions се чувства като атомно групиране на команди, което може да се направи условно. Важно е да запомните, че изпълнението на командата се отлага, тъй като резултатите от четенето се връщат в момента на изпълнение на транзакцията, а не в момента на издаване на командата.
За Redis Cluster клиентите не са взели решение за глобална стратегия. Безопасно е да изпълнявате транзакции на конкретен възел на Redis Cluster, но сте ограничени до ключовете, обслужвани от този възел. И двете възможни стратегии имат свойства, които могат да бъдат полезни за определени случаи на употреба, но също така идват с ограничения.
