ただのKVSではない#

「キーに値を入れて取り出す」だけではなく、値として データ構造 を選べるのが Redis の特徴です。

• 文字列、ハッシュ、リスト、セット、ソート済みセット
• ビットマップ、HyperLogLog、Geo、ストリーム

この豊富さが、「次に挙げる定番用途」を支えています。

定番の使いどころ#

• キャッシュ：DBに毎回問い合わせると重い結果を、Redis に置いて使い回す。TTL を付けておくと管理が楽。
• セッションストア：複数台のアプリサーバーで共通のセッションを持ちたいとき。
• レートリミッタ：INCR と TTL を組み合わせれば、シンプルなカウンタ型のレートリミットが作れる。
• ジョブキュー：リストや Streams を使った軽量なジョブキュー。Sidekiq などはこれを土台にしている。
• Pub/Sub・通知：チャネルへの publish と subscribe で、シンプルなリアルタイム通知が組める。
• ランキング：ソート済みセット（Sorted Set）でスコア順の集計が高速にできる。

運用で気にしたいこと#

• メモリが満杯になったらどうするか：maxmemory と maxmemory-policy（LRU、LFUなど）で、上限と追い出し戦略を決めておく。
• 永続化：RDB（スナップショット）か AOF（追記ログ）、あるいは両方。落ちたときにどこまで失っていいかで選ぶ。
• スケール：単一インスタンスで足りなければ、Redis Cluster による水平分割か、レプリカでの読み取り分散。
• シングルスレッド：コマンド処理は基本的にシングルスレッドなので、巨大なキーへの重いコマンド（KEYS * や巨大な LRANGE）は全体を詰まらせます。

「速さ」と「データ構造の表現力」を活かすミドルウェアであって、永続化ストレージとして DB の置き換えにする選択肢は、よほどの覚悟がないかぎり避けたほうが無難です。