Redis のマスター/スレーブ同期の詳細な説明-PHPチュートリアル-php.cn

マスターとスレーブの同期の文字通りの意味は、誰がマスターで誰がスレーブであり、それらが同期されて同期効果を形成することです。では、Redis のマスター/スレーブ同期についてどれくらい知っていますか?この記事ではRedisのマスター・スレーブ同期解析を中心に紹介しますので、参考になれば幸いです。

1. Redis マスターとスレーブの同期原理

1.1 Redis マスターとスレーブの同期プロセス

スレーブサーバーに接続するマスターを設定した後、スレーブはマスターとの接続を確立し、同期コマンドを送信します。同期によって初めて確立された接続であっても、接続が切断された後の再接続であっても、マスターはバックグラウンドプロセスを開始してデータベーススナップショットをファイルに保存します。同時に、マスターのメインプロセスが収集を開始します。新しい書き込みコマンドを実行し、それらをキャッシュします。バックグラウンドプロセスがファイルの書き込みを完了すると、マスターはスナップショットファイルをスレーブに送信し、スレーブはファイルをディスクに保存し、それをメモリにロードしてデータベーススナップショットをスレーブに復元します。スレーブがスナップショットファイルの回復を完了すると、マスターはキャッシュされたすべてのコマンドをスレーブに転送し、スレーブはメモリデータベースを更新します。マスターが受信した後続の書き込みコマンドは、最初に確立された接続を通じてスレーブに送信されます。マスターからスレーブにデータを同期するコマンドと、クライアントからマスターに送信されるコマンドは、同じプロトコル形式を使用します。マスターとスレーブ間の接続が切断された場合、スレーブは自動的に接続を再確立できます。マスターが複数のスレーブから同時に同期接続コマンドを受信した場合、データベースミラーを書き込むプロセスのみを開始し、それをすべてのスレーブに送信します。

1.2 Redis マスター/スレーブ同期の特徴

マスター/スレーブ同期には、主に次の側面を含む明らかな分散キャッシュ特性があります:

1) マスターは複数のスレーブを持つことができ、スレーブも複数のスレーブを持つことができます;
2) スレーブはマスターに接続できるだけでなく、スレーブは他のスレーブに接続してツリー構造を形成することもできます。
3) マスターとスレーブの同期はマスターをブロックしませんが、スレーブはブロックします。つまり、1 つ以上のスレーブが初めてマスターとデータを同期するとき、マスターはクライアントからのリクエストを処理し続けることができます。逆に、スレーブが初めてデータを同期するとブロックされ、クライアントのリクエストを処理できなくなります。
4) マスターとスレーブの同期を使用して、システムのスケーラビリティを向上させることができます。クライアントの読み取りリクエストを実行するために使用することもできます。単純なデータ冗長性またはスレーブ上でのみの永続化により、クラスターの全体的なパフォーマンスが向上します。

1.3 Redisアクティブ同期設定方法

マスタースレーブRedisサーバーの同期設定を完了するには2つの方法があります。すべてはスレーブサーバー上で行う必要があり、スレーブが接続する必要がある Redis サーバー (マスターまたはスレーブの場合があります) を指定します。

1.3.1 設定ファイルに設定する

スレーブとなるRedisサーバーの設定ファイル(redis.conf)に設定します。

設定コード

slaveof 10.1.1.102 6379 #指定master的ip和端口

ログイン後にコピー

明らかに、この設定方法は非常に簡単ですが、設定ファイルの変更が必要であり、設定ファイルはサーバーの起動時にロードされます。したがって、サーバーを起動せずに変更することはできず、操作は柔軟性に欠けます。

この設定方法は、展開時の初期設定として適しています。

1.3.2 Redis クライアントでの設定

ここでは、Redis が公式に推奨している Jedis を例として取り上げます。以下の記事のテストも Jedis に基づいています。ここでの jedis オブジェクトインスタンスはスレーブに属し、パラメータはサーバーのアドレスとポートです。

Java コード

slaveJdedis.slaveOf("10.1.1.102", 6379); #指定master的ip和端口 
slaveJdedis.slaveofNoOne(); #取消指定master，自己成为一个master了

ログイン後にコピー

マスターサーバーとスレーブサーバー間のマスター/スレーブ関係は、クライアントが指定した方法で簡単に変更できます。したがって、この方法は、必要に応じてマスターサーバーとスレーブサーバーをオンラインで調整するのに非常に適しています。

1.3.3 現在のマスター/スレーブ同期の問題

