1. 高い同時実行性メカニズム
Redis はシングル スレッドに基づいており、スタンドでホストできることがわかっています。 -alone モード 数万程度しかありませんが、Redis のマスター/スレーブ アーキテクチャと読み取りと書き込みの分離により、ビッグ データ下での数十万の高い同時リクエストをどのように改善するか。
ビデオ コースの推奨事項 →: 「数千万のデータに対する同時実行ソリューション (理論と実践)」
1. マスター/スレーブ レプリケーション
Redis のマスター/スレーブ レプリケーションの構成は強調されませんが、主にマスター/スレーブ レプリケーションの原理とプロセスに依存します。マスターホストは管理者として必要であり、複数のスレーブマシンを構築します。スレーブ スレーブが起動しようとすると、マスター ホストにコマンド PSYNC を送信しますが、このときスレーブ スレーブが再接続されると、スレーブ スレーブが持っていないデータがマスター ホストからコピーされます。初めて接続すると、完全な再同期がトリガーされます。トリガー後、マスターホストはバックグラウンドでプロセスを開始し、RDBスナップショットファイルを生成すると同時に、この期間の書き込み操作をキャッシュに保存し、RDBファイルが生成されると、RDBファイルを送信します。スレーブ マシンにファイルを送信すると、スレーブ マシンはファイルを取得します。その後、ファイルは最初にディスクに書き込まれ、次にメモリにロードされます。最後に、マスター ホストもメモリにキャッシュされたデータをスレーブ マシンに送信します。同じ時間です。マスター/スレーブ間のネットワーク障害が発生し、複数のスレーブが再接続した場合、マスターは 1 つの RDB のみを再起動してすべてのスレーブにサービスを提供します。 [関連する推奨事項: Redis ビデオ チュートリアル ]
ブレークポイントの再開: マスターとスレーブにレプリカ オフセットがあり、その中にマスター ID があり、オフセットはネットワーク障害後にスレーブが再接続すると、対応する最後のレプリカ オフセットを見つけてコピーします。対応するオフセットが見つからない場合は、完全な再同期がトリガーされます。
①レプリケーションの完全なプロセス
(1) スレーブ ノードが開始され、マスター ノードのホストと IP を含むマスター ノードの情報のみが保存されますが、レプリケーション プロセスは実行されません。 start
マスター ホストと IP はどこから来ますか? redis.conf の smileof 設定の
(2) スレーブ ノード内には、新しいホストがあるかどうかを確認するスケジュールされたタスクがあります。マスターノードに接続し、毎秒コピーします。それが見つかったら、マスターノードとのソケットネットワーク接続を確立します。
(3) スレーブノードはマスターノードに ping コマンドを送信します。
(4) パスワード認証。マスターが requirepass を設定すると、スレーブ ノードは認証のために masterauth パスワードを送信する必要があります。
(5) マスター ノードは初めて完全なレプリケーションを実行し、すべてのデータをスレーブ ノードに送信します。
(6) マスター ノードは、コマンドの書き込みを継続し、それらをスレーブ ノードに非同期でコピーします。
②データ同期関連するコア メカニズム
は、スレーブが初めて msater に接続するときに実行される完全なコピーを指します。そのプロセスの詳細なメカニズム
(1) マスターとスレーブの両方がオフセットを維持します。
マスターは自身のオフセットを継続的に蓄積し、スレーブも自身のオフセットを継続的に蓄積します
スレーブは自身のオフセットを毎秒マスターに報告し、マスターも各スレーブのオフセットを保存します
これは、完全なレプリケーションに特に使用されるという意味ではありません。主な理由は、両方のスレーブが同じであることです。マスターとスレーブは、相互間のデータの不一致を知るために、それぞれのデータのオフセットを知る必要があります。
(2) バックログ
マスター ノードにはバックログがあります。デフォルトのサイズは 1MB です。
マスター ノードがデータをスレーブ ノードにコピーすると、バックログにもデータのコピーが同期的に書き込まれます。
バックログは主に完全レプリケーションに使用されます。中断後の増分レプリケーション
(3) マスター実行 ID
info サーバー、マスター実行 ID
が表示されます。マスター ノードが再起動したり、データが変更された場合、ホスト IP に基づいてマスター ノードを見つけることは信頼できません。 , その後、スレーブ ノードは異なる実行 ID に従って区別される必要があります。実行 ID が異なる場合は、完全なコピーが作成されます。
実行 ID を変更せずに Redis を再起動する必要がある場合は、redis-cli デバッグを使用できますreload command
(4)psync
スレーブノードはpsyncを使用してマスターノードからコピーし、psync runid offset
マスターノードは自身の状況に応じて応答情報を返します。完全レプリケーションをトリガーするのは FULLRESYNC runid offset である可能性があります。または、CONTINUE が増分コピーをトリガーする可能性があります
③フル コピー
(1) マスターは bgsave を実行し、rdb スナップショット ファイルをローカルに生成します
(2) マスター ノードは rdb スナップショット ファイルをスレーブ ノードに送信します rdb コピー時間が 60 秒 (repl-timeout) を超える場合、ノードはコピーが失敗したと判断します。このパラメータは適切に調整できます。
(3) ギガビット ネットワーク カードを搭載したマシンの場合、通常 1 秒あたり 100MB、6G のファイルが転送され、60 秒を超える可能性があります
(4) マスター ノードが RDB を生成しているとき、すべての新しい書き込みコマンドはメモリにキャッシュされます。スレーブ ノードが RDB を保存した後、新しい書き込みコマンドはスレーブ ノードにコピーされます。
(5) client-output -buffer-limit スレーブ 256MB 64MB 60、コピー中にメモリ バッファが 64MB 以上を消費し続けるか、一度に 256MB を超える場合、コピーを停止し、コピーは失敗します。
(6) スレーブ ノードが rdb を受信した後、古いデータ バージョンに基づいて外部サービスを提供しながら、自身の古いデータをクリアし、メモリ内の rdb を自身に再ロードします。
(7) スレーブ ノードが AOF をオンにすると、BGREWRITEAOF が即座に実行され、 AOF は書き換えられます
rdb の生成、ネットワーク経由の rdb コピー、スレーブ古いデータのクリーニングとスレーブの aof の書き換えには非常に時間がかかります
コピーされたデータの量が 4G ~ 6G の場合の場合、フル コピー時間は 1 分半から 2 分かかる可能性があります。
④増分レプリケーション
(1) フル レプリケーション プロセス中にマスターとスレーブのネットワーク接続が切断された場合、スレーブがマスターに再接続すると、増分レプリケーションがトリガーされます
(2) マスターは、自身のバックログから失われたデータの一部を取得し、スレーブ ノードに送信します。デフォルトのバックログは 1MB
(3) msater は、スレーブによって送信された psync のオフセットに基づいてバックログからデータを取得します
⑤ハートビート
マスター ノードとスレーブ ノードは相互にハートビート情報を送信します
マスターはデフォルトで 10 秒ごとにハートビートを送信し、スレーブ ノードは 1 秒ごとにハートビートを送信します
##⑥非同期レプリケーション#マスターが書き込みコマンドを受信するたびに、データを書き込むようになりました内部的に送信し、スレーブ ノードに非同期で送信します。
2. 読み取りと書き込みの分離: マスターは書き込み操作を担当し、スレーブはマスターによるアクセス クエリの削減を支援する責任を負います。
##2. 高可用性メカニズム
高同時実行性の場合、複数のクラスターに 1 つのマスターと複数のバックアップが装備されます。は 1 つのホストのみです。マスターがダウンし、システム全体が書き込み操作を実行できず、スレーブがデータを同期できない場合、システム全体が麻痺し、システム全体が使用できなくなります。 Redis の高可用性メカニズムはセンチネル メカニズムです。センチネルは Redis クラスターの重要なコンポーネントであり、クラスターの監視、情報通知、フェイルオーバー、構成センターを担当します。
(1) クラスター監視。Redis マスタープロセスとスレーブプロセスが正常に動作しているかどうかを監視します。(2) メッセージ通知。Redis インスタンスに障害が発生した場合、センチネルはアラーム通知としてメッセージを送信します。管理者に送信
(3) フェイルオーバー、マスター ノードがハングアップした場合、自動的にスレーブ ノードに転送されます (4) 構成センター、フェイルオーバーが発生した場合、クライアントに新しいマスター アドレスを通知します
Sentinel それ自体が分散されており、クラスターとして機能するため、連携して動作する必要があります。
マスター ノードがダウンしていることが判明した場合、分散選挙を伴う監視員の過半数の同意が必要になります。
3. 高可用性と高同時実行性に起因するデータ損失の問題
(1) 非同期レプリケーションによって発生するデータ損失
理由は、マスター -> です。スレーブのレプリケーションは非同期であるため、一部のデータはマスターがクラッシュする前にスレーブにコピーされず、データのこれらの部分が失われる可能性があります。 (2) スプリット ブレインによるデータ損失スプリット ブレイン、つまりマスターが配置されているマシンが突然通常のネットワークから外れ、他のスレーブ マシンに接続できなくなりますが、実際、マスターはまだ実行中です。この時点で、センチネルはマスターがダウンしていると判断し、選挙を開始して他のスレーブをマスターに切り替える可能性があります。現時点では, クラスターには 2 つのスレーブが存在します。マスターがあり、いわゆるスプリット ブレインです。この時点でスレーブがマスターに切り替わりますが、クライアントには切り替える時間がない可能性があります。 したがって、古いマスターが再び復元されると、古いマスターは独自のスレーブとして新しいマスターにハングされます。データは消去され、新しいマスターから再度データがコピーされます。 非同期レプリケーションとスプリット ブレインによるデータ損失の解決策min-slaves-to-write 1 min-slaves-max-lag 10少なくとも 1 つのスレーブが必要です。データ レプリケーションと同期の遅延は 10 秒を超えることはできません1 回の場合スレーブ、データ レプリケーション、および同期の遅延が 10 秒を超えると、この時点でマスターはリクエストを受信しなくなります
上記 2 つの構成により、非同期レプリケーションとスプリット ブレインによるデータ損失を軽減できます
(1) 非同期レプリケーションによるデータ損失を軽減します
min-slaves-max-lag を使用する構成を変更すると、スレーブ コピー データと ACK 遅延が長すぎると、マスターがダウンした後に大量のデータが失われる可能性があると考えられ、書き込み要求が拒否されます。これにより、一部のデータが失われるのを防ぐことができます。スレーブによるデータ損失を制御可能な範囲で低減する
(2) スプリットブレインによるデータ損失を低減
マスタがスプリットブレインの場合この構成により、指定された数のスレーブにデータを送信し続けることができず、スレーブが 10 秒以上自分自身に ack メッセージを送信しない場合、クライアントの書き込みが確実に行われます。リクエストは直接拒否されます
このようにして、スプリット ブレイン後の古いマスターはクライアントからの新しいデータを受け入れなくなり、データ損失が回避されます。いずれかのスレーブとの接続が失われ、10 秒後にどのスレーブも自身に ACK を返さない場合、そのリクエストは拒否されます。新しい書き込みリクエスト
したがって、スプリット ブレイン シナリオでは、最大 10 秒間のデータが失われた
プログラミング関連の知識については、
以上がRedis の高可用性と高同時実行メカニズムの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

redis'sserver-sideoperations offferidions and forexuctingcomplexoperationsontheserver.1)機能を調整することで、javascript、orredis'sscriptinglanguage、infulancingscalabilityandmantenmention

redisisbothadatabaseandaserver.1)asadatabase、itusesin memorystorage forfastaccess、理想的なforreal-timeapplicationsandcaching.2)asaserver、itupportspub/submessagingandaging andluascriptingforreal-communicationandserver-sideoperation。

Redisは、高性能と柔軟性を提供するNOSQLデータベースです。 1)大規模データと高い並行性の処理に適したキー価値ペアを介してデータを保存します。 2)メモリストレージとシングルスレッドモデルは、速い読み取りと書き込みと原子性を確保します。 3)RDBおよびAOFメカニズムを使用してデータを持続し、高可用性とスケールアウトをサポートします。

Redisは、主にデータベース、キャッシュ、メッセージブローカーとして使用されるメモリデータ構造ストレージシステムです。そのコア機能には、シングルスレッドモデル、I/O多重化、持続メカニズム、複製、クラスタリング機能が含まれます。 Redisは、キャッシュ、セッションストレージ、メッセージキューのための実際のアプリケーションで一般的に使用されます。適切なデータ構造を選択し、パイプラインとトランザクションを使用し、監視とチューニングを使用することにより、パフォーマンスを大幅に改善できます。

