記事のディレクトリ
Redisのパブリッシュおよびサブスクライブ
チャンネルに登録する
127.0.0.1:6379> subscribe zzf
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "zzf"
3) (integer) 1
別の接続のチャネルにメッセージを投稿する
127.0.0.1:6379> publish zzf "hello,zzf"
(integer) 1
そこにサブスクライブすると、対応する情報を受け取ります
127.0.0.1:6379> subscribe zzf
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "zzf"
3) (integer) 1
1) "message"
2) "zzf"
3) "hello,zzf"
使用するシーン
1.シンプルなリアルタイムチャット
2.パブリッシュおよびサブスクライブモデル
Redisマスタースレーブレプリケーション
概念
マスタースレーブレプリケーションとは、あるRedisサーバーのデータを他のRedisサーバーにコピーすることです。前者はマスターノード（マスター/リーダー）と呼ばれ、後者はスレーブノード（スレーブ/フォロワー）と呼ばれます。データレプリケーションは1つです。つまり、マスターノードからスレーブノードへの移動のみが可能であり、マスターは主に書き込みを行い、スレーブは主に読み取りを行います。
デフォルトでは、各Redisサーバーがマスターノードであり、マスターノードは複数のスレーブノードを持つことができます（またはスレーブノードなし）が、スレーブノードは1つのマスターノードしか持つことができません。
マスタースレーブレプリケーションの主な機能は次のとおりです。
1.データの冗長性：マスタースレーブレプリケーションは、データのホットバックアップを実現します。これは、永続性に加えてデータの冗長性の方法です。
2.障害回復：マスターノードに問題がある場合、スレーブノードは迅速な障害回復を実現するためのサービスを提供できます。実際、これは一種のサービス冗長性です。
3.負荷分散：マスタースレーブレプリケーションに基づいて、読み取りと書き込みを分離することで、マスターノードは書き込みサービスを提供でき、スレーブノードは読み取りサービスを提供します（つまり、アプリケーションはマスターノードに接続します） Redisデータを書き込むとき、およびアプリケーションはRedisデータを読み取るときにスレーブノードに接続します。ノード）サーバーの負荷を共有します。特に、書き込みを減らして読み取りを増やすシナリオでは、複数のスレーブノードで読み取り負荷を共有すると同時実行性が大幅に向上します。 Redisサーバーの
4.高可用性の基礎：上記の機能に加えて、マスタースレーブレプリケーションはセンチネルとクラスターの実装の基礎でもあるため、マスタースレーブレプリケーションはRedisの高可用性の基礎です。
一般的に、エンジニアリングプロジェクトでRedisを使用するには、Redisを1つだけ使用するだけでは不十分です。理由は次のとおりです。
1.構造的に、単一のRedisサーバーには単一障害点があり、サーバーはすべてのリクエストの負荷を処理する必要があり、これは非常にストレスがかかります。
2.容量に関しては、Redisサーバーのメモリ容量が限られている場合、Redisサーバーのメモリ容量が256Gであっても、すべてのメモリをRedisストレージメモリとして使用することはできません。一般的に、1つのRedisで使用される最大メモリ20Gを超えてはなりません
環境構成（マスタースレーブレプリケーションクラスターテスト）
Redisサーバー情報を表示する
127.0.0.1:6379> info replication
# Replication
role:master #角色
connected_slaves:0 #连接的从机数
master_replid:8dc2e8e176e7efa3d0a21afbdc67f19f0ea9545a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
テスト用に3つのredis構成ファイルをコピーします
cp /www/server/redis/redis.conf /www/server/redis/zzfconf/redis80.conf
cp /www/server/redis/redis.conf /www/server/redis/zzfconf/redis81.conf
cp /www/server/redis/redis.conf /www/server/redis/zzfconf/redis82.conf
構成ファイルの対応する情報を変更します
1、ポート
2、pid名
3、ログファイル名
4、dump.rdb名
変更が完了したら、サービスを開始し、プロセス情報を表示します
redis-server /www/server/redis/zzfconf/redis80.conf
redis-server /www/server/redis/zzfconf/redis81.conf
redis-server /www/server/redis/zzfconf/redis82.conf
これらの3つの新しいredisサービスを使用して、マスタースレーブ操作のマスタースレーブレプリケーションを実行します
デフォルトはマスターノードです。ポート6380をマスターサーバーとして使用し、ポート6381と6382をスレーブサーバーとして使用します。スレーブサーバーにコマンドを入力します。
slaveof 127.0.0.1 6380
各サーバーの情報を再度確認してください
6380
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=56,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=56,lag=1
master_replid:452e335dd36c2d75bf664ca043b0074e678fbca3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56
6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:452e335dd36c2d75bf664ca043b0074e678fbca3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14
6382
127.0.0.1:6382> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:452e335dd36c2d75bf664ca043b0074e678fbca3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:43
repl_backlog_histlen:0
これはコマンドを介して構成され、一時的なものです
永続的な構成は、構成ファイルで構成する必要があります。この場所からコメントを削除し、ホストのIPとポートを入力して
テストします。
127.0.0.1:6380> set k1 v1
OK
127.0.0.1:6381> set k2 v2
(error) READONLY You can't write against a read only replica.
127.0.0.1:6381> get k1
"v1"
127.0.0.1:6382> set k1 v1
(error) READONLY You can't write against a read only replica.
127.0.0.1:6382> get k1
"v1"
マスターは書き込み可能ですが、スレーブは書き込みできず、読み取りしかできません。
マスターが切断されている場合、スレーブは読み取りはできますが、システム全体は書き込みできません。
マスターが書き込んだデータを読み取ることができるのはスレーブだけです。
コピーの原則
スレーブ（スレーブ）は、マスター（ホスト）に正常に接続した後、同期コマンドを送信します。マスターは、コマンドを受信してバックグラウンド保存プロセスを開始します。同時に、受信したすべてのコマンドを収集して、データセットを変更します。バックグラウンドプロセスが実行された後、マスターはデータファイル全体をスレーブに転送し、完全な同期を完了します。
完全なレプリケーション：スレーブサービスはデータベースファイルデータを受信した後、それを保存してメモリにロードします。
インクリメンタルレプリケーション：マスターは引き続きすべての新しいデータを収集します。変更コマンドはスレーブに順番に渡されて同期が完了しますが、マスターが再接続されている限り、完全な同期（完全レプリケーション）が順番に実行されます。自動的に
上記のマスタースレーブレプリケーションモデルは、1つのホストと複数のスレーブを持つ1
対多のモデルです。別のチェーンモデルも使用できます。たとえば、6380ポートサーバーがホストとして使用され、6381がのスレーブとして使用されます。 6380、6382は6381として使用されます。スレーブはチェーンを形成して正常に使用できるようにします。
マスターが切断されている場合は、それを使用してslaveof no one自分をマスターに変えることができ、他のノードは手動で最新のマスターに接続できます。ノード
センチネルモード
マスタースレーブ切り替えテクノロジーの方法は次のとおりです。マスターサーバーがダウンした場合、サーバーをマスターサーバーに手動で切り替える必要があります。これには手動による介入が必要であり、時間と手間がかかり、サービスを利用できなくなります。一定期間、センチネルモードを検討すると、ホストにバックグラウンドで障害が発生しているかどうかを監視でき、障害が発生した場合は、投票数に応じてライブラリからメインライブラリに自動的に切り替わります。
実際の生産で一般的に使用されるマルチセンチネルモード
メインサーバーがダウンしていると仮定すると、Sentinel 1は最初にこの結果を検出し、システムはフェイルオーバープロセスをすぐには実行しません。Sentinel1がメインサーバーが利用できないと主観的に信じているだけです。この現象は主観的オフラインと呼ばれます。次の歩哨もメインサーバーが利用できないことを検出し、その数が特定の値に達すると、歩哨間で投票が行われ、投票の結果が歩哨によって開始されてフェイルオーバー操作が実行されます。切り替えが成功すると、各センチネルは、パブリッシュおよびサブスクライブモードを介してサーバーからホストに切り替わります。これは、目的オフラインと呼ばれます。
センチネルプロファイル
vim sentinel.conf
sentinel monitor myredis 127.0.0.1 6380 1
myredisは監視対象の名前で、カスタマイズできます。
番号1は、ホストがダウンしていることを意味します。歩哨は、メインサーバーがダウンしていると見なし、フェイルオーバーします。スレーブは新しいホストに投票します。
ホストが戻ってきた場合、新しいホストにのみマージできます。スレーブとして、
監視を開始します。
redis-sentinel sentinel.conf
ポート6380でサーバーをシャットダウンすると、しばらくするとメッセージが表示されます。
この時点で、残りの2つのスレーブの1つがマスターに切り替えられます。ここでは、ポート6382のサーバーがマスターになっています。
127.0.0.1:6382> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=15160,lag=0
master_replid:9b5d53c80a86c60b9018bae00d4666b62c0f9902
master_replid2:c6216c491387c038802f20d011432f64bcb12c72
master_repl_offset:15160
second_repl_offset:7314
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:15160
利点：
1。マスタースレーブレプリケーションモデルに基づくSentinelクラスターには、マスタースレーブ構成のすべての利点があります
。2。マスタースレーブを切り替えて、障害を転送できます。システムの可用性が向上します。
3.歩哨モードはマスタースレーブモードです。アップグレード、手動から自動、より堅牢
短所：
1。Redisはオンライン拡張
を実装するのが簡単ではありません。クラスターの数が上限に達すると、オンライン拡張は非常に面倒です。2。センチネルモードの構成を実現するのは実際には非常に面倒です。
Redisキャッシュの浸透と雪崩
キャッシュの浸透
ユーザーがデータの一部をクエリする必要があり、redisメモリデータベースが使用できないこと、つまりキャッシュがヒットしていないことがわかった場合は、永続層データベースにクエリを実行します。何も見つからなかったため、このクエリは失敗しました。多くのユーザーがいる場合、キャッシュはヒットせず、すべてのユーザーが永続層データベースを要求するため、データベースに大きなプレッシャーがかかります。現時点では、キャッシュの侵入に相当します。
解決
ブルームフィルター
ブルームフィルターは、可能なすべてのクエリパラメーターをハッシュの形式で格納するデータ構造です。最初にコントロールレイヤーで検証され、一致しない場合は破棄されるため、基盤となるストレージシステムへのクエリの負荷を回避できます。
空のオブジェクトをキャッシュ
するストレージレイヤーが欠落している場合、返された空のオブジェクトもキャッシュされ、同時に有効期限が設定されます。後でこのデータへのアクセスがキャッシュから取得され、バックエンドデータソースが保護されます。
ただし、この方法には2つの問題が
あります。1。null値をキャッシュできる場合、より多くのキーを格納するためにより多くのスペースが必要に
なります。2。null値に有効期限がすぐに設定された場合でも、キャッシュレイヤーとストレージレイヤー。データは一定期間一貫性がなく、ビジネスに影響を与える可能性があります。
キャッシュの内訳
非常に高温で、常に大きな同時実行性を保持し、大きな同時実行性がこのポイントへのアクセスに集中するキーを指します。キーが失敗すると、継続的な大きな同時実行性がキャッシュを破壊し、バリアAホールの場合と同様にデータベースを直接要求します。掘削された。
キーの有効期限が切れた場合は、同時アクセス要求の数が多い。このタイプのデータは、一般的にホットデータである。キャッシュの有効期限が切れたので、データベースが最新のデータを照会するために同時にアクセスされ、キャッシュ書き戻され、データベースが発生します瞬間的な圧力が大きすぎます
解決
ホットスポットデータを
無期限に設定します。キャッシュの観点から、有効期限が設定されていなくても、ホットスポットキーの有効期限による問題は発生しません。
ミューテックスロックの追加
分散ロック：分散ロックを使用して、1つのスレッドのみが各キーのバックエンドサービスに同時にクエリを実行できるようにし、他のスレッドは分散ロックを取得する権限がない場合に待機します。このようにして、高い同時実行性のプレッシャーが分散ロックに転送されます
キャッシュアバランシェ
一元化されたキャッシュの有効期限が切れたとき、
キャッシュサーバーがダウンしたとき、またはネットワークが切断されたときの特定の期間を指します。これにより、自然に雪崩が発生します。
ソリューション
Redisは高可用性です
。つまり、クラスターを構築するためにRedisをさらにいくつか追加します。
現在の制限の低下
キャッシュに障害が発生した後、データベース内のキャッシュに書き込むスレッドの数は、ロックまたはキューによって制御されます。たとえば、1つのスレッドのみがデータのクエリと特定のキーのキャッシュへの書き込みを許可され、他のスレッドは待機します
データのウォームアップ
正式な展開の前に、可能なデータが事前にアクセスされるため、大量にアクセスされる可能性のあるデータの一部がキャッシュにロードされます。大規模な同時アクセスが発生する前に、キャッシュ内のさまざまなキーのロードを手動でトリガーし、さまざまな有効期限を設定して、キャッシュの無効化の時点を可能な限り均一にします。
参照
https://www.bilibili.com/video/BV1S54y1R7SB