Redis ტრანზაქციები (MULTI/EXEC მეშვეობით) აერთიანებს მრავალ ბრძანებას ატომურად — ყველა ერთად, სხვა ბრძანებების ჩარევის გარეშე. WATCH-თან ერთად ოპტიმისტური ლოკინგისთვის, ისინი დაეხმარება მრავალი ოპერაციის შესაბამისობის მოთხოვნილ სცენარებში. Redis ტრანზაქციები მნიშვნელოვნად განსხვავდება SQL ტრანზაქციებისგან.
MULTI # start a transaction (begin queuing commands)
SET account:1 100 # QUEUED (not executed yet)
SET account:2 200 # QUEUED
INCR counter # QUEUED
EXEC # execute ALL queued commands atomically (as one unit)
# → all commands run together, with NO other client's commands in between
MULTI იწყებს ბრძანებების რიგში დასმას; EXEC შეასრულებს მათ ყველა ატომურად (სხვა კლიენტებისგან ჩარევის გარეშე). DISCARD გააუქმებს რიგში დასმულ ტრანზაქციას.
# WATCH a key; if it CHANGES before EXEC, the transaction ABORTS (returns nil)
WATCH balance
val = GET balance # read the current value
MULTI
SET balance (val - 100) # modify based on what we read
EXEC # → if "balance" changed since WATCH, EXEC fails (returns nil)
# → retry the whole thing if it failed (optimistic concurrency control)
WATCH უზრუნველყოფს ოპტიმისტურ ლოკინგს: თუ დაკვირვებული გასაღები შეიცვლება სხვა კლიენტის მიერ EXEC-მდე, ტრანზაქცია უარი ეთქმის — რაც თქვენ დაარწმუნებთ უსაფრთხოდ შემოწმება-შემდეგ-დაყენების ოპერაციების შესრულებაში (კონფლიქტის შემთხვევაში ხელახლა სცადოთ).
⚠️ Redis transactions are NOT like SQL transactions:
✗ NO ROLLBACK — if a command fails at EXEC time, OTHER commands still execute
(errors don't roll back the transaction; Redis doesn't undo). Only syntax errors
before EXEC abort the whole thing.
✓ Atomicity = commands run together without interleaving (isolation), NOT all-or-nothing
with rollback on error.
→ Often Lua SCRIPTS are used instead for complex atomic logic (a script runs atomically).
Redis ტრანზაქციების გაგება მნიშვნელოვანია მრავალი ოპერაციის თანმიმდევრულად შესასრულებლად, ამიტომ ეს სასარგებლო ცოდნაა — და განსაკუთრებით მნიშვნელოვანია გავიგოთ, როგორ განსხვავდება ისინი SQL ტრანზაქციებისგან, რათა არ დაკეტოთ მცდარი ვარაუდები.
ძირითადი შესაძლებლობა — MULTI/EXEC ბრძანებების დაჯგუფება ატომურად (EXEC-ის დროს შესასრულებლად (ყველა ერთად, სხვა კლიენტის ბრძანებების ჩარევის გარეშე) — ეხმარება სცენარებში, სადაც მრავალი ოპერაცია უნდა შედეგი თანმიმდევრული ერთეულის სახით.
WATCH მექანიზმი უზრუნველყოფს ოპტიმისტურ ლოკინგს (შემოწმება-და-დაყენება): ტრანზაქციის უარი ეთქმის, თუ დაკვირვებული გასაღები შეიცვლა EXEC-მდე, რაც უშუეშესაძლებლობას იძლევა უსაფრთხო შემოწმება-შემდეგ-შეცვლის ოპერაციების შესრულებას (მაგალითად, ბალანსის შემცირება მის ამჟამინდელი მნიშვნელობის საფუძველზე) კონფლიქტის შემთხვევაში ხელახლა სცადოთ — ეს მნიშვნელოვანია სწორი თანამედროვე ოპერაციებისთვის.
ყველაზე კრიტიკული წერტილი არის იმის გაგება, თუ როგორ განსხვავდება Redis ტრანზაქციები SQL ტრანზაქციებისგან: Redis-ს არ აქვს ბრუნვა — თუ ბრძანება ვერ შეასრულა EXEC დროს, სხვა ბრძანებები კვლავ შეასრულდება (Redis არ უქმდება), ამიტომ "ატომურობა" აქ ნიშნავს იმას, რომ ბრძანებები ერთად შეასრულდება ჩარევის გარეშე (იზოლაცია), ნაწილ სულ-ან-არა შეცდომის გაუქმებით.
მცდარი გაგება (SQL-ის მსგავსი გაუქმების აღმოჩენა) იწვევს არასწორ შეცდომის დამუშავებას.
ცოდნა, რომ Lua სკრიპტები ხშირად გამოიყენება რთული ატომური ლოგიკისთვის (სკრიპტი განხორციელდება ატომურად ერთეულის სახით) ღირებულია.
მას შემდეგ, რაც თანმიმდევრული მრავლობითი ოპერაციის შესრულება და სწორი თანამედროვობა რეალური საჭიროებაა, და რადგან Redis ტრანზაქციები (MULTI/EXEC ოპტიმისტური ლოკინგით WATCH-ის მეშვეობით) ღებულობენ მათ, მაგრამ მნიშვნელოვანი განსხვავებებით SQL-დან (არ არის გაუქმება), რომლებიც უნდა გავიგოთ, Redis ტრანზაქციების გაგება — MULTI/EXEC, WATCH-ზე დაფუძნებული ოპტიმისტური ლოკინგი, და განსაკუთრებით არაგაუქმების განსხვავება SQL-დან — ღირებულია, პრაქტიკულად შესაბამისი ცოდნა Redis-ის სწორად გამოყენებისთვის თანამედროვე სცენარებში, სადაც გაგება განსხვავებებისა ნაცნობი SQL ტრანზაქციებიდან ისეთივე მნიშვნელოვანია, როგორც თავად მექანიზმი.