RedisデータベースとSQLデータベースの主な違いは、Redisが高性能および柔軟性要件に適したインメモリデータベースであることです。 SQLデータベースは、複雑なクエリとデータの一貫性要件に適したリレーショナルデータベースです。具体的には、1)Redisは高速データアクセスとキャッシュサービスを提供し、キャッシュおよびリアルタイムのデータ処理に適した複数のデータ型をサポートします。 2)SQLデータベースは、テーブル構造を介してデータを管理し、複雑なクエリとトランザクション処理をサポートし、データの一貫性を必要とするeコマースや金融システムなどのシナリオに適しています。

redisactsassassadatastoreandaservice.1)asadatastore、itusesin memorystorage for fastorations、supporting variousdatastructureSlike-key-valuepairsandsortedsets.2)asaservice、iteasruascruascriptingrupting criptingforceptingpurplecomplecomplecprexoperations

他のデータベースと比較して、Redisには次の独自の利点があります。1)非常に速い速度、および読み取り操作は通常、マイクロ秒レベルにあります。 2)豊富なデータ構造と操作をサポートします。 3)キャッシュ、カウンター、公開サブスクリプションなどの柔軟な使用シナリオ。 Redisまたはその他のデータベースを選択する場合、特定のニーズとシナリオに依存します。 Redisは、高性能および低遅延のアプリケーションでうまく機能します。

Redisは、データストレージと管理において重要な役割を果たしており、複数のデータ構造と持続性メカニズムを通じて最新のアプリケーションの中核となっています。 1)Redisは、文字列、リスト、コレクション、注文されたコレクション、ハッシュテーブルなどのデータ構造をサポートし、キャッシュや複雑なビジネスロジックに適しています。 2)RDBとAOFの2つの持続方法を通じて、Redisは信頼できるストレージとデータの迅速な回復を保証します。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

SublimeText3 Linux 新バージョン
SublimeText3 Linux 最新バージョン

メモ帳++7.3.1
使いやすく無料のコードエディター

MantisBT
Mantis は、製品の欠陥追跡を支援するために設計された、導入が簡単な Web ベースの欠陥追跡ツールです。 PHP、MySQL、Web サーバーが必要です。デモおよびホスティング サービスをチェックしてください。

SublimeText3 中国語版
中国語版、とても使いやすい

ドリームウィーバー CS6
ビジュアル Web 開発ツール

ホットトピック









