Redis Pub/Subの深淵：`UNSUBSCRIBE`の低レイヤメカニズムとクライアント状態管理の真実
RedisのPub/Sub機能は、そのシンプルさと爆発的なスループットから、多くのリアルタイムアーキテクチャの基盤として採用されてきた。しかし、その内部実装、特に「購読の解除（`UNSUBSCRIBE`）」という一見地味な操作が、Redisのイベントループやメモリ管理においてどのようなコストと状態遷移を伴うのかを正確に理解しているエンジニアは少ない。
今回は、Pub/Subアーキテクチャの心臓部である `UNSUBSCRIBE` コマンドに焦点を当て、Redisが内部で抱えるクライアント構造体の変遷、メモリの動的解放、そしてネットワークI/Oの境界線について、実装レベルの知見を暴いていく。
—
1. クライアント状態の内部表現：なぜ `UNSUBSCRIBE` は軽量ではないのか
Redisはシングルスレッドのイベント駆動アーキテクチャ（Epoll / Kqueue）で動作する。各クライアント接続は `client` という巨大なC言語の構造体（`server.h` で定義）として管理されている。
Pub/Subにおいて、この `client` 構造体は以下の2つの主要なハッシュテーブル（あるいはリスト）を保持する。
1. `pubsub_channels`: クライアントが現在購読しているチャネルを管理するハッシュテーブル（Dictionary）。
2. `pubsub_patterns`: パターンベース（`PSUBSCRIBE`）で購読しているパターンを管理するリスト/ハッシュ。
`UNSUBSCRIBE` コマンドが発行された瞬間、Redisサーバー内部では以下の処理が同期的に実行される。
// server.c / pubsub.c の概念的イメージ
int clientUninstallChannelSubscription(client c, robj channel) {
// 1. pubsub_channels ハッシュからチャネルを削除
if (dictDelete(c->pubsub_channels, channel) == DICT_OK) {
// 2. グローバルなチャネル購読マップ（server.pubsub_channels）からもクライアントを排除
pubsubUnsubscribeChannel(c, channel);
return 1;
}
return 0;
}
ここで重要なのは、グローバルなチャネル管理マップからのデクリメントと、クライアント固有のハッシュからの削除がアトミックに行われる点である。特定のチャネルを購読している全クライアントのリスト（Linked List）から該当クライアントをO(1)〜O(N)で引き抜く操作が発生する。
—
2. `UNSUBSCRIBE` レスポンスの厳密なプロトコル構造
`UNSUBSCRIBE` を発行した際、クライアントが受け取るレスポンスは、単なる成否のフラグではない。複数チャネルの同時解除や、パターン購読の有無によって、レスポンスの配列長が動的に変化する。
実務でクライアントライブラリを自作、あるいはチューニングする際に見落としがちな、レスポンスのシリアライゼーション構造を解剖する。
レスポンスのフォーマット（RESP2 / RESP3）
コマンド：`UNSUBSCRIBE notifications chat`
この場合、Redisは解除したチャネルの数だけ配列を返す。
3
$11
unsubscribe
$12
notifications
:1
3
$11
unsubscribe
$4
chat
:0
レスポンスの各要素の解剖
1. バルクストリング (`unsubscribe`): コマンドの確認応答。
2. バルクストリング (チャネル名): 正常に購読解除されたチャネル名。
3. 整数 (`:1`, `:0`): そのクライアントが現在保持している残りの購読チャネル数。
最後の整数値が `0` になった瞬間、Redisの内部ではクライアントのPub/Subモードが解除され、通常のコマンド処理モード（Normal Mode）へと降格する。この状態遷移の判定コストは極めて低いが、高頻度でコネクションを共有するアーキテクチャでは、このカウンタの追跡がメモリ断片化を防ぐ鍵となる。
—
3. メモリ管理の罠：ゴーストチャネルとグローバルハッシュの収縮
多くのエンジニアが誤解している点として、あるチャネルを購読している最後のクライアントが `UNSUBSCRIBE` を実行したとき、Redisサーバー内部のグローバルな `server.pubsub_channels` ハッシュテーブルから、そのチャネルのエントリが即座に完全削除されるという挙動があげられる。
void pubsubUnsubscribeChannel(client c, robj channel) {
dict channels = server.pubsub_channels;
robj cnumobj;
int retval = dictDelete(c->pubsub_channels, channel);
// グローバルマップからクライアントを削除
list clients = dictFetchValue(server.pubsub_channels, channel);
listDelNode(clients, lnode);
// もしこのチャネルを購読するクライアントが0になったら
if (listLength(clients) == 0) {
dictDelete(server.pubsub_channels, channel); // ハッシュのエントリ自体を破棄
}
}
この設計により、誰も購読していない「ゴーストチャネル」がメモリ上に残り続け、メモリリークのような枯渇を引き起こすことは防がれている。
しかし、極限の低レイヤ視点では、`dictDelete` によるハッシュテーブルの縮小（rehashing）のタイミングが問題になる。数百万の動的な一時チャネルが短時間で `SUBSCRIBE` と `UNSUBSCRIBE` を繰り返した場合、Redisの辞書型（dict.c）におけるメモリーフラグメンテーション（jemallocの断片化）が加速する。
—
4. アーキテクトが知るべき実践的アンチパターンと限界突破の知見
大規模分散システムにおいて、Pub/Subと `UNSUBSCRIBE` を雑に扱うと、以下のボトルネックに直面する。
アンチパターン：接続ごとの動的 `SUBSCRIBE`/`UNSUBSCRIBE` の乱用
「必要な時だけ購読し、不要になったら即座に `UNSUBSCRIBE` する」という設計は、クリーンに見えてRedisサーバーのCPUキャッシュ効率を悪化させる。
`server.pubsub_channels` のハッシュ操作と、それに伴うメモリのアロケーション/解放（jemallocのarena操作）が頻発し、システムコール（マルチスレッド環境ではないが、メモリ管理レイヤ）のロック競合やCPUサイクルの無駄な消費を招く。
限界突破のためのチューニング指針
1. 永続コネクションの維持:
高スプレッドなイベント配信基盤では、チャネルの動的増減を避け、クライアント側でイベントのルーティング（フィルタリング）を完結させるか、固定化されたチャネル設計を採用する。
2. RESP3の活用:
Redis 6以降で導入されたRESP3を使用することで、Pub/Subのメッセージがプッシュ型で非同期に流れてくる際のパース効率が最適化される。ただし、`UNSUBSCRIBE` 時のストリーム制御のロジックはクライアント側で厳密にハンドリングする必要がある。
3. モニターとメモリプールの監視:
`INFO memory` における `mem_fragmentation_ratio` を常に監視し、Pub/Subの頻繁な結合・切断が jemalloc に与えている影響を観測すること。必要であれば、Redisの再起動なきリハッシュを促す設定や、クライアントの切断・再接続ローテーションを設計に組み込むべきである。
—
結び
`UNSUBSCRIBE` は単なる「お片付けコマンド」ではない。それは、Redisというインメモリ・データストアが、動的に変化するクライアントの関心事をどのようにメモリ空間から安全かつ効率的に消去するかという、洗練されたアルゴリズムの結晶である。
表面的なコマンドのリファレンスを覚えるフェーズは終わった。アーキテクトたる者、その背後でうごめくC言語のポインタ操作、ハッシュの再配置、そしてネットワークバッファの挙動までを脳内に描けなければならない。
コメント