マスターサーバーとスレーブサーバーはRedisによって自動的に選択されず、手動での参加が必要なため、マスター/スレーブの切り替えを自動的に完了することはできません。このため、いつ、誰が切り替えをトリガーすべきかという問題が生じます。クライアントにこの機能がないことを確認しました。必要な場合は、自分で追加する必要があります。

Jedis は現在、読み取り元の Redis サーバーをランダムに選択するため、自動分散読み取りを実現するには、Jedis を再カプセル化する必要があります。

1) マスターとスレーブの動作状態をできるだけ早く検出するメカニズムを開発する必要があります。
2) マスターとスレーブの自動切り替え戦略を定義する必要があります。
3) ランダムに読み取ることができるメカニズム。 Redis サーバーのメカニズムを定義する必要があります。

これらの機能はクライアントに実装できますが、効果はあまり良くありません。サーバー自体がそれをサポートできれば完璧ですが、Redis 公式 Web サイトの紹介を見る限り、まだそのような要望は出ておらず、その予定もないようです。

2. Redis メインストリームクライアントの紹介

Redis の公式 Web サイトには、5 つの Redis 用 Java クライアントソフトウェアがリストされています。このうち、Jedis は Redis が公式に推奨する Java クライアントであり、メンテナンスと更新が行われています。現在、サーバーの最新の安定バージョンは Redis2.4.17 で、最新のテストバージョンは Redis 2.6.0 RC7 です。

2.1 Jedis

Jedis は、公式に推奨される Redis の Java クライアントバージョンです。現在の最新バージョンは Jedis 2.1.0-5 で、Redis バージョン 2.0.0 と完全な互換性があります。このクライアントは常に保守および更新されます。

2.2 JRedis

JRedis は長い間更新されておらず、Redis 2.0.0 バージョンと完全に互換性があります。本日5月以前にアップデート後、最新のRedis2.6.0テスト版に対応可能となりました。

2.3 JDBC-Redis

JDBC-Redis は、NoSQL データベース Redis 用の JDBC ドライバーです。ダウンロードできるのは、2009 年 3 月にリリースされた jdbc-redis_0.1_beta バージョンのみですが、現在はメンテナンスされていません。

2.4 RJC

RJC は、Apache DBCP スタイルの接続プーリングを提供します。更新は 1 年前に停止されており、Redis 2.0.0 バージョンと完全に互換性があります。

2.5 redis-protocol

このアップデートは最も速く、最も頻繁に行われ、最新の Redis 2.6.0 バージョンと互換性があります。ただし、Redis プロトコルを完全にサポートし、Redis サーバーとより効率的に対話できるように配置されています。そのため、redisサーバーの機能を十分に活用できません。

2.6 各Javaクライアントの総合評価

全体として、各クライアントは基本的にRedisプロトコルで定義された基本機能を実装しています。最近の Redis プロトコルの更新では、Redis プロトコルが最も完全にサポートされています。Jedis は、Redis サーバーに対してより多くの構成操作を提供し、最も使いやすくなっています。他のクライアントはほとんどメンテナンスされず、機能は平均的です。

クライアントの機能を少し拡張したい場合は、Jedis に基づいて開発するのが最も早い方法です。

互換性を最大限に高め、クライアント機能を拡張したい場合は、Redis プロトコルが最適な選択です。

3. Redis マスター/スレーブ同期の使用に関する提案

Redis マスター/スレーブ同期は、現在のすべての Java クライアントで十分にサポートされているわけではありません。主な理由は、Redis サーバー自体の実装メカニズムの制限によって引き起こされるはずです。やむを得ず行う場合には可能ですが、効果が損なわれる可能性があります。

3.1 Jdedis をカプセル化することで実装されます

1) Redis サーバークラスターのサーバートポロジ関係を維持する責任を負う管理クラスを追加します。
2) Redis サーバーでのサーバー操作の監視と維持を担う監視クラスを追加します。クラスターのステータス;
3) 新しいマスター選択戦略クラスを追加します。これは、マスターとスレーブ間の切り替えタイミングを決定し、マスターとして機能する最適な Redis サーバーを選択します。
4) 新しいプロキシクラスを追加して、Redis サーバー上の現在の Jedis クライアントの読み取りおよび書き込み操作を引き継ぎます。アプリケーション層は、プロキシクラスを通じて Jedis クライアントを使用します。プロキシクラスは、Redis サーバークラスターがアプリケーション層に対して透過的であることを保証する必要があります。