ホームページ  >  記事  >  データベース  >  Redis クラスターのアーキテクチャと比較を見てみましょう

Redis クラスターのアーキテクチャと比較を見てみましょう

coldplay.xixi
coldplay.xixi転載
2021-03-12 11:17:051982ブラウズ

Redis クラスターのアーキテクチャと比較を見てみましょう

1、Redis3.0 # ##########################・ #########アドバンテージ############ # ##a.

セントラル ノードなしb.

データは

スロット ## に従って保存されます# 複数の Redis インスタンス

c. スムーズな拡張

/ ノードの縮小d. 自動フェイルオーバー(ノード間のパス

ゴシッププロトコル交換ステータス情報,投票メカニズムが完了しましたスレーブ

to マスター 役割の改善)e. 運用および保守コストを削減し、システムの信頼性を向上させる スケーラビリティと高可用性 (推奨 (無料): redis)·

欠点

##a.

外部に大きく依存する Redis-Tribb. ##監視と管理の欠如

##c. ##依存関係が必要# スマート クライアント(接続メンテナンス

キャッシュ ルーティング テーブル、MultiOp およびパイプライン

サポート)

d. フェイルオーバー ノードの検出が遅すぎるため、 ほど良好ではありません。」 セントラル ノード ZooKeeper」タイムリー##e. ゴシップ メッセージ オーバーヘッド f. 統計に基づいてホット データとコールド データを区別できません

g. スレーブ "コールド スタンバイ''、読み取りプレッシャーを軽減できません2、

プロキシ Redis クラスター## # #### ##############################・ #########アドバンテージ#### ##スマート クライアント

a.

プロキシの使用と比較して、ネットワークの 1 層伝送消費量が多く効率が高い ;b. 随時調整します。

プロキシa.

のセットを提供します。 HTTP Restful インターフェイス。基盤となるストレージを分離します。クライアントに対して完全に透過的な、言語を超えた通話。

b. アップグレードとメンテナンスは比較的簡単です。 Redis クラスター をメンテナンスするには、 をスムーズにアップグレードするだけです。プロキシ#### ##。

c.

階層ストレージ、基礎となるストレージはホットおよびコールドの異種ストレージです。

d.

権限制御、プロキシ は、秘密キーを介してホワイトリストを制御し、一部の違法なリクエストをブロックできます すべて除外された。また、ユーザーが要求した非常に大きな を制御およびフィルターすることもできます。 #e.

セキュリティ、 Keys## などのいくつかの危険なコマンドをブロックできます。 #保存すべてフラッシュなど。 f.

容量制御、さまざまなユーザー容量アプリケーションに基づく容量制限。

g.

さまざまなユーザーの

キー とプレフィックスに基づいて、リソースを分離するためのリソースの論理分離。 h.

埋め込みポイントを監視し、さまざまなインターフェイスの埋め込みポイントとその他の情報を監視します。

·

欠点スマート クライアント

:

a.

クライアントの未熟さは、アプリケーションの安定性に影響を与え、開発の難易度を高めます。

b. MultiOp

および

Pipeline のサポートは限定的です。 c.

接続メンテナンス、

スマート クライアント ペアはクラスター内の各ノードに接続されます ソケット メンテナンス。 プロキシ

a.

プロキシ層にはもう 1 つの転送があり、パフォーマンスが向上しますが、損失が発生します。

b

.拡張

/スケールダウンする場合、運用と保守の要件が高く、スムーズなスケーリングを実現することが困難です3、

Technical Selectionredis

公式ドキュメントには次の文章が含まれています

: redis-cli クラスターのサポートは非​​常に基本的なものであるため、Redis クラスター ノードがクライアントを適切なノードにリダイレクトできるという事実を常に利用します。本格的なクライアントはそれよりも優れた機能を備え、マップをキャッシュできます。ハッシュ スロットとノード アドレスの間で、適切なノードへの適切な接続を直接使用します。マップは、フェールオーバー後やシステム管理者がノードの追加または削除によってクラスタ レイアウトを変更した後など、クラスタ構成で何かが変更された場合にのみ更新されます。

一般的な考え方は、現在の

redis クラスター

公式クライアントには単純な機能があり、redis## に依存しているということです。 # ノード データが見つかったクラスター内の redis インスタンスにリダイレクトします。一貫性 ハッシュフェイルオーバー、およびクラスター管理機能を実現できる、より完全なクライアントが必要です。したがって、公式の redis クラスター クライアントを使用することは賢明な選択ではありません。この記事では、参考のために 3 ソリューションを提供します。どのような問題でも、理にかなっている場合は、誰でも私と話し合うことを歓迎します。

スキーム 1 使用nginx開発(OpenRestymethod)

理由は次のとおりです。:

a SingleMasterMultipleWork モード、各 Work が続きます Redis も単一プロセス シングルスレッド モードであり、Epoll イベント駆動型モードに基づいています。

b. Nginx は、リクエストを処理する非同期かつノンブロッキングな方法、つまり効率的な非同期フレームワークを採用しています。

c. 使用するメモリが少なく、独自のメモリ プール管理メソッドのセットを備えています。多数の小規模メモリ アプリケーションをまとめると、Malloc よりも高速になる可能性があります。メモリの断片化を軽減し、メモリ リークを防ぎます。メモリ管理の複雑さを軽減します。

d. Nginx のアクセス速度を向上させるため、Nginx 独自の接続プールのセットを使用します。

e. 最も重要なことは、カスタム モジュール開発をサポートすることです。

#f. #業界では、NginxRedis# # の評判は、2 つの偉大な成果物とみなすことができます。性能はとても良いです。

# スキーム

# 2 codis(Wandojia が採用したエージェントベースの redis##クラスタースキーム)##参考codis

公式ドキュメントhttps://github .com/CodisLabs/codisCodis は、高可用性、データシャーディング、モニタリング、動的拡張を含むキャッシュ ソリューションの完全なセットです

## #など####。

Apps->Agent

->rediscluster

を使用しています。間違いなくこれですメソッドは基本的にスケールの後に使用されます。 #計画3 独立開発

redis

スマート クライアント 主に redis スロット 管理、フェイルオーバー

、整合性 を実装します。ハッシュ関数。 4、Redis 3.0クラスター

Redis 3.0クラスターは、完全に分散化された P2P モデルを採用しています。 Redis はすべての Key16384# #slot# に分割します## では、各 Redis インスタンスが slot の一部を担当します。クラスター内のすべての情報 ##(#ノード、ポート、スロット#など)、すべてはノード間の定期的なデータ交換を通じて更新されます。 Redisクライアントは、任意の

Redis

インスタンスでリクエストを作成します。必要なデータがインスタンスにない場合は、 , リダイレクト コマンドを使用して、クライアントを目的のインスタンスに誘導します。 Redis 3.0クラスターのワークフローを次の図に示します。

#Redis

クラスター内のマシンは定期的にデータを交換します。ワークフローは次のとおりです:

##(

1

Redis

クライアントは Redis2# にあります ##インスタンス上の特定のデータにアクセスします; 2In

Redis2 は、このデータが Redis3 インスタンスにあることを検出し、Redis にリダイレクトを送信しました。 client Command; 3 Redis

クライアントがリダイレクト コマンドを受信した後、Redis3 インスタンスにアクセスして、必要なデータを取得します。 Redis 3.0 のクラスター ソリューションには次の 2 つの問題があります: 1)

1 つの ##Redis インスタンスには #"

データ ストレージ #"# があります# #“ルート リダイレクト、完全に分散化された設計。この利点は、デプロイが非常に簡単であることです。非常に多くのコンポーネントと依存関係がある Codis とは異なり、Redis を直接デプロイするだけです。しかし、問題は、ビジネスを簡単にアップグレードするのは難しいということです。ある日、Redisバグ に重大な問題が発生した場合、あなたはRedis クラスター全体をロールバックすることしかできません。 2) プロトコルは大幅に変更されており、対応する Redis クライアントもアップグレードする必要があります。 Redis クライアントをアップグレードした後に

Bug が存在しないことを誰が確認できるでしょうか?また、すでに大規模なオンライン運営を行っている企業にとって、コード内の Redis クライアントをアップグレードすることも非常に面倒な作業です。

5、Redis4.0

(1)所有的redis節點彼此互聯(PING-PONG##機制 ),內部使用二進位協定最佳化傳輸速度和頻寬;

(2)節點的Fail是透過叢集中超過半數的節點偵測失效時才生效;

(3)客戶端與redis節點直連,不需要中間proxy層。客戶端不需要連接叢集所有節點,連接叢集中任何一個可用節點即可;

(4)redis-cluster把所有的實體節點對應到[0-16383]slot(插槽)上,cluster #負責維護node<->slot<->value

以上がRedis クラスターのアーキテクチャと比較を見てみましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はcsdn.netで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。