Redisトランザクションの深淵：ACIDの幻想と「楽観的並行性制御」の冷徹な現実
Redisのトランザクション（`MULTI`/`EXEC`）を、RDBMSのそれと同義だと誤解しているエンジニアは多い。もし君が、Redisのトランザクションを「データ整合性を担保するための万能薬」だと考えているなら、今すぐその認識を捨てろ。
Redisにおけるトランザクションとは、ACID特性を完全に保証するものではない。それは、「シングルスレッド実行モデルにおけるコマンドの連続実行の保証」という、極めてプリミティブだが強力な機能に過ぎないのだ。
今日は、Redisの内部アーキテクチャの観点から、この「偽りのトランザクション」の正体と、その限界を突破するための戦略を解剖する。
—
1. MULTI/EXEC の本質：キューイングの正体
Redisの `MULTI` を発行した瞬間、クライアントの接続状態は「トランザクションモード」へと遷移する。重要なのは、この時点でサーバー側では一切のコマンドが実行されていないということだ。
クライアントが送ったコマンドは、サーバー側のメモリ上に保持された「キュー」にただ積み上げられる。そして `EXEC` が発行された瞬間、Redisのシングルスレッドイベントループがこのキューを順次アトミックに実行していく。
- 内部メカニズム:
- Redisは単一の実行スレッドで動作する。つまり、`EXEC` が開始された瞬間に他のクライアントからのコマンドが割り込むことは物理的に不可能だ。
- これが「アトミック」と呼ばれる所以だが、ここには「ロールバックの概念が存在しない」という致命的な仕様が隠されている。
もし、キューの途中で構文エラー（`EXEC` 以前のチェックで弾かれるもの）ではなく、実行時のデータ型不一致（`LPUSH` を `SET` されたキーに行う等）が発生しても、Redisは処理を停止しない。後続のコマンドはそのまま実行される。これが、RDBMSのトランザクションとの決定的かつ暴力的な違いだ。
2. WATCH と楽観的並行性制御 (OCC)
Redisにおいて、「整合性」を担保する唯一の手段が `WATCH` コマンドだ。これは一種の楽観的並行性制御（Optimistic Concurrency Control）である。
`WATCH` を指定したキーは、`EXEC` が完了するまで「監視対象」となる。もし他のクライアントがそのキーを書き換えた場合、現在のトランザクションは `EXEC` の瞬間に `nil` を返して「失敗」する。
楽観的ロックの典型的なコード
WATCH my_key
val = GET my_key
val = val + 1
MULTI
SET my_key val
EXEC # もしこの間に他者が my_key を更新していれば、ここは nil を返す
アーキテクトの視点：なぜパフォーマンスを犠牲にするのか
`WATCH` は、クライアント側での「再試行ループ」を前提としている。高負荷な環境で衝突が頻発すれば、CPUサイクルは再試行のための無駄なリクエスト処理で浪費される。
もし君が大規模な分散環境でこの仕組みを使おうとしているなら、「本当にRedisでやる必要があるのか」を自問すべきだ。Luaスクリプトでサーバーサイドに処理を押し込めるなら、その方が遥かに低レイテンシで、かつアトミックだ。
3. Luaスクリプト：トランザクションの「真の代替」
私は、実務レベルのアーキテクチャ設計において `MULTI`/`EXEC` を使うことは稀だ。なぜなら、Luaスクリプトの方が遥かに堅牢だからだ。
Luaスクリプトは、実行中、Redisサーバー全体をブロックする（※正確にはスクリプトが終了するまで他のコマンドは待機する）。これは、トランザクションにおける「競合のリスク」を排除するだけでなく、ネットワークラウンドトリップを最小化し、メモリ上のデータ構造を直接操作する速度を最大限に引き出す。
— Luaによるアトミックな加算処理
local val = redis.call(“GET”, KEYS[1])
val = tonumber(val) + tonumber(ARGV[1])
redis.call(“SET”, KEYS[1], val)
return val
このアプローチを取ることで、クライアント・サーバー間の不必要な通信を排除し、Redisのシングルスレッドの恩恵を極限まで享受できる。
4. 結論：何を信じ、何を棄てるか
Redisのトランザクションは、ツールボックスの中にある「特定の条件下でのみ機能する特殊な道具」だ。
1. ACIDを求めるならRDBMSを使え: Redisのトランザクションは、データ整合性維持のメインエンジンではない。
2. パフォーマンスとアトミック性を両立させるならLua: `MULTI/EXEC` よりも、Redisのスクリプト実行機能の方が、低レイヤのメモリ操作としては一貫性が高い。
3. ウォッチによる衝突管理はコストを計算せよ: `WATCH` は便利だが、高コンテンション環境ではシステムを崩壊させる引き金になる。
我々エンジニアに求められているのは、フレームワークやライブラリが提供する「便利そうな機能」を鵜呑みにすることではない。そのコマンドがメモリ上でどのような挙動を示し、イベントループにどのような負荷を与え、障害時にどのような不整合を生むかを「理解」することだ。
Redisを使いこなすとは、その限界を知り、その限界をコードの設計で補うことである。コードを書く前に、まずプロトコルとイベントループの挙動を脳内でシミュレートしてみろ。それが、伝説的なアーキテクトへの第一歩だ。
コメント