私の連絡先情報
郵便メール:
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
データベースレベルのトランザクション
データベース レベルでは、トランザクションは、すべてが正常に実行されるか、またはどれも実行されない一連の操作です。
データベーストランザクションの4大特徴
Redisトランザクション
Redis トランザクションはコマンドのセットであり、トランザクション内のすべてのコマンドはシリアル化され、一連のコマンドは 1 回限りの連続的かつ排他的な方法で実行されます。
MULTIトランザクションを開始します。EXECこのコマンドはトランザクションをトリガーします。
マルチ、実行、破棄
からのトランザクション入力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"
取引を放棄する
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
みんな一緒に座って
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.
知らせ：
コマンド セットには間違った命令が含まれています (これらは構文エラーであることに注意してください)。それらはすべて接続されていますが、すべて失敗します。
すべての不正には所有者があり、すべての借金には所有者がいます
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"
知らせ：
実行時エラー、つまり文法的以外のエラーの場合は、正しいコマンドが実行され、間違ったコマンドはエラーを返します。
概要
既存の企業では、80% の企業が主に Redis スタンドアロン サービスを使用しています。実際のシナリオでは、単一ノード上の Redis はリスクを伴いやすいです。
問題に直面している:
- 機械の故障。 Redis サーバーにデプロイします。マシンに障害が発生した場合は、別のサーバーに移行してデータが同期されていることを確認する必要があります。
- 容量のボトルネック。 Redis メモリを 16G メモリから 64G メモリに拡張する必要がある場合、1 台のマシンでは間違いなくそれを満たすことができません。もちろん、新しい 128G マシンを購入することもできます。
解決
分散データベースのより大きなストレージ容量を実現し、大量の同時アクセスに耐えるために、元の集中データベースのデータを他の複数のネットワーク ノードに保存します。
知らせ：
単一ノードのこの問題を解決するために、Redis はデータの複数のコピーを他のノードにデプロイしてレプリケーションを行い、Redis の高可用性とデータの冗長バックアップを実現してデータとサービスの高可用性を確保します。
マスタースレーブレプリケーションとは
マスター/スレーブ レプリケーションとは、1 つの Redis サーバーから他の Redis サーバーにデータをコピーすることを指します。前者はマスター ノードと呼ばれ、後者はスレーブ ノードと呼ばれます。データのレプリケーションは一方向であり、マスター ノードからスレーブ ノードへのみ可能です。
マスター/スレーブ レプリケーションの役割
設定ファイルの書き込み
新しい redis6379.conf を作成する
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
新しいredis6380.confを作成する
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
新しいredis6381.confを作成する
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
3 つの Redis サーバーを起動する
./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
システムプロセスの表示
[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
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
スレーブデータベースは搭載されていますが、マスターデータベースは搭載されていません
構文形式:
slaveof <ip> <port>
例：
6380 と 6381 で実行されました。
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
ホストでデータを書き込み、スレーブでデータを読み取る
set k1 v1
マスター/スレーブ レプリケーションは 3 つの段階に分けることができます
コピー工程は大きく6つの工程に分かれます
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
4. ping コマンドを送信します。
接続が正常に確立された後、スレーブ ノードは最初の通信の ping 要求を送信します。
効果：
- マスターとスレーブ間のネットワークソケットが利用可能かどうかを検出します。
- マスターノードが現在コマンドを受け入れられるかどうかを検出します
ASD。
requirepass パラメータがマスター ノードに設定されている場合、スレーブ ノードはパスワードがマスター ノードと同じであることを確認するようにマスター ノードを設定する必要があります。検証が失敗した場合、レプリケーションは行われません。終了すると、スレーブ ノードはレプリケーション プロセスを再開します。
データセットを同期します。
マスターとスレーブのレプリケーション接続が正常に通信した後、初めてレプリケーションが確立されると、マスター ノードは保持しているすべてのデータをスレーブ ノードに送信します。この部分の操作は最も長いステップです。
マスター/スレーブ同期戦略
マスターとスレーブが接続されたばかりの場合は完全同期が実行され、完全同期が完了すると増分同期が実行されます。もちろん、必要に応じて、スレーブはいつでも完全な同期を開始できます。 Redis の戦略では、何があっても最初に増分同期が試行され、失敗した場合はスレーブ マシンが完全同期を実行する必要があります。
例えば
キャッシュを保存する
set name jjy
録音コマンドは、
$3 r n
set r n
$4 r n
name r n
$5 r n
jjy r n
| オフセット | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 |
|---|---|---|---|---|---|---|---|---|---|
| バイト値 | $ | 3 | r | ん | $ | 4 | ん | 1つの | メートル |
7. コマンドは継続的にコピーされます。
マスターノードが現在のデータをスレーブノードに同期すると、レプリケーション確立プロセスが完了します。次に、マスター ノードは継続的に書き込みコマンドをスレーブ ノードに送信して、マスターとスレーブのデータの一貫性を確保します。
Redis マスター/スレーブ レプリケーションの欠点
ホストマスターがダウンした場合は、スイッチを手動で解決する必要があります。
露出の問題:
マスター ノードがダウンして書き込みサービスが使用できなくなった場合は、手動で切り替えてマスター ノードを再選択し、マスターとスレーブの関係を手動で設定する必要があります。
マスタースレーブスイッチング技術
マスター サーバーがダウンした場合、スレーブ サーバーをマスター サーバーに手動で切り替える必要があります。これには手動による介入が必要で、時間と労力がかかり、またサービスが一定期間利用できなくなることもあります。これは推奨されるアプローチではありません。多くの場合、以下を優先します。セントリーモード。
センチネルの概要
Sentinel モードは特殊なモードです。まず、Redis は独立したプロセスとして実行されます。原則として、センチネルはコマンドを送信し、Redis サーバーの応答を待つことによって、実行中の複数の Redis インスタンスを監視します。
センチネルの役割
新しい Sentinel-26379.conf ファイルを作成します
#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
パラメータ:
センチネル モニター 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
新しい Sentinel-26381.conf ファイルを作成します
#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
センチネルノードの起動
redis-sentinel sentinel-26379.conf
センチネルノードのステータスを表示する
[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
モニタリング段階
知らせ：
- Sentinel (sentinel 1)----->マスター (master) とスレーブ (slave) に情報を送信し、完全な情報を取得します。
- センチネル (センチネル 2)----->マスター (master) に情報を開始すると、既存のセンチネル (センチネル 1) の情報がわかり、スレーブ (スレーブ) に接続されます。
- Sentinel (sentinel 2)----->sentinel (sentinel 1) へのサブスクライブを開始します。
通知段階
Sentinel は情報を収集するためにマスターとスレーブに継続的に通知を送信します。
フェイルオーバーフェーズ
通知フェーズでは、センチネルによって送信された通知がマスターからの応答を受信しない場合、マスターを SRI_S_DOWN としてマークし、マスターが死亡したことを他のセンチネルが聞くと、マスターのステータスを各センチネルに送信します。私もそれを確認して送信します。結果は各センチネルに共有され、マスターがダウンしていると思われる場合、マスターは SRI_0_DOWN としてマークされます。
ここで次のような質問が生じます。
このとき、マスターを交代する必要があります。誰がマスターになりますか?
投票方法
方法：
選挙通知を最初に受け取った番兵のどちらがそれに投票するでしょう。
いくつかのケースを排除します。
概要
マスター ノードに障害が発生した場合の Sentinel の監視機能と自動フェイルオーバー機能を示します。
フェイルオーバーのデモンストレーション
kill コマンドを使用してマスター ノードを強制終了します。
ps aux |grep redis
kill -9 pid
センチネルノード情報の表示
すぐに 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
知らせ：
センチネルがマスターノードの障害を検出して転送するまでに時間がかかるため、マスターノードが切り替わっていないことがわかります。
ノード 6379 を再起動します
[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
設定ファイルが書き換えられる
フェールオーバー フェーズ中に、センチネル ノードとマスター/スレーブ ノードの構成ファイルが書き換えられます。
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
結論は
Redis には 3 つのクラスター モードがあります
セントリーモードのデメリット
欠点がある：
クラスターモードの概要
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
パラメータ：
- クラスタ構成ファイル: 他のノードのステータス、永続変数などが含まれるクラスタ永続構成ファイルは、上で構成した 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/
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
各ノードが正常に起動するかどうかを確認する
[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
クラスターを構成する
コマンド形式: --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
クラスターの検証
任意のクライアントに接続する
./redis-cli -h 192.168.47.100 -p 6379 -c
パラメータ:
‐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>
Redis クラスターすべてのデータは 16384 個のスロット (スロット) に分割されており、各ノードはスロットの一部を担当します。スロット情報は各ノードに格納されます。マスター ノードのみにスロットが割り当てられ、スレーブ ノードにはスロットが割り当てられません。
スロット位置決めアルゴリズム： k1 = 127001
デフォルトでは、クラスターは crc16 アルゴリズムを使用してキー値をハッシュして整数値を取得し、この整数値を 16384 を法として使用して特定のスロットを取得します。
HASH_SLOT = CRC16(キー) % 16384
回復
ビューノード
192.168.66.103:8001> cluster nodes
マスターノードを強制終了します
lsof -i:8001
kill -9 pid
ノード情報の監視
設定ファイルを変更する
spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
知らせ
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"));
}
}
私の内容がお役に立てましたら、よろしくお願いしますいいね、コメント、お気に入り 。創作は簡単ではありません、皆さんのサポートが私の原動力です
彼は 30 年以上テクノロジーの研究に専念しており、java、linux、javascript、php、css などのさまざまな言語に堪能であり、オープンソース分野で多くの貢献を行っています。将来の参考のために技術開発におけるいくつかの問題を共有する開発者ドキュメント ステーション。
郵便メール: