TIL

07. Redis Transaction

• Redis 트랜잭션은 MULTI/EXEC/DISCARD/WATCH로 여러 명령을 하나로 묶어 원자적·격리 실행하는 기능
• SQL 트랜잭션과 다른 점이 핵심
  • 롤백이 없음 — 실행 중 한 명령이 실패해도 나머지는 그대로 적용됨
  • 격리는 보장하지만 ACID의 원자성(전부 성공 or 전부 실패)은 보장하지 않음
• 핵심 두 축
  • MULTI/EXEC: 명령을 큐에 모아 한 번에 실행 (원자성·격리)
  • WATCH: 낙관적 락(CAS)으로 “읽고 판단 후 쓰기”를 안전하게

핵심 명령

MULTI

• 트랜잭션 시작. 이후 명령은 즉시 실행되지 않고 큐에 쌓임
• 큐에 쌓이는 각 명령은 결과 대신 QUEUED를 반환

EXEC

• 큐에 쌓인 명령을 순차·원자적으로 실행하고 결과 배열을 반환
• 실행 중 다른 클라이언트의 명령이 사이에 끼어들 수 없음 (단일 스레드)

MULTI            # OK
SET k1 v1        # QUEUED
INCR counter     # QUEUED
EXEC             # 1) OK  2) (integer) 5   ← 큐 전체를 한 번에 실행

DISCARD

• 큐를 비우고 트랜잭션을 취소 (아무 명령도 실행 안 함)
• 감시 중인 키도 함께 해제

WATCH / UNWATCH

• WATCH key [key ...]: 키를 감시 대상으로 등록 (MULTI 전에 호출해야 함)
• UNWATCH: 모든 감시 해제 (EXEC·DISCARD 시 자동 해제됨)

원자성과 격리

• Redis는 단일 스레드라 EXEC가 큐 전체를 하나의 작업 단위로 실행
• 따라서 트랜잭션 중간에 다른 클라이언트 요청이 처리되지 않음 → 격리 보장
• 단, 이 “원자성”은 격리·일괄 실행을 의미하며 실패 시 되돌리는 원자성은 아님

에러 처리와 롤백 없음

큐잉 단계 에러 → 트랜잭션 전체 취소

• 문법 오류·잘못된 인자 수·없는 명령처럼 큐에 넣는 시점에 잡히는 에러
• 서버가 트랜잭션을 오류로 표시하고, EXEC 시 실행을 거부 (EXECABORT) → 아무것도 실행 안 됨

실행 단계 에러 → 나머지는 그대로 실행

• 타입이 안 맞는 명령처럼 EXEC 실행 시점에야 나는 에러
• 해당 명령만 에러로 처리되고 다른 명령은 그대로 실행됨 (롤백 없음)

MULTI
SET k "hello"    # QUEUED
INCR k           # QUEUED (문자열에 INCR → 실행 시 에러)
LPUSH list a     # QUEUED
EXEC
# 1) OK   2) (error) ...   3) (integer) 1   ← 2번이 실패해도 1·3번은 적용됨

롤백을 지원하지 않는 이유

• 실행 단계 에러는 대부분 타입 오류 등 프로그래밍 실수라 운영 전에 걸러야 할 문제로 봄
• 롤백을 빼서 Redis를 단순하고 빠르게 유지하는 설계 선택

WATCH — 낙관적 락 (CAS)

• WATCH한 키가 EXEC 전에 다른 클라이언트에 의해 변경되면 → EXEC가 nil 반환하고 큐 전체 취소
• 키를 잠그지 않음 — 다른 클라가 읽고 쓰는 건 자유, 다만 그랬으면 내 EXEC가 실패 → 비관적 락(차단)이 아니라 낙관적(변경 감지 후 취소), 사실상 CAS(Compare-And-Swap)
• 변경 감지는 “touched” 플래그 기반 → 같은 값으로 덮어써도 변경으로 간주되어 취소될 수 있음

왜 WATCH가 필요한가

• MULTI만으로는 “읽고 → 판단 → 쓰기”가 불가능
  • 큐에 쌓인 명령은 EXEC 전엔 값을 반환하지 않으므로, 읽은 값으로 분기할 수 없음
• 그래서 읽기는 WATCH와 MULTI 사이에서 하고, 그 사이 값이 안 바뀌었음을 WATCH가 보장

표준 CAS 패턴

WATCH balance            # 감시 시작
cur = GET balance        # 현재 값 읽기 (WATCH ~ MULTI 사이)
# 앱에서 계산·검증: new = cur - 100 (잔액 충분한지)
MULTI
SET balance <new>
EXEC                     # balance가 그새 바뀌었으면 nil → 처음부터 재시도

트랜잭션 ≠ 파이프라이닝

• 파이프라이닝: 여러 명령을 한 번에 전송해 RTT만 줄이는 것 → 원자성·격리 보장 없음
• 트랜잭션: 거기에 원자적 일괄 실행과 격리를 더한 것
• 보통 MULTI~EXEC 자체도 파이프라인으로 보내 성능을 챙김

한계

• 고경합 키에서는 WATCH 재시도가 몰려 retry storm 발생
• 감시할 키를 미리 알아야 함
• 복잡한 read-modify-write는 재시도 없이 서버에서 원자 실행하는 Lua 스크립트가 유리 → 08. Lua Scripting에서 비교

참고

• Redis 공식 — Transactions
• Redis Blog — You Don’t Need Transaction Rollbacks in Redis