Redisのクラスタのコンセプトを改善

仕上げシステムは改善する必要後、十分ではありません

1.飼育係のクラスタ

ノードの数が奇数、理由：投票メカニズム、高効率の選挙

2. solrcloud

1.コンセプト

solrcloudプログラムが提供された検索のSolrを分散さsolrCloudを使用した場合、大規模、フォールトトレラント、分散インデックス作成および検索機能を必要とします。大規模な検索ボリューム、検索要求を使用して高い同時実行。

Solrのベースの分散検索プログラム及び飼育係、主なアイデアは、飼育係クラスタ構成情報センターとして使用することです。

特徴：

一元化された構成情報
自動フォールトトレランス
リアルタイム検索の近く
自動負荷分散クエリ

3. Redisのクラスタ

1.コンセプト

なぜRedisのクラスタを構築します。Redisのデータがメモリに格納され、私たちのコンピュータのメモリは、一般に、HBaseのHadoopのエコシステムまたはMogoDBであるRedisの大きなデータを格納するための大規模なデータストレージに適していないことを意味し、大きくありません。Redisのは非常に並行処理に適している、一つのデバイスの記憶容量は非常に限られているが、複数のデバイスは、協力してクラスタの使用を必要とする、メモリ何倍を大きくさせることができます。

RedisのRedisのクラスタバージョン3.0クラスタをサポートした後、各ノードとクラスタ、各ノードと他のすべてのノードの全体の状態のデータを保存し、溶液のRedisクラウン、Redisのクラスタフリー中心構造です。以下に示されているRedisのクラスタアーキテクチャ。

ここに画像を挿入説明

Redisのクライアント・ノードは、中間層プロキシなしで、接続されている。クライアントは、任意の利用可能なクラスタノードが、クラスタ内のすべてのノードに接続されているに接続される必要はありません。

すべてのノードが相互接続され、Redisの（PING-PONG機構）は、バイナリプロトコルと帯域幅の最適化を使用して、内部伝送速度。

2.分散ストレージメカニズム - 溝

Redisのクラスタマッピング[0から16383]スロット、保守を担当するクラスタに物理ノードの全て

16384個のクラスタ各キーが対応するように構築されたRedisのハッシュキー値を最初演算結果を使用してクラスタのRedis、RedisのCRC16アルゴリズム鍵に配置するスロット、および16384の残りの数の結果、溝間号0から16383ハッシュ、Redisのノードの数に応じて異なるノードにマッピングされたハッシュスロットに実質的に等しくなります

例えば、3つのノード：次のように流通チャネルの値です。

SERVER1：0から5460

SERVER2：5461から10922

SERVER3：10923から16383

3.フォールトトレランス - 世論調査

選挙プロセスは、マスターノードの半分以上は、（クラスタノードタイムアウト）以上の障害と通信する場合、すべてのクラスタに関与するのマスターである、ノード障害が、自動フェイルオーバー操作をトリガと考えている。マスタノードからアップグレード自動的にノードに対応するノードの失敗

クラスタ全体が使用できない場合

フェイル状態に入るように[0から16383]そのスロットのクラスターのマッピングを理解することができるように、クラスタ・マスタが任意ハングした場合、および現在のマスタスレーブない。クラスタを入力し、状態失敗完了していません

ここに画像を挿入説明

他の概念

1.リバースプロキシ

リバースプロキシ、インターネット上での接続要求を受信するために、プロキシサーバ、その後、内部ネットワーク上のサーバに要求を転送し、インターネット上のクライアントのリクエストリンクにサーバから得られた結果を返す、この時間は、外部プロキシサーバのパフォーマンスリバースプロキシサーバ。

nginxのnginxのホスト設定ファイルを変更します

upstream pinyougou-portal {
  server 192.168.25.141:8080;
}
server {
  listen	80;
  server_name www.pinyougou.com;
  
  location / {
  	proxy_pass http://pinyougou-portal;
  	index	index.html;
   }
}

2.ロードバランシング

リバースプロキシの負荷分散によって行わnginxのWebプロジェクト

エンジニアリング・サービスの負荷分散を担当する飼育係

nginxの設定

upstream pinyougou-portal {
  server 192.168.25.141:8080;
  server 192.168.25.141:8081;
  server 192.168.25.141:8082;
}
server {
  listen	80;
  server_name www.pinyougou.com;
  
  location / {
  	proxy_pass http://pinyougou-portal;
  	index	index.html;
   }
}

3.高可用性

nginxの圧力の多くに、私たちは、ホスト・マシンとバックアップ・マシンが互いの健全性を監視するための高可用性の監視プログラムを実行している、バックアップ・マシンを作成する必要があります。

keepalivedのは、高可用性クラスタサービスソフトウェアを確保するために、単一障害点を防ぐために、クラスタ管理です。