コマンド使用ガイドライン

ダウンロード

フォーカスモード

フォントサイズ

最終更新日: 2026-10-20 18:20:58

AI翻訳

Distributed Cacheはシングルスレッドモデルに基づいてコマンドリクエストを処理します。不適切なコマンド使用はインスタンス全体をブロックし、すべての業務に影響を与える可能性があります。本書では、高複雑度コマンド、禁止コマンド、データベース選択、バッチ操作、トランザクション、Luaスクリプト、Monitorコマンド、Hashtagの使用、メッセージキュー制限などの側面から、コマンド使用の規範と基準を定義します。
一、O(N)コマンドにおけるNに注目する
hgetall、lrange、smembers、zrange、sinterなどのコマンドの時間計算量はO(N)であり、使用時にNの値を明確にする必要があります。Nが大きい場合、これらのコマンドは長時間シングルスレッドを占有し、他のリクエストをブロックします。
コマンド
リスク説明
代替案
HGETALL
ハッシュテーブルの全フィールドを一度に返すため、Key内のフィールドが多すぎる場合にブロッキングが深刻になります。
HSCANカーソルを使用してバッチ単位で走査します。
SMEMBERS
セットの全メンバーを一度に返します。
SSCANカーソルを使用してバッチ単位で走査します。
ZRANGE
ソート済みセットの指定範囲内の全メンバーを一度に返します。
ZSCANカーソルを使用してバッチ単位で走査するか、クエリ範囲を縮小します。
LRANGE
リストの指定範囲内の全要素を一度に返します。
範囲を縮小するか、ページングで取得します。
SINTER
複数のセットの積集合を求める場合、要素が多いほど時間がかかります。
ビジネス側で共通集合の演算を実行します。
説明：
HSCAN、SSCAN、ZSCANコマンドを使用する際は、適切なCOUNTパラメータを指定することをお勧めします。毎回の走査で1000個前後の要素を返すのが比較的適切な選択です。具体的な数はインスタンス構成と業務シナリオに応じて調整する必要があります。
二、使用禁止コマンド
以下のコマンドは本番環境での使用を禁止または制限します。Redisはシングルスレッドで動作するため、これらのコマンドは実行時間が長すぎたり、操作リスクが高すぎたりすると、コマンド実行のブロックやデータ損失を引き起こしやすくなります。パラメータdisable-command-listを設定して無効化することをお勧めします。
コマンド
リスク説明
代替案
KEYS
すべてのキーを走査してパターンに一致させ、Redisサーバーをブロックします。
SCANカーソルを使用した段階的なマッチングを行います。
FLUSHDB
現在のデータベースの全データを消去し、復元できません。
SCAN + DELによる段階的な削除を行います。
FLUSHALL
インスタンス内の全データベースのデータをすべて消去し、復元できません。
SCAN + DELによる段階的な削除を行います。
SHUTDOWN
Redisサーバーをシャットダウンし、サービス中断とデータ損失を引き起こします。
コンソールからインスタンスのライフサイクルを管理します。
CONFIG
サーバーのランタイム設定を変更し、操作を誤るとクラッシュを引き起こす可能性があります。
コンソールからインスタンスパラメータを変更します。
以下のコマンドは本番環境で頻繁に使用することはお勧めしません：
コマンド
リスク説明
使用推奨事項
RANDOMKEY
キーをランダムに1つ返し、Redisサーバーをブロックします。
テスト環境でのみ使用してください。
INFO
サーバー統計情報を返し、実行中に他のリクエストをブロックします。
問題の切り分け時のみ短時間使用してください。
BGREWRITEAOF
AOFファイルを非同期で書き換え、大量のシステムリソースを消費します。
システムにより自動的にトリガーされます。手動実行は避けてください。
BGSAVE
RDBスナップショットを非同期で生成し、大量のシステムリソースを消費します。
システムにより自動的にトリガーされます。手動実行は避けてください。
説明：
運用保守のシナリオにおいて、INFOまたはCONFIGコマンドを使用して調査する必要が確かにある場合は、低ピーク時に短時間操作し、操作完了後に速やかに終了してください。
三、Selectの適切な使用
Redisはマルチデータベース（Multi-DB）をサポートしています。データベースインデックス番号は0を開始インデックス値とし、SELECTコマンドでいつでも切り替えることができます。
アーキテクチャ
使用推奨事項
スタンダード版
複数のDBでデータを区分できますが、Redis自体はシングルスレッドで処理されるため、複数DB間のリクエストは相互に影響を及ぼします。
クラスタ版
0号DBを優先的に使用することをお勧めします。0号DB以外は拡張に対応していません。
説明：
クラスタ版のシナリオでは、クライアントが0番DBをリクエストする際にSELECT 0を実行しなくてもよく、不要なネットワークインタラクションを削減できます。
四、バッチ操作の適切な使用
アプリケーション側がRedisにアクセスする際、大きな部分の所要時間はネットワークRTTに起因します。大量のGETまたはSET操作を実行する必要がある場合は、バッチコマンドを使用してネットワークオーバーヘッドを削減できます。
方式
説明
適用シナリオ
ネイティブバッチコマンド（MGET/MSET）
アトミック操作であり、サーバー側で一括実行されます。
同種のキーを一括で読み書きします。
Pipeline
非アトミック操作であり、クライアントが複数のコマンドをまとめて送信します。
異なる種類のコマンドを一括で実行します。
反面例： 単一バッチ操作の要素数が500を超えると、単一リクエストの所要時間が長くなり、バックエンドのジッタやクラスタ拡張時に業務への影響が大きくなります。
MGET key1 key2 key3 ... key1000
正しい例： バッチ操作を複数回に分割し、毎回500要素以内に制御してください。
第一批
MGET key1 key2 ... key500
﻿
# 第二批
MGET key501 key502 ... key800
説明：
1回のバッチ操作の要素数を500以内に制御し、同時にバッチ操作の要素に大きなKeyが存在するかどうかに注意してください。
ネイティブバッチコマンドはアトミック操作であり、Pipelineは非アトミック操作です。
Pipelineは異なるコマンドをパッケージ化できますが、ネイティブバッチコマンドはサポートしていません。
Pipelineはクライアントとサーバーの両方でサポートされている必要があります。
五、トランザクションの使用は非推奨
Redisのトランザクション機能は弱く、ロールバックをサポートしていません。クラスタ版のシナリオでは、1回のトランザクション操作のKeyは同じSlot上にある必要があり、そうでない場合、トランザクションの実行は失敗します。
説明：
ビジネスでトランザクション保障が必要な場合は、Luaスクリプトの使用を推奨します。Luaスクリプトはサーバー側でアトミックに実行されますが、同様にクラスタ版ではすべての操作のKeyが同じノード上にある必要があります。
六、クラスタ版におけるLua使用の特別要件
6.1 KeyはKEYS配列で渡すこと
redis.call / redis.pcall で呼び出す Redis コマンドでは、Key の位置は必ず KEYS 配列から取得する必要があります。そうでない場合、エラーが返されます：
-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array
6.2 操作対象のKeyは同一ノードに存在すること
単一のLuaスクリプトで操作するKeyは同じノード上にある必要があります。そうでない場合、エラーが返されます：
Lua script attempted to access a non local key in a cluster node
説明：
Luaスクリプトで複数のKeyを操作する必要がある場合は、Hashtagを使用して関連するKeyを同じハッシュスロットに割り当てることができます。使用前に、本ドキュメントの第8節「Hashtagの使用に関する推奨事項」を参照してください。
七、Monitorコマンドについて
Monitorコマンドは、Redisサーバーが受信したコマンドストリームをリアルタイムに出力するために使用され、サーバーのパフォーマンスに一定の影響を与えます。
シーン
使用推奨事項
日常運用
Monitorを有効にすることはお勧めしません。
問題の切り分け
コマンド実行状況を分析するために短時間有効にすることができます。調査が完了したら速やかに無効にしてください。
説明：
Monitorを長時間有効にすると、サーバーリソースを継続的に消費し、出力バッファを占有するため、パフォーマンスが低下します。調査が必要ない場合は、有効にしないでください。
八、Hashtag活用の提案
Hashtagは、Redisクラスタが提供する特別なルールであり、特定の構文を使用して複数の異なるキーを同じハッシュスロット（Hash Slot）に強制的に割り当てることで、クロスキー操作をサポートします。不適切に使用した場合、深刻なデータとリクエストの偏りを引き起こし、この問題はクラスタ拡張によって解決できません。
8.1 Hashtagの不適切な使用によるリスク
リスクタイプ
説明
データスキュー（Memory Skew）
同一のHashtagを大量に使用するキーが特定のノードに集中し、そのノードのメモリ使用率が他のノードより大幅に高くなり、メモリアラートや容量不足が早期に発生する可能性があります。
リクエストスキュー（Hotspot）
これらのデータに対するすべての読み書きリクエストが同一ノードに集中し、そのノードが性能のボトルネックとなり、遅延の増加やクラスタ全体の停止を引き起こす可能性があります。
拡張不可性
ハッシュスロットの計算は固定のHashtagに依存します。これによって引き起こされる偏りの問題は、クラスタノードを追加しても緩和できません。
8.2 Hashtag使用ガイドライン
基準
説明
最小化と分割
すべての関連データに統一のHashtagを使用せず、業務タイプや機能モジュールごとに異なる細粒度のHashtagを使用してください。
均一な分散を確保します。
Hashtag値が全体として均等に分散されるようにしてください。元のIDの後にサフィックスを追加して手動でシャーディングできます。
必要な場合にのみ使用してください。
トランザクション、Luaスクリプト、またはマルチキーコマンドを使用する必要がある場合にのみHashtagを使用してください。無関係なキーにはこの機能を濫用しないでください。
反面例： すべてのユーザーデータに統一のHashtagを使用すると、全データが単一ノードに集中します。
SET {global}:user:1001 "data1"
SET {global}:user:1002 "data2"
SET {global}:order:5001 "order_data"
正しい例： 業務タイプごとにHashtagを分割し、データは異なるノードに分散します。
SET {user:1001}:profile "data1"
SET {user:1001}:session "session_data"
SET {order:5001}:detail "order_data"
説明：
システム設計段階でHashtagの使用方針をレビューすることをお勧めします。リリース後に調整する場合、既存データの移行が必要となり、コストが高くなります。
九、Redisをメッセージキューとして使用することの禁止
Redisをメッセージキューとして使用することは禁止されています。Redisのパブリッシュ/サブスクライブとList構造はメッセージキューのコア機能を備えておらず、容量、ネットワーク、効率、機能の面で多くの制限があります。
制限項目
説明
メッセージ永続化
RedisのPub/Subはメッセージを永続化しません。コンシューマーがオフラインの間のメッセージは失われます。
メッセージ確認
消費確認メカニズム（ACK）には対応しておらず、メッセージの確実な消費を保証できません。
蓄積能力
List構造をキューとして使用する場合、メッセージの蓄積によりメモリが大量に消費され、キャッシュ性能に影響します。
消費モデル
コンシューマーグループ、メッセージパーティショニングなどの高度な機能には対応していません。
説明：
メッセージキューのニーズがある場合は、専門的なメッセージミドルウェアの使用をお勧めします。例えば、CKafkaまたはTDMQです。

ヘルプとサポート

この記事はお役に立ちましたか？

営業担当者にお問い合わせいただくかチケットを提出してサポートを求めることができます。

フィードバック

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

コマンド使用ガイドライン

一、O(N)コマンドにおけるNに注目する

二、使用禁止コマンド

三、Selectの適切な使用

四、バッチ操作の適切な使用

五、トランザクションの使用は非推奨

六、クラスタ版におけるLua使用の特別要件

6.1 KeyはKEYS配列で渡すこと

6.2 操作対象のKeyは同一ノードに存在すること

七、Monitorコマンドについて

八、Hashtag活用の提案

8.1 Hashtagの不適切な使用によるリスク

8.2 Hashtag使用ガイドライン

九、Redisをメッセージキューとして使用することの禁止

ヘルプとサポート

コマンド	リスク説明	代替案
`HGETALL`	ハッシュテーブルの全フィールドを一度に返すため、Key内のフィールドが多すぎる場合にブロッキングが深刻になります。	`HSCAN`カーソルを使用してバッチ単位で走査します。
`SMEMBERS`	セットの全メンバーを一度に返します。	`SSCAN`カーソルを使用してバッチ単位で走査します。
`ZRANGE`	ソート済みセットの指定範囲内の全メンバーを一度に返します。	`ZSCAN`カーソルを使用してバッチ単位で走査するか、クエリ範囲を縮小します。
`LRANGE`	リストの指定範囲内の全要素を一度に返します。	範囲を縮小するか、ページングで取得します。
`SINTER`	複数のセットの積集合を求める場合、要素が多いほど時間がかかります。	ビジネス側で共通集合の演算を実行します。

コマンド	リスク説明	使用推奨事項
`RANDOMKEY`	キーをランダムに1つ返し、Redisサーバーをブロックします。	テスト環境でのみ使用してください。
`INFO`	サーバー統計情報を返し、実行中に他のリクエストをブロックします。	問題の切り分け時のみ短時間使用してください。
`BGREWRITEAOF`	AOFファイルを非同期で書き換え、大量のシステムリソースを消費します。	システムにより自動的にトリガーされます。手動実行は避けてください。
`BGSAVE`	RDBスナップショットを非同期で生成し、大量のシステムリソースを消費します。	システムにより自動的にトリガーされます。手動実行は避けてください。

アーキテクチャ	使用推奨事項
スタンダード版	複数のDBでデータを区分できますが、Redis自体はシングルスレッドで処理されるため、複数DB間のリクエストは相互に影響を及ぼします。
クラスタ版	0号DBを優先的に使用することをお勧めします。0号DB以外は拡張に対応していません。

方式	説明	適用シナリオ
ネイティブバッチコマンド（`MGET`/`MSET`）	アトミック操作であり、サーバー側で一括実行されます。	同種のキーを一括で読み書きします。
Pipeline	非アトミック操作であり、クライアントが複数のコマンドをまとめて送信します。	異なる種類のコマンドを一括で実行します。

シーン	使用推奨事項
日常運用	Monitorを有効にすることはお勧めしません。
問題の切り分け	コマンド実行状況を分析するために短時間有効にすることができます。調査が完了したら速やかに無効にしてください。

リスクタイプ	説明
データスキュー（Memory Skew）	同一のHashtagを大量に使用するキーが特定のノードに集中し、そのノードのメモリ使用率が他のノードより大幅に高くなり、メモリアラートや容量不足が早期に発生する可能性があります。
リクエストスキュー（Hotspot）	これらのデータに対するすべての読み書きリクエストが同一ノードに集中し、そのノードが性能のボトルネックとなり、遅延の増加やクラスタ全体の停止を引き起こす可能性があります。
拡張不可性	ハッシュスロットの計算は固定のHashtagに依存します。これによって引き起こされる偏りの問題は、クラスタノードを追加しても緩和できません。

基準	説明
最小化と分割	すべての関連データに統一のHashtagを使用せず、業務タイプや機能モジュールごとに異なる細粒度のHashtagを使用してください。
均一な分散を確保します。	Hashtag値が全体として均等に分散されるようにしてください。元のIDの後にサフィックスを追加して手動でシャーディングできます。
必要な場合にのみ使用してください。	トランザクション、Luaスクリプト、またはマルチキーコマンドを使用する必要がある場合にのみHashtagを使用してください。無関係なキーにはこの機能を濫用しないでください。

制限項目	説明
メッセージ永続化	RedisのPub/Subはメッセージを永続化しません。コンシューマーがオフラインの間のメッセージは失われます。
メッセージ確認	消費確認メカニズム（ACK）には対応しておらず、メッセージの確実な消費を保証できません。
蓄積能力	List構造をキューとして使用する場合、メッセージの蓄積によりメモリが大量に消費され、キャッシュ性能に影響します。
消費モデル	コンシューマーグループ、メッセージパーティショニングなどの高度な機能には対応していません。

コマンド	リスク説明	代替案
`KEYS`	すべてのキーを走査してパターンに一致させ、Redisサーバーをブロックします。	`SCAN`カーソルを使用した段階的なマッチングを行います。
`FLUSHDB`	現在のデータベースの全データを消去し、復元できません。	`SCAN` + `DEL`による段階的な削除を行います。
`FLUSHALL`	インスタンス内の全データベースのデータをすべて消去し、復元できません。	`SCAN` + `DEL`による段階的な削除を行います。
`SHUTDOWN`	Redisサーバーをシャットダウンし、サービス中断とデータ損失を引き起こします。	コンソールからインスタンスのライフサイクルを管理します。
`CONFIG`	サーバーのランタイム設定を変更し、操作を誤るとクラッシュを引き起こす可能性があります。	コンソールからインスタンスパラメータを変更します。