技術共有

7.11 日の学習チェックイン —— 初心者向け Redis 学習 (6)

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

7.11 デイスタディチェックイン

ここに画像の説明を挿入します

1.redisトランザクション

トランザクションと ACID プロパティの概念

ここに画像の説明を挿入します
データベースレベルのトランザクション

データベース レベルでは、トランザクションは、すべてが正常に実行されるか、またはどれも実行されない一連の操作です。

データベーストランザクションの4大特徴

  • A: アトミック、アトミック性は、すべての SQL をアトミックな作業単位として実行します。すべてが実行されるか、まったく実行されません。
  • C: 一貫性。トランザクション完了後、すべてのデータのステータスは一貫しています。つまり、アカウント A から 100 が減算されている限り、アカウント B に 100 が追加されます。
  • I: 分離。複数のトランザクションが同時に実行される場合、各トランザクションによって行われた変更は他のトランザクションから分離する必要があります。
  • D: 期間、永続性。つまり、トランザクションの完了後、データベース データへの変更が永続的に保存されます。

Redisトランザクション

Redis トランザクションはコマンドのセットであり、トランザクション内のすべてのコマンドはシリアル化され、一連のコマンドは 1 回限りの連続的かつ排他的な方法で実行されます。

ここに画像の説明を挿入します

Redis トランザクションの 3 つの主要な特徴

  • 個別の隔離作業 : トランザクション内のすべてのコマンドはシリアル化され、順番に実行されます。トランザクションの実行中、他のクライアントから送信されたコマンド要求によって中断されることはありません。
  • 分離レベルの概念がない: キュー内のコマンドは、トランザクションが送信されるまで実際には実行されません。トランザクションが送信される前に命令が実際に実行されることはないため、「トランザクション内の更新を確認するためのトランザクション内でのクエリや、トランザクション外でのクエリ」は存在しません。トランザクションが「見えません」。
  • アトミック性の保証はない: 同じ Redis トランザクション内でコマンドの実行に失敗した場合でも、後続のコマンドはロールバックせずに実行されます。

Redis トランザクション実行の 3 つの段階

ここに画像の説明を挿入します

  • オンにする:によるMULTIトランザクションを開始します。
  • チームに参加する: 複数のコマンドをトランザクションにエンキューします。これらのコマンドは受信後すぐに実行されず、実行を待機するトランザクション キューに置かれます。
  • 埋め込む:によるEXECこのコマンドはトランザクションをトリガーします。

Redisトランザクションの基本操作

ここに画像の説明を挿入します
マルチ、実行、破棄

からのトランザクション入力Multiコマンドが開始されると、入力されたコマンドは 1 つずつコマンド バッファ キューにプッシュされ、実行されるまで実行されません。Execその後、Redis は前のコマンド バッファ キュー内のコマンドを順番に実行します。チーム編成プロセス中に、パスを渡すことができますdiscardチームを辞めてください。

127.0.0.1:6379> set t1 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set id 12
QUEUED
127.0.0.1:6379(TX)> get id
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK
2) "12"
3) (integer) 2
4) (integer) 3
5) "3"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

取引を放棄する

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> set age 29
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> DISCARD
OK
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

みんな一緒に座って

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> get name
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> set email
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

知らせ
コマンド セットには間違った命令が含まれています (これらは構文エラーであることに注意してください)。それらはすべて接続されていますが、すべて失敗します。

すべての不正には所有者があり、すべての借金には所有者がいます

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set age 11
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> set email [email protected]
QUEUED
127.0.0.1:6379(TX)> incr email
QUEUED
127.0.0.1:6379(TX)> get age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (integer) 5
3) OK
4) (error) ERR value is not an integer or out of range
5) "11"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

知らせ
実行時エラー、つまり文法的以外のエラーの場合は、正しいコマンドが実行され、間違ったコマンドはエラーを返します。

2. Redisクラスター

マスター/スレーブ レプリケーション

ここに画像の説明を挿入します
概要
既存の企業では、80% の企業が主に Redis スタンドアロン サービスを使用しています。実際のシナリオでは、単一ノード上の Redis はリスクを伴いやすいです。

問題に直面している:

  • 機械の故障。 Redis サーバーにデプロイします。マシンに障害が発生した場合は、別のサーバーに移行してデータが同期されていることを確認する必要があります。
  • 容量のボトルネック。 Redis メモリを 16G メモリから 64G メモリに拡張する必要がある場合、1 台のマシンでは間違いなくそれを満たすことができません。もちろん、新しい 128G マシンを購入することもできます。

解決

分散データベースのより大きなストレージ容量を実現し、大量の同時アクセスに耐えるために、元の集中データベースのデータを他の複数のネットワーク ノードに保存します。

知らせ
単一ノードのこの問題を解決するために、Redis はデータの複数のコピーを他のノードにデプロイしてレプリケーションを行い、Redis の高可用性とデータの冗長バックアップを実現してデータとサービスの高可用性を確保します。

マスタースレーブレプリケーションとは

マスター/スレーブ レプリケーションとは、1 つの Redis サーバーから他の Redis サーバーにデータをコピーすることを指します。前者はマスター ノードと呼ばれ、後者はスレーブ ノードと呼ばれます。データのレプリケーションは一方向であり、マスター ノードからスレーブ ノードへのみ可能です。

ここに画像の説明を挿入します
マスター/スレーブ レプリケーションの役割

  • データの冗長性: マスター/スレーブ レプリケーションは、永続性に加えてデータ冗長化方法であるデータのホット バックアップを実装します。
  • 回復: マスター ノードで問題が発生した場合、スレーブ ノードは迅速な障害回復を実現するためのサービスを提供できます。これは実際には一種のサービスの冗長性です。
  • 負荷分散: マスター/スレーブ レプリケーションに基づいて、読み取りと書き込みが分離されているため、マスター ノードは書き込みサービスを提供し、スレーブ ノードは読み取りサービスを提供できます (つまり、Redis データを書き込む場合、アプリケーションはマスター ノードに接続する必要があります) 、Redis データを読み取るとき、アプリケーションはスレーブ ノードに接続する必要があります)、サーバーの負荷を共有する、特に書き込みが少なく読み取りが多いシナリオでは、複数のスレーブ ノードを通じて読み取り負荷を共有すると、Redis サーバーの同時実行性が大幅に向上します。 。
  • 高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションはセンチネルとクラスターの実装の基礎でもあります。したがって、マスター/スレーブ レプリケーションは Redis の高可用性の基礎となります。

マスタ/スレーブレプリケーション環境のセットアップ

ここに画像の説明を挿入します
設定ファイルの書き込み
新しい redis6379.conf を作成する

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
  • 1
  • 2
  • 3
  • 4

新しいredis6380.confを作成する

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
  • 1
  • 2
  • 3
  • 4

新しいredis6381.confを作成する

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
  • 1
  • 2
  • 3
  • 4

3 つの Redis サーバーを起動する

./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
  • 1
  • 2
  • 3

システムプロセスの表示

[root@localhost src]# ps -ef |grep redis
root    40737    1  0 22:05 ?     00:00:00 ./redis-server *:6379
root    40743    1  0 22:05 ?     00:00:00 ./redis-server *:6380
root    40750    1  0 22:05 ?     00:00:00 ./redis-server *:6381
root    40758  40631  0 22:05 pts/0   00:00:00 grep --color=auto redis
  • 1
  • 2
  • 3
  • 4
  • 5

3台のホストの稼働状態を確認する

#打印主从复制的相关信息
./redis-cli -p 6379
./redis-cli -p 6380
./redis-cli -p 6381
127.0.0.1:6379> info replication
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

スレーブデータベースは搭載されていますが、マスターデータベースは搭載されていません

構文形式:

slaveof  <ip> <port>
  • 1

例:

6380 と 6381 で実行されました。

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
  • 1
  • 2

ホストでデータを書き込み、スレーブでデータを読み取る

