第5章 Redis関連の設定(redis.conf)
1) 測定単位の説明（大文字と小文字は区別されません）
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.
2)
デフォルトでは、bind=127.0.0.1 はローカル マシンからのアクセス要求のみを受け入れることができます
。これを記述しない場合は、制限なく任意の IP アドレスからのアクセスを受け入れることができます。本番環境では、ローカル マシンのアドレスを記述する必要があります。アプリケーション サーバー。
保護モードが有効な場合、バインド IP が設定されておらず、パスワードも設定されていない場合、Redis はこのマシンからのリクエストのみを受け入れることができます。
#bind 127.0.0.1
protected-mode no
3) ポートサービスのポート番号
port 6379
4)
daemonize がバックグラウンドプロセスであるかどうか
daemonize yes
5) pidfile は
pid ファイルの場所を保存します。各インスタンスは異なる pid ファイルを生成します。
pidfile /var/run/redis_6379.pid
6) ログファイル
ログファイルの保存場所
logfile ""
7)
データベース設定ライブラリの数はデフォルトで 16 です
databases 16
8) requirepass
パスワードを設定する
requirepass 123456
127.0.0.1:6379> k1 v1 を設定
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth "123456"
OK
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> get k1
"v1"
9) maxmemory は、
Redis が使用できるメモリの量を設定します。メモリ使用量の上限に達すると、Redis は内部データの削除を試みます。削除ルールは maxmemory-policy で指定できます。Redis が削除ルールに従ってメモリ内のデータを削除できない場合、または「削除が許可されていない」場合、
Redis は、SET、LPUSH など、メモリに適用する必要がある命令に対してエラー メッセージを返します。
# maxmemory <bytes>
10) maxmemory-policy
の削除戦略
# maxmemory-policy noeviction
#volatile-lru: LRU アルゴリズムを使用してキーを削除します。有効期限が設定されているキーのみ
#allkeys-lru: LRU アルゴリズムを使用してキーを削除します。 #
volatile-lfu: LFU 戦略を使用してキーを削除し、有効期限を設定するキー操作のみを使用します。
# allkeys-lfu : LFU 戦略を使用してキーを削除します
#volatile-random: 期限切れのセットからランダムなキーを削除し、有効期限が設定されたキーのみを操作します
#allkeys-random: ランダムなキーを
削除します # volatile-ttl: 最小値を持つキーを削除しますTTL 値、つまり最近期限切れになるキー
#noeviction: 削除しないでください。書き込み操作の場合、エラー メッセージが返されるだけです。
11) Maxmemory-samples は
サンプル数を設定します。LRU アルゴリズムと最小 TTL アルゴリズムは正確なアルゴリズムではなく推定値であるため、サンプル サイズを設定できます。一般的には 3 ～ 7 の数値が設定され、値が小さいほどサンプルの精度は低くなりますが、パフォーマンスの消費は少なくなります。
# maxmemory-samples 5
第6章 ジェダイ
Jedis は Redis の Java クライアントであり、Java コードを通じて Redis を操作できます。
6.1 環境の準備
1) 依存関係を追加する
redis.clients jedis 3.3.0 ## 6.2 基本テスト 1) 接続性のテストpublic class JedisDemo
{
public static void main(String[] args) {
//创建一个客户端对象, 连接服务端
Jedis jedis = new Jedis("hadoop102", 6379);
//向服务端发送命令
String res = jedis.ping();
//如果是读操作，解析返回的结果
System.out.println(res);
//关闭客户端
jedis.close();
}
}
Hadoop102 がサービスを開始します。
2) 接続プール
接続プールは主に、redis サービスへの各接続によって発生する接続消費を保存し、接続されたインスタンスを再利用するために使用されます。
public class JedisPoolDemo
{
public static void main(String[] args) {
//创建一个存放客户端连接的池子
JedisPool jedisPool = new JedisPool("hadoop102", 6379);
//从池子中借一个连接
Jedis jedis = jedisPool.getResource();
//向服务端发送命令
String res = jedis.ping();
//如果是读操作，解析返回的结果
System.out.println(res);
//将连接还回池子
//如果连接是从池中借来的，自动还回池子，如果不是借的，是直接new的，那么就关闭
jedis.close();
}
}
第 7 章 Redis の永続化
7.1 2 つの方法
Redis は、RDB と AOF という 2 つの異なる形式の永続性を提供します。
RDB は完全なスナップショット バックアップであり、バックアップ中にメモリ内のすべてのデータをディスク上のファイルに保存します。(少量のデータに適しており、大量のデータはリソースを消費します)
AOF は増分ログ バックアップであり、すべての書き込み操作コマンドをログ ファイルに追加して記録するだけではありません。
7.2 RDB（Redisデータベース）
7.2.1 それは何ですか
指定された時間間隔内にメモリ内のデータ セットのスナップショットをディスクに書き込みます (専門用語では Snapshot スナップショット)。Redis サービスが開始されると、指定された場所にあるスナップショット ファイルがメモリに直接読み込まれます。
7.2.2 バックアップ構成
RDB バックアップはデフォルトで自動的に有効になるため、手動で有効にする必要はありません。使用しない場合は、dbfilename の後の値を空白に設定するだけで済みます。
1) RDB で保存したファイル
redis.conf でファイル名を設定します。デフォルトは dump.rdb です。
dbfilename dump.rdb
2) RDB ファイルの保存パスは、
Redis 起動時にコマンドラインが置かれているディレクトリがデフォルトですが、変更することもできます。
dir ./
7.2.3 RDB自動保存戦略
# save <seconds> <changes>
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
# Note: you can disable saving completely by commenting out all "save" lines.
save 900 1
save 300 10
save 60 10000
7.2.4 RDB手動保存
(1) save: 実行中、サーバーはクライアントの読み取りと書き込みをブロックします。完全バックアップ。
(2) bgsave: 実行中、サーバーはクライアントの読み書きをブロックせず、バックアップしながらサービスを行うため、速度が遅くなります。
(3) シャットダウン時、サービスはすぐにバックアップを実行してシャットダウンします。
(4) flashall でクリアされたデータをバックアップします。
7.2.5 その他の RDB 設定
1) rdb を保存するときに、ファイルを圧縮します。
rdbcompression yes
2) ファイルを検証します
。ストレージ スナップショットの後、Redis にデータ検証に CRC64 アルゴリズムを使用させることもできますが、これによりパフォーマンスの消費が約 10% 増加します。パフォーマンスを最大限に向上させたい場合は、この機能をオフにすることができます
。
7.2.6 RDBのメリットとデメリット
1) 利点:
AOF と比較して、ディスク容量が節約され、復元が高速になります。災害復旧 (ディスクからクラウドにデータを復元する方法) に適しています。
2) 欠点:
Redis はフォーク中にコピーオンライト技術を使用しますが、データが巨大な場合は依然としてパフォーマンスを消費します。
バックアップ サイクル中に一定の間隔でバックアップを作成するため、Redis が予期せずダウンした場合、最後のスナップショット以降の変更はすべて失われます。
7.3 AOF (Append Only File)
7.3.1
各書き込み操作をログの形式で記録し (テキスト ファイルには追加情報は保存されません)、Redis によって実行されたすべての書き込み命令を記録します (読み取り操作は記録されません)。ファイルは追加のみ可能ですが、書き換えはできません。Redis は起動開始時にファイルを読み取り、データを再構築します。つまり、Redis が再起動すると、ログ ファイルの内容に従って書き込みコマンドが前から後ろに実行されます。データ復旧を完了します。
7.3.2 AOF を有効にする1) AOF はデフォルトでは有効になっていません。
設定ファイルで
appendonly yes を手動で設定する必要があります。
2) AOF ファイルの
appendfilename "appendonly.aof"
3) AOF ファイルが保存される場所は、次のパスと一致しています。 RDB
dir RDB パスの
7.3.3 AOF バックアップ戦略
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
毎秒appendfsync
7.3.4 AOF ファイルの損傷の回復
redis-check-aof --appendonly.aof を修正
7.3.5 書き換え
AOF はファイルを追加する方式を採用しているため、ファイルがどんどん大きくなってしまうのを避けるために、AOF ファイルのサイズが設定されたしきい値を超えると、Redis がファイルの書き換えを開始する書き換え機構が追加されています。 AOF ファイル。データを復元できる最小限の命令セットを保持します。書き換えはコマンド bgrewriteaof を使用して手動で開始できます。
ただし、再書き込みによりディスク容量が大幅に節約され、回復時間が短縮されます。ただし、書き換えごとに一定の負荷がかかるため、Redis は書き換え前に特定の条件を満たさなければならないように設定されています。
システムがロードされるとき、または最後の書き換えが完了すると、Redis はこの時点で AOF サイズを記録し、Redis の AOF の現在のサイズ >=base_size +base_size*100% (デフォルト) および現在のサイズ >=64mb (デフォルト) の場合、Redis は AOF を書き換えます。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
7.3.6 AOF の長所と短所
1) 利点:
(1) バックアップ メカニズムがより堅牢になり、データ損失の可能性が低くなります。デフォルトでは、失われるデータは 1 秒だけであり、極端な場合には、最後の操作のデータのみが失われます。
(2) ログテキストが読みやすく、AOFファイルを操作することで誤操作に対応できます。
2) 欠点:
(1) RDB と比較して、より多くのディスク容量を必要とします
(2) バックアップの復元に時間がかかります
(3) すべての書き込みが同期されている場合、パフォーマンスに一定のプレッシャーがかかります
(4) リカバリを引き起こす個別のバグがあります失敗
7.4 永続化の優先順位
AOF の優先順位は RDB の優先順位よりも高く、AOF と RDB が同時に有効になっている場合、Redis サービスの開始時に AOF が優先され
ます
。
(2) データに敏感でない場合は、RDB のみを使用することもできます
(3) AOF のみを使用するのは、バグが発生する可能性があるため推奨されません。
(4) 純粋なメモリキャッシュを行うだけの場合は必要ありません
シナリオに応じて: キャッシュの場合は有効にする必要はありませんが、
データベースとして使用する場合は、最良の場合、データの一部が失われます。データベースとして使用したい場合は、 、このデータ損失のリスクを許容する必要があります。