【テクニカル・上級編】 DISCARDコマンド – Redis

Redisトランザクションの深層：`DISCARD` が示すシングルスレッドの美学とメモリ管理の裏側

データベースのトランザクションといえば、ACID特性、特にAtomicity（原子性）やIsolation（隔離性）を保証するための複雑なロック機構やWrite-Ahead Log（WAL）、そしてUndo/Redoログの嵐を思い浮かべるだろう。

しかし、Redisの世界は異なる。
Redisのトランザクション（`MULTI` / `EXEC` / `DISCARD`）は、RDBのようなロールバック機構を持たない。単なる「コマンドのバッチ実行キューイング」に過ぎない。この設計思想の是非については過去に幾度となく議論されてきたが、今回はその中でも「トランザクションの破棄」を司る `DISCARD` コマンドにスポットを当てる。

表面的なコマンドの使い方などリファレンスを見れば済む話だ。本稿では、C言語で実装されたRedisのソースコードの深部に潜り、`DISCARD` がメモリ上で何を行っているのか、そしてこの単純なコマンドがRedisのシングルスレッドアーキテクチャにおいていかに洗練されたメカニズムで動いているのかを、チーフアーキテクトの視点から解き明かす。

—

1. `DISCARD` の内部挙動：C言語レベルでの実体

Redisはシングルスレッドのイベントループ（Reactorパターン）で動作している。複数のクライアントからリクエストが同時に到達しても、それらは完全にシリアライズされて処理される。

クライアントが `MULTI` を発行した瞬間、Redisの内部構造体 `client`（`server.h` で定義される）の状態が変化する。

/ server.h の client 構造体（抜粋・概念的表現） /
typedef struct client {
// …
int flags; / クライアントのフラグ (CLIENT_MULTI など) /
multiState mstate; / トランザクションの状態を保持する構造体 /
// …
} client;

`multiState` 構造体こそが、キューイングされたコマンドのリストを保持する実体である。

/ トランザクションの状態を保持する構造体 /
typedef struct multiState {
multiCmd commands; / キューイングされたコマンドの配列 /
int count; / キューに入っているコマンドの総数 /
int flags; / TRANSACTION_DIRTY_CAS などのフラグ /
} multiState;

ここで `DISCARD` コマンドが実行された時、Redis内部では何が起きているのか。
処理の核心は `discardTransaction(client c)` 関数に集約されている。

`discardTransaction` のライフサイクル

1. コマンドバッファの解放: `mstate.commands` 配列に格納されていた `multiCmd` 構造体（各コマンドの引数、引数の長さ、コマンドポインタ）が走査され、動的に割り当てられていたメモリが `zfree()` によって解放される。
2. メモリの返却: これにより、キューイングのために一時確保されていたヒープメモリが即座にOS（あるいはRedisのアロケータであるjemalloc）へ返却される。
3. フラグのクリア: クライアントの `flags` から `CLIENT_MULTI` が剥がされ、`mstate.count` が `0` にリセットされる。

特筆すべきは、この一連の処理が完全にアトミックであり、他のクライアントの介入を一切許さないという点だ。シングルスレッドで動くRedisにおいて、キューの破棄はポインタの書き換えとメモリ解放の連続に過ぎず、複雑なロック解放待ち（Latch Contention）が発生する余地すらない。

—

2. メモリ最適化の観点から見た `DISCARD` の重要性

大規模な分散システムや高ス負荷なマイクロサービスアーキテクチャにおいて、メモリリークやフラグメンテーションは死活問題である。ここで、実務上見落とされがちな「トランザクションとメモリ」の罠について言及しよう。

キューイングが引き起こすメモリプレッシャー

アプリケーション層のバグやネットワークの切断により、`MULTI` を発行したものの `EXEC` も `DISCARD` も送信されない「ゾンビ状態のトランザクション」がクライアントセッション内に残留することがある。

もしクライアントが巨大なペイロード（数MB〜数十MBの文字列やハッシュなど）を含むコマンドを何千件も `MULTI` の中にキューイングしたまま放置した場合、そのデータ構造はすべて `client` 構造体の `mstate` 内のメモリ上に保持され続ける。

[Client Connection]
└── mstate (multiState)
├── multiCmd [1] -> 巨大な文字列データ (Heap)
├── multiCmd [2] -> 巨大な文字列データ (Heap)
└── … (累積メモリ消費の増大)

Redisインスタンス全体のメモリ使用量が `maxmemory` に達している極限状態において、このような放置されたトランザクションは OOM（Out of Memory）を引き起こすトリガーとなり得る。

`DISCARD` による即時回収の保証

ここで `DISCARD` を明示的に発行することの真の価値が見えてくる。
`DISCARD` は単に「状態を戻す」だけでなく、「そのトランザクションのために確保されたヒープメモリの即時解放（Deferred freeingではなくSynchronous freeing）」を強制する。

Redisのメモリ管理（jemalloc / libc malloc）において、細切れに確保されたコマンド引数のメモリブロックを迅速に解放し、フラグメンテーションの悪化を防ぐ上で、`DISCARD` は極めてクリーンな動作をする。

—

3. `EXEC` との比較：アトミック性の幻想とエラーハンドリング

多くのエンジニアが誤解している点として、Redisのトランザクションは「途中で失敗したらロールバックされる」わけではない。

`EXEC` の場合：キュー内のコマンドは順番に実行される。途中で構文エラーや型エラー（例：文字列に対して `HSET` を実行）が発生しても、残りのコマンドは実行され続ける。
`DISCARD` の場合：実行ボタンが押される前（`EXEC` 前）に、そのバッチ全体を「無かったこと」にする。

つまり、`DISCARD` は「実行前の安全装置」である。
アプリケーション層でバリデーションエラーや前提条件の不一致（CAS：Check-And-Set の失敗など）を検知した場合、速やかに `DISCARD` を送信することが、無駄なコマンド実行の抑止とメモリの早期解放において最適解となる。

擬似的なアプリケーションロジックのフロー
MULTI
SET user:1001:lock “acquired”
HINCRBY user:1001:stats login_count 1
万が一、ここで前提条件（例: ユーザーが既に存在しない等）が崩れていると判明した場合
DISCARD
=> 即座にキューがクリアされ、メモリが解放される。サーバー側への負荷は最小限に抑えられる。

—

4. チーフアーキテクトからの提言：プロダクション環境でのベストプラクティス

現場のコードレビューをしていると、`MULTI`/`EXEC` の中でアプリケーション側の重い処理や外部APIコールを挟み込み、結果として `DISCARD` も `EXEC` も呼ばれないままコネクションがプールに戻されるアンチパターンに遭遇することがある。

極限の高スループットを求めるシステム設計において、以下の原則を厳守してほしい。

1. トランザクション内での外部I/Oの排除: Redisのトランザクションブロック（`MULTI` から `DISCARD` / `EXEC` まで）の間に、絶対にブロックする可能性のある処理を挟まないこと。シングルスレッドの美学を殺すだけでなく、クライアント側のバッファ溢れやタイムアウトを誘発する。
2. 例外処理（Error Handling）の確実な実装: アプリケーション側で例外が発生した際、必ず `finally` ブロック等で `DISCARD` を発行する防御的プログラミングを徹底せよ。これを怠ると、前述の通りコネクションプールの再利用時に予期せぬトランザクション汚染やメモリ肥大化を招く。
3. Luaスクリプトとの使い分け: 複雑な条件分岐やアトミックな操作が必要な場合、トランザクション＋ `DISCARD` の組み合わせよりも、`EVAL` によるLuaスクリプトの利用を強く推奨する。LuaスクリプトはRedisサーバー側でアトミックに実行され、クライアントとの往復ネットワークラウンドトリップ（RTT）を削減できるため、アーキテクチャの観点からより堅牢である。

—

結び

`DISCARD` は地味なコマンドだ。華やかなデータ構造操作や、ミリ秒を争うキャッシュ戦略の陰に隠れがちである。
しかし、その内部実装を見れば、Redisという極限まで最適化されたインメモリデータベースの「無駄を削ぎ落とした美学」が凝縮されていることがわかる。

システムの本質を理解するとは、こうした隅っこの仕様に込められた作者の意図と、メモリの挙動までを脳内でトレースできることだ。今日のコードから、無駄なトランザクションの残骸を綺麗に `DISCARD` する準備はできているか？