set k1 v1
  • 1

マスタースレーブレプリケーションの原理の解析

ここに画像の説明を挿入します
マスター/スレーブ レプリケーションは 3 つの段階に分けることができます

  • 接続確立フェーズ (つまり、準備フェーズ)
  • データ同期フェーズ
  • コマンド伝播段階

コピー工程は大きく6つの工程に分かれます

ここに画像の説明を挿入します

  1. マスターノード(master)の情報を保存します。
    スレーブオブ実行後のステータス情報の表示
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  1. スレーブ ノード (スレーブ) は、毎秒実行されるスケジュールされたタスクを通じてレプリケーション関連のロジックを維持します。スケジュールされたタスクは、新しいマスター ノードの存在を検出すると、そのノードとのネットワーク接続を確立しようとします。
    ここに画像の説明を挿入します
  2. スレーブノードとマスターノード間のネットワーク接続を確立します。
    スレーブ ノードはソケットを確立します。ポート 51234 は、マスター ノードによって送信されたレプリケーション コマンドを受け入れるために特に使用されます。

ここに画像の説明を挿入します
4. ping コマンドを送信します。

接続が正常に確立された後、スレーブ ノードは最初の通信の ping 要求を送信します。

ここに画像の説明を挿入します

効果:

  • マスターとスレーブ間のネットワークソケットが利用可能かどうかを検出します。
  • マスターノードが現在コマンドを受け入れられるかどうかを検出します
  1. ASD。
    requirepass パラメータがマスター ノードに設定されている場合、スレーブ ノードはパスワードがマスター ノードと同じであることを確認するようにマスター ノードを設定する必要があります。検証が失敗した場合、レプリケーションは行われません。終了すると、スレーブ ノードはレプリケーション プロセスを再開します。

  2. データセットを同期します。
    マスターとスレーブのレプリケーション接続が正常に通信した後、初めてレプリケーションが確立されると、マスター ノードは保持しているすべてのデータをスレーブ ノードに送信します。この部分の操作は最も長いステップです。
    ここに画像の説明を挿入します

マスター/スレーブ同期戦略

マスターとスレーブが接続されたばかりの場合は完全同期が実行され、完全同期が完了すると増分同期が実行されます。もちろん、必要に応じて、スレーブはいつでも完全な同期を開始できます。 Redis の戦略では、何があっても最初に増分同期が試行され、失敗した場合はスレーブ マシンが完全同期を実行する必要があります。

例えば

キャッシュを保存する

set name jjy
  • 1

録音コマンドは、

$3 r n
set r n
$4 r n
name r n
$5  r n
jjy r n
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
オフセット100010011002100310041005100610071008
バイト値$3r$41つのメートル

7. コマンドは継続的にコピーされます。
マスターノードが現在のデータをスレーブノードに同期すると、レプリケーション確立プロセスが完了します。次に、マスター ノードは継続的に書き込みコマンドをスレーブ ノードに送信して、マスターとスレーブのデータの一貫性を確保します。

センチネル監視

ここに画像の説明を挿入します
Redis マスター/スレーブ レプリケーションの欠点

ホストマスターがダウンした場合は、スイッチを手動で解決する必要があります。

ここに画像の説明を挿入します

露出の問題:
マスター ノードがダウンして書き込みサービスが使用できなくなった場合は、手動で切り替えてマスター ノードを再選択し、マスターとスレーブの関係を手動で設定する必要があります。

マスタースレーブスイッチング技術

マスター サーバーがダウンした場合、スレーブ サーバーをマスター サーバーに手動で切り替える必要があります。これには手動による介入が必要で、時間と労力がかかり、またサービスが一定期間利用できなくなることもあります。これは推奨されるアプローチではありません。多くの場合、以下を優先します。セントリーモード

センチネルの概要

Sentinel モードは特殊なモードです。まず、Redis は独立したプロセスとして実行されます。原則として、センチネルはコマンドを送信し、Redis サーバーの応答を待つことによって、実行中の複数の Redis インスタンスを監視します。

ここに画像の説明を挿入します
センチネルの役割

  • クラスターの監視: Redis マスタープロセスとスレーブプロセスが適切に動作しているかどうかを監視する責任を負います。
  • 通知: Redis インスタンスに障害が発生した場合、センチネルはメッセージをアラーム通知として管理者に送信する責任があります。
  • フェイルオーバー: マスターノードがハングアップした場合、自動的にスレーブノードに転送されます。
  • 構成センター: フェイルオーバーが発生した場合、クライアントに新しいマスター アドレスを通知します。

センチネル監視環境構築

ここに画像の説明を挿入します

新しい Sentinel-26379.conf ファイルを作成します

#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

パラメータ:
センチネル モニター mymaster 192.168.92.128 6379 2 構成の意味は次のとおりです。センチネル ノードはマスター ノード 192.168.92.128:6379 を監視します。最後の 2 の意味は、障害の判定に関連しています。マスター ノード: 少なくとも 2 つが必要です。2 つのセンチネル ノードが一致する場合にのみ、マスター ノードの障害が判断され、フェイルオーバーが実行されます。

新しい Sentinel-26380.conf ファイルを作成します

#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

新しい Sentinel-26381.conf ファイルを作成します

#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

センチネルノードの起動

redis-sentinel sentinel-26379.conf
  • 1

センチネルノードのステータスを表示する

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> 
127.0.0.1:26379> 
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.66.100:6379,slaves=2,sentinels=3
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

Sentinelの動作原理の分析

ここに画像の説明を挿入します
モニタリング段階
ここに画像の説明を挿入します

知らせ:

  • Sentinel (sentinel 1)-----&gt;マスター (master) とスレーブ (slave) に情報を送信し、完全な情報を取得します。
  • センチネル (センチネル 2)-----&gt;マスター (master) に情報を開始すると、既存のセンチネル (センチネル 1) の情報がわかり、スレーブ (スレーブ) に接続されます。
  • Sentinel (sentinel 2)-----&gt;sentinel (sentinel 1) へのサブスクライブを開始します。

通知段階

Sentinel は情報を収集するためにマスターとスレーブに継続的に通知を送信します。

フェイルオーバーフェーズ

通知フェーズでは、センチネルによって送信された通知がマスターからの応答を受信しない場合、マスターを SRI_S_DOWN としてマークし、マスターが死亡したことを他のセンチネルが聞くと、マスターのステータスを各センチネルに送信します。私もそれを確認して送信します。結果は各センチネルに共有され、マスターがダウンしていると思われる場合、マスターは SRI_0_DOWN としてマークされます。
ここに画像の説明を挿入します
ここで次のような質問が生じます。

このとき、マスターを交代する必要があります。誰がマスターになりますか?

投票方法

方法:

選挙通知を最初に受け取った番兵のどちらがそれに投票するでしょう。

いくつかのケースを排除します。

  • オンラインではありません
  • 応答が遅い
  • オリジナルマスターから長期間切断されている
  • 優先原則

フェイルオーバー

ここに画像の説明を挿入します
概要
マスター ノードに障害が発生した場合の Sentinel の監視機能と自動フェイルオーバー機能を示します。

フェイルオーバーのデモンストレーション
kill コマンドを使用してマスター ノードを強制終了します。

ps aux |grep redis
kill -9 pid
  • 1
  • 2

センチネルノード情報の表示

すぐに Sentinel ノードで info Sentinel コマンドを使用して表示した場合。

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=5,sentinels=3
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

知らせ
センチネルがマスターノードの障害を検出して転送するまでに時間がかかるため、マスターノードが切り替わっていないことがわかります。

ノード 6379 を再起動します

[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

設定ファイルが書き換えられる
フェールオーバー フェーズ中に、センチネル ノードとマスター/スレーブ ノードの構成ファイルが書き換えられます。

include /usr/local/redis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
# Generated by CONFIG REWRITE
daemonize yes
protected-mode no
appendonly yes
slowlog-max-len 1200
slowlog-log-slower-than 1000
save 5 1
user default on nopass ~* &* +@all
dir "/usr/local/redis"
replicaof 127.0.0.1 6381
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

結論は

  • Sentinel システムのマスター/スレーブ ノードは、通常のマスター/スレーブ ノードと何ら変わりません。障害の検出と転送は Sentinel によって制御され、完了します。
  • Sentinel ノードは本質的には Redis ノードです。
  • 各センチネル ノードは、他のセンチネル ノードとスレーブ ノードを自動的に検出するように監視マスター ノードを構成するだけで済みます。
  • センチネル ノードの起動フェーズとフェイルオーバー フェーズ中に、各ノードの構成ファイルが書き換えられます (構成の書き換え)。

クラスターモード

Redis には 3 つのクラスター モードがあります

  • マスタースレーブモード
  • センチネルモード
  • クラスターモード

セントリーモードのデメリット
ここに画像の説明を挿入します
欠点がある

  • マスターが電話を切ると、選挙中にセンチネルがマスターを選出します。Redis にアクセスする方法はなく、アクセスが一時的に中断されます。
  • セントリー モードでは、マスター ノードのみが外部から書き込み可能で、スレーブ ノードは読み取りのみに使用できます。単一の Redis ノードは最大 10W QPS をサポートしますが、電子商取引プロモーション中は、データ書き込みのすべてのプレッシャーがマスターにかかります。
  • Redis の単一ノードのメモリを大きく設定しすぎると、ノードの起動時にマスターとスレーブの同期が非常に遅くなり、時間がかかります。

クラスターモードの概要
ここに画像の説明を挿入します
Redis クラスターは、複数のマスター/スレーブ ノード グループで構成される分散サービス クラスターであり、レプリケーション、高可用性、シャーディング機能を備えています。

Redis クラスターの利点

  • Redis クラスターには複数のマスターがあるため、一時的なアクセス問題の影響を軽減できます。
  • Redis クラスターには複数のマスターがあり、より高い同時実行性を実現できます。
  • Redis クラスターはシャードに保存できるため、より多くのデータを保存できます

クラスターモード構築

Redis クラスターの構築には、少なくとも 3 つのマスター ノードが必要です。ここでは、それぞれにスレーブ ノードを持つ 3 つのマスターを構築し、合計 6 つの Redis ノードを構築します。
ここに画像の説明を挿入します
クラスター構築

ポート番号がそれぞれ 6379、6380、6381、6382、6383、および 6384 の 6 つの異なる Redis ノードを作成します。

知らせ注: dump.rdb および appendonly.aof ファイルは、コピーする前に削除する必要があります。

1. 新しい設定ファイルを作成します
redis6379.config、redis6380.config、redis6381.config、redis6382.config、redis6383.config、redis6384.config ファイルを作成し、ファイルのポート番号に対応するように構成ファイル内のポート番号を変更します。

daemonize yes
dir /usr/local/redis-7.2.4/redis-cluster/6382/
bind 192.168.47.100
port 6382
dbfilename dump6382.rdb
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000
appendonly yes
protected-mode no
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

パラメータ

  • クラスタ構成ファイル: 他のノードのステータス、永続変数などが含まれるクラスタ永続構成ファイルは、上で構成した dir ディレクトリに自動的に生成されます。各ノードは動作中にクラスター構成ファイルを維持します。クラスター情報が変更されるたびに (ノードの追加または削除など)、クラスター内のすべてのノードは、ノードの再起動時に最新の情報を構成ファイルに更新します。構成ファイルを使用してクラスター情報を取得すると、クラスターに簡単に再参加できます。クラスター構成ファイルは Redis によって保守され、手動で変更する必要はありません。
  • clouster-enabled: クラスターを有効にします。

フォルダーを作る

mkdir -p /usr/local/redis-7.2.4/redis-cluster/6379/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6380/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6381/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6382/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6383/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6384/
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

6 つのノードを開始します

[root@bogon src]# ./redis-server ../redis6379.config
[root@bogon src]# ./redis-server ../redis6380.config
[root@bogon src]# ./redis-server ../redis6381.config
[root@bogon src]# ./redis-server ../redis6382.config
[root@bogon src]# ./redis-server ../redis6383.config
[root@bogon src]# ./redis-server ../redis6384.config
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

各ノードが正常に起動するかどうかを確認する

[root@bogon src]# ps -ef | grep redis
root    3889    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6379 [cluster]
root    3895    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6380 [cluster]
root    3901    1 0 09:57 ?    00:00:03 ./redis-server 0.0.0.0:6381 [cluster]
root    3907    1 0 09:57 ?    00:00:02 ./redis-server *:6382 [cluster]
root    3913    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6383 [cluster]
root    3919    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6384 [cluster]
root    4247  2418 0 10:22 pts/0  00:00:00 grep --color=auto redis
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

クラスターを構成する

コマンド形式: --cluster-replicas 1 は、マスターごとにスレーブ ノードを作成することを意味します

知らせ: ここでの IP は、各ノードが配置されているマシンの実際の IP です。

[root@localhost src]# ./redis-cli --cluster create 192.168.47.100:6379 192.168.47.100:6380 192.168.47.100:6381 192.168.47.100:6382 192.168.47.100:6383 192.168.47.100:6384 --cluster-replicas 1
  • 1

ここに画像の説明を挿入します

クラスターの検証

任意のクライアントに接続する

./redis-cli -h 192.168.47.100  -p 6379 -c
  • 1

パラメータ:

‐h : ホストアドレス
-p : ポート番号
‐c: クラスタモードを示します

データ書き込みテスト

[root@bogon src]# ./redis-cli -p 6379 -c
127.0.0.1:6379> set name zhangsan
-> Redirected to slot [5798] located at 192.168.47.100:6380
OK
192.168.47.100:6380> get name
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> get name
-> Redirected to slot [5798] located at 192.168.47.100:6380
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> readonly
OK
127.0.0.1:6383> get name
"zhangsan"
127.0.0.1:6383>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

クラスターパターン原理の解析

Redis クラスターすべてのデータは 16384 個のスロット (スロット) に分割されており、各ノードはスロットの一部を担当します。スロット情報は各ノードに格納されます。マスター ノードのみにスロットが割り当てられ、スレーブ ノードにはスロットが割り当てられません。

ここに画像の説明を挿入します

スロット位置決めアルゴリズム: k1 = 127001

デフォルトでは、クラスターは crc16 アルゴリズムを使用してキー値をハッシュして整数値を取得し、この整数値を 16384 を法として使用して特定のスロットを取得します。

HASH_SLOT = CRC16(キー) % 16384

回復
ビューノード

192.168.66.103:8001> cluster nodes
  • 1

マスターノードを強制終了します

lsof -i:8001
kill -9 pid
  • 1
  • 2

ノード情報の監視

ここに画像の説明を挿入します

Java オペレーティング Redis クラスター

ここに画像の説明を挿入します
設定ファイルを変更する

spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
  • 1

知らせ
1. 高可用性を確保するには、Redis クラスターに少なくとも 3 つのノードが必要です。
2. Redis クラスターの実行中はノードの追加または削除を避ける必要があります。これは、データの移行が発生し、Redis クラスターの全体的なパフォーマンスに影響を与える可能性があるためです。

Javaで書かれたコード

@SpringBootTest
public class CluseterTest {

  @Autowired
  private RedisTemplate<String,Object> redisTemplate;

  @Test
  void string() {
    //  保存字符串
    redisTemplate.opsForValue().set("itbaizhan","itbaizhan123");

    System.out.println(redisTemplate.opsForValue().get("itbaizhan"));

   }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

私の内容がお役に立てましたら、よろしくお願いしますいいね、コメント、お気に入り 。創作は簡単ではありません、皆さんのサポートが私の原動力です
ここに画像の説明を挿入します