redis,rabbitmq,graphite,zabbix,tengine,haproxy,keepalived,ansible,saltstack,要約
5030 ワード
一、redis
RDB永続化方式は、その時点のデータスナップショットを特定の間隔で保存する
データ損失を防ぐためには、Redisのデータをメモリからディスクにdumpする必要があります.これが永続化です.Redisは、RDBとAOFの2つの永続化方式を提供する.Redisは両者の結合を可能にし,両者の同時閉鎖も可能にした.
RDBは、メモリ内のデータセットを定期的にバックアップすることができる.サーバが起動すると、RDBファイルからデータセットを復元できます.
AOF(append only file)は、サーバのすべての書き込み操作を記録することができる.サーバが再起動されると、すべての書き込み操作が再実行され、データバックアップが実現されます.書き込み操作セットが大きすぎる(既存のデータセットよりも大きい)場合、Redisは書き込み操作セットを書き換える
rdbの利点 RDBの性能はとても良くて、持久化を行う必要がある時、メインプロセスはforkの1つのサブプロセスが出てきて、それから持久化の仕事をサブプロセスに渡して、自分で関連するI/O操作がありません. AOFよりもデータ量が比較的大きい場合、RDBの起動速度は よりも速い.
欠点
RDBはデータの損失を引き起こしやすい.5分ごとにスナップショットを保存すると、Redisが何らかの理由で正常に動作しない場合、最後にスナップショットが生成されてからRedisに問題が発生するまでの間、データが失われます.
スナップショットは信頼性が低い.もしあなたのパソコンが突然ダウンタイムになったり、電源が切れたり、うっかりプロセスを殺したりすると、最新のデータが失われます.AOFファイルは、より信頼性の高い永続化方式を提供しています.Redisがデータセットを修正するコマンドを受け取るたびにAOFファイルにコマンドを追加し、Redisを再起動するとAOFのコマンドが再実行され、データが再構築されます.
メリット AOFログファイルは、純粋に追加されたファイルです.突然停電した場合でも、ログの位置付けや破損の問題は発生しません.ディスクがいっぱいになったなど、何らかの理由でコマンドがログファイルに半分しか書かれていない場合でも、
欠点
いくつかのfsyncポリシーでは、AOFの速度はRDBよりも遅くなる.通常fsyncは毎秒1回に設定すると比較的高いパフォーマンスが得られます
二、rabbitmq
RabbitMQは主にシステム間の双方向デカップリングを実現するために実現される.生産者が大量にデータを生成すると、消費者は急速に消費できず、中間層が必要になる.このデータを保存
Vhost分析
RabbitMQのVhostは主に異なるビジネスモジュールを区分するために使用される.異なるビジネスモジュール間では情報のインタラクションはありません.
Vhost間は完全に隔離されており、異なるVhost間ではExchangeとQueueを共有できません.したがって、Vhost間のデータは共有および共有できません.このような機能を実現するには,Vhost間で対応するコードロジックを手動で構築する必要がある.
vhostsは主にユーザー、
メッセージキュー(MQ)使用手順
いくつかの概念の説明:
1.Broker:簡単に言えば、メッセージキューサーバエンティティです.
2.Exchange:メッセージがどのルールでどのキューにルーティングされるかを指定するメッセージスイッチ.
3.Queue:メッセージキューキャリアであり、各メッセージは1つ以上のキューに投入される.
4.Binding:exchangeとqueueをルーティングルールに従ってバインドする役割を果たします.
5.Routing Key:ルーティングキー、exchangeはこのキーに基づいてメッセージ配信を行う.
6.vhost:仮想ホストで、1つのbrokerに複数のvhostを開設し、異なるユーザーの権限分離として使用することができます.
7.producer:メッセージ生産者は、メッセージを配達するプログラムです.
8.consumer:メッセージ消費者は、メッセージを受信するプログラムです.
9.channel:クライアントの各接続において、複数のchannelを確立することができ、各channelはセッションタスクを表す.
メッセージ・キューの使用手順は、次のようになります.
1.クライアントはメッセージキューサーバに接続し、channelを開きます.
2.クライアントはexchangeを宣言し、関連するプロパティを設定します.
3.クライアントはqueueを宣言し、関連するプロパティを設定します.
4.クライアントはrouting keyを使用して、exchangeとqueueの間にバインド関係を確立します.
5.クライアントはexchangeにメッセージを送信します.
6.exchangeはメッセージを受信すると、メッセージのkeyと設定されたbindingに基づいてメッセージルーティングを行い、1つ以上のキューにメッセージを配信する.
a)Directタイプの場合、メッセージ内のRoutingKeyは、そのExchangeに関連付けられたすべてのBindingのBindingKeyと比較され、等しい場合はそのBindingに対応するQueueに送信される.
b)Fanoutタイプの場合、Exchangeで定義されているBindingのすべてのQueuesにメッセージが送信されますが、実はブロードキャスト動作です.
c)Topicタイプの場合は正規表現に従ってRoutingKeyとBindingKeyがマッチングされ、マッチングに成功した場合は対応するQueueに送信されます.(記号"#"は1つ以上の語に一致し、記号"*"はちょうど1つの語に一致する)
詳細:
ExchangeはQueueがたくさんあるかもしれませんが、メッセージは具体的にどのQに分かれていますか?具体的にはexchangeのタイプを見てみましょう.
具体的なexchangeにはいくつかのタイプがあります.
1、keyに完全に基づいて配信されるのがDirectスイッチであり、例えば、バインド時にroutingkeyを「abc」と設定すると、クライアントが送信するメッセージは、keyを「abc」と設定したもののみキューに配信される.
2、keyをパターンマッチングして配達するのをTopicスイッチといい、記号「#」は1つ以上の語をマッチングし、記号「*」はちょうど1つの語をマッチングする.例えば「abc.#」マッチングabc.def.ghi”,”abc.*”一致のみabc.def”.
3、keyを必要としないFanoutスイッチというものもあります.ブロードキャストモードを採用し、メッセージが入ってくると、スイッチにバインドされたすべてのキューに送信されます.
HA
ミラーモード:必要なキューをミラーキューにして、複数のノードに存在し、rabbitMQのHA方案に属する.このモードは、consumerがデータを取得する際に一時的にプルアップするのではなく、メッセージエンティティがミラーノード間で同期するという実質的に一般的なモードとは異なる問題を解決する.
クラスタには2つのノードがあります.
メモリノード:ステータスのみをメモリに保存します(例外として、永続的なqueueの永続的なコンテンツがdiskに保存されます).
≪ディスク・ノード|Disk Node|emdw≫:ステータスをメモリとディスクに保存します.メモリノードはディスクに書き込まれませんが、ディスクノードよりも実行されます.クラスタでは、ステータスを保存するためにディスクノードが1つしか必要ありません.クラスタにメモリノードが1つしかない場合は、それらを停止することはできません.そうしないと、すべてのステータス、メッセージなどが失われます.
三、graphite
四、zabbix
五、tengine
六、haproxy
七、keepalived
八、ansible
九、saltstack
十、tomcat
VMメモリモデル
1.1 Javaスタック
Javaスタックは各スレッドに関連付けられており、JVMは各スレッドを作成する際に、スレッドに一定のスタックスペースを割り当てます.主に、スレッド実行中のローカル変数、メソッドの戻り値、およびメソッド呼び出しコンテキストを格納するために使用されます.スタック空間はスレッドの終了に伴って解放される.StackOverflowError:スレッド実行中にスタックスペースが足りない場合、JVMはこの異常を放出します.このような状況は一般的に死再帰によるものです.
1.2山
Javaのヒープはすべてのスレッドによって共有されるメモリ領域であり、ヒープは配列、スレッドオブジェクトなど、さまざまなJAVAオブジェクトを保存するために使用されます.
heap
これはJVMがオブジェクトインスタンスおよび配列値を格納するための領域であり、Javaでnewによって作成されたすべてのオブジェクトのメモリがここに割り当てられていると考えられ、HeapのオブジェクトのメモリはGCの回収を待つ必要がある
JVMゴミ回収
GC(Garbage Collection)の基本原理:メモリで使用されなくなったオブジェクトを回収し、GCで回収する方法をコレクターと呼びます.GCはリソースと時間を消費する必要があるため、Javaはオブジェクトのライフサイクルの特徴を分析した後、新生代、旧生代の方法でオブジェクトを収集し、GCによるアプリケーションの一時停止をできるだけ短縮します.
(1)新生代の対象の収集をminor GCと呼ぶ.
(2)旧生代の対象の収集をFull GCと呼ぶ.
(3)プログラムでアクティブにSystemを呼び出す.gc()が強制的に実行するGCはFull GCである.
GCにはいくつかの資源と時間を消費する必要があるため、Javaはオブジェクトのライフサイクルの特徴を分析した後、
新生代ヤングジェネレーション Eden Space新しいランタイムデータ領域へのインスタンスは、この に格納されます. S 0 Suvivor Spaceは存在時間が長く、ゴミ回収によって除去されなかった例があり、EdenからS 0 に移る. S 1 Survivor Spaceと同様に、より長い時間の例が存在し、S 0からS 1 に移行した.
旧世代Old Generation/tenuredと同様に,より長い時間のインスタンスが存在し,オブジェクトの複数回の回収がクリアされず,S 1からtenureに移行した.
十一、梱包
十二、kvm
RDB永続化方式は、その時点のデータスナップショットを特定の間隔で保存する
データ損失を防ぐためには、Redisのデータをメモリからディスクにdumpする必要があります.これが永続化です.Redisは、RDBとAOFの2つの永続化方式を提供する.Redisは両者の結合を可能にし,両者の同時閉鎖も可能にした.
RDBは、メモリ内のデータセットを定期的にバックアップすることができる.サーバが起動すると、RDBファイルからデータセットを復元できます.
AOF(append only file)は、サーバのすべての書き込み操作を記録することができる.サーバが再起動されると、すべての書き込み操作が再実行され、データバックアップが実現されます.書き込み操作セットが大きすぎる(既存のデータセットよりも大きい)場合、Redisは書き込み操作セットを書き換える
rdbの利点
欠点
RDBはデータの損失を引き起こしやすい.5分ごとにスナップショットを保存すると、Redisが何らかの理由で正常に動作しない場合、最後にスナップショットが生成されてからRedisに問題が発生するまでの間、データが失われます.
スナップショットは信頼性が低い.もしあなたのパソコンが突然ダウンタイムになったり、電源が切れたり、うっかりプロセスを殺したりすると、最新のデータが失われます.AOFファイルは、より信頼性の高い永続化方式を提供しています.Redisがデータセットを修正するコマンドを受け取るたびにAOFファイルにコマンドを追加し、Redisを再起動するとAOFのコマンドが再実行され、データが再構築されます.
メリット
redis-check-aofというツールで簡単に修復できます.欠点
いくつかのfsyncポリシーでは、AOFの速度はRDBよりも遅くなる.通常fsyncは毎秒1回に設定すると比較的高いパフォーマンスが得られます
二、rabbitmq
RabbitMQは主にシステム間の双方向デカップリングを実現するために実現される.生産者が大量にデータを生成すると、消費者は急速に消費できず、中間層が必要になる.このデータを保存
Vhost分析
RabbitMQのVhostは主に異なるビジネスモジュールを区分するために使用される.異なるビジネスモジュール間では情報のインタラクションはありません.
Vhost間は完全に隔離されており、異なるVhost間ではExchangeとQueueを共有できません.したがって、Vhost間のデータは共有および共有できません.このような機能を実現するには,Vhost間で対応するコードロジックを手動で構築する必要がある.
vhostsは主にユーザー、
メッセージキュー(MQ)使用手順
いくつかの概念の説明:
1.Broker:簡単に言えば、メッセージキューサーバエンティティです.
2.Exchange:メッセージがどのルールでどのキューにルーティングされるかを指定するメッセージスイッチ.
3.Queue:メッセージキューキャリアであり、各メッセージは1つ以上のキューに投入される.
4.Binding:exchangeとqueueをルーティングルールに従ってバインドする役割を果たします.
5.Routing Key:ルーティングキー、exchangeはこのキーに基づいてメッセージ配信を行う.
6.vhost:仮想ホストで、1つのbrokerに複数のvhostを開設し、異なるユーザーの権限分離として使用することができます.
7.producer:メッセージ生産者は、メッセージを配達するプログラムです.
8.consumer:メッセージ消費者は、メッセージを受信するプログラムです.
9.channel:クライアントの各接続において、複数のchannelを確立することができ、各channelはセッションタスクを表す.
メッセージ・キューの使用手順は、次のようになります.
1.クライアントはメッセージキューサーバに接続し、channelを開きます.
2.クライアントはexchangeを宣言し、関連するプロパティを設定します.
3.クライアントはqueueを宣言し、関連するプロパティを設定します.
4.クライアントはrouting keyを使用して、exchangeとqueueの間にバインド関係を確立します.
5.クライアントはexchangeにメッセージを送信します.
6.exchangeはメッセージを受信すると、メッセージのkeyと設定されたbindingに基づいてメッセージルーティングを行い、1つ以上のキューにメッセージを配信する.
a)Directタイプの場合、メッセージ内のRoutingKeyは、そのExchangeに関連付けられたすべてのBindingのBindingKeyと比較され、等しい場合はそのBindingに対応するQueueに送信される.
b)Fanoutタイプの場合、Exchangeで定義されているBindingのすべてのQueuesにメッセージが送信されますが、実はブロードキャスト動作です.
c)Topicタイプの場合は正規表現に従ってRoutingKeyとBindingKeyがマッチングされ、マッチングに成功した場合は対応するQueueに送信されます.(記号"#"は1つ以上の語に一致し、記号"*"はちょうど1つの語に一致する)
詳細:
ExchangeはQueueがたくさんあるかもしれませんが、メッセージは具体的にどのQに分かれていますか?具体的にはexchangeのタイプを見てみましょう.
具体的なexchangeにはいくつかのタイプがあります.
1、keyに完全に基づいて配信されるのがDirectスイッチであり、例えば、バインド時にroutingkeyを「abc」と設定すると、クライアントが送信するメッセージは、keyを「abc」と設定したもののみキューに配信される.
2、keyをパターンマッチングして配達するのをTopicスイッチといい、記号「#」は1つ以上の語をマッチングし、記号「*」はちょうど1つの語をマッチングする.例えば「abc.#」マッチングabc.def.ghi”,”abc.*”一致のみabc.def”.
3、keyを必要としないFanoutスイッチというものもあります.ブロードキャストモードを採用し、メッセージが入ってくると、スイッチにバインドされたすべてのキューに送信されます.
HA
ミラーモード:必要なキューをミラーキューにして、複数のノードに存在し、rabbitMQのHA方案に属する.このモードは、consumerがデータを取得する際に一時的にプルアップするのではなく、メッセージエンティティがミラーノード間で同期するという実質的に一般的なモードとは異なる問題を解決する.
クラスタには2つのノードがあります.
メモリノード:ステータスのみをメモリに保存します(例外として、永続的なqueueの永続的なコンテンツがdiskに保存されます).
≪ディスク・ノード|Disk Node|emdw≫:ステータスをメモリとディスクに保存します.メモリノードはディスクに書き込まれませんが、ディスクノードよりも実行されます.クラスタでは、ステータスを保存するためにディスクノードが1つしか必要ありません.クラスタにメモリノードが1つしかない場合は、それらを停止することはできません.そうしないと、すべてのステータス、メッセージなどが失われます.
三、graphite
四、zabbix
五、tengine
六、haproxy
七、keepalived
八、ansible
九、saltstack
十、tomcat
VMメモリモデル
1.1 Javaスタック
Javaスタックは各スレッドに関連付けられており、JVMは各スレッドを作成する際に、スレッドに一定のスタックスペースを割り当てます.主に、スレッド実行中のローカル変数、メソッドの戻り値、およびメソッド呼び出しコンテキストを格納するために使用されます.スタック空間はスレッドの終了に伴って解放される.StackOverflowError:スレッド実行中にスタックスペースが足りない場合、JVMはこの異常を放出します.このような状況は一般的に死再帰によるものです.
1.2山
Javaのヒープはすべてのスレッドによって共有されるメモリ領域であり、ヒープは配列、スレッドオブジェクトなど、さまざまなJAVAオブジェクトを保存するために使用されます.
heap
これはJVMがオブジェクトインスタンスおよび配列値を格納するための領域であり、Javaでnewによって作成されたすべてのオブジェクトのメモリがここに割り当てられていると考えられ、HeapのオブジェクトのメモリはGCの回収を待つ必要がある
JVMゴミ回収
GC(Garbage Collection)の基本原理:メモリで使用されなくなったオブジェクトを回収し、GCで回収する方法をコレクターと呼びます.GCはリソースと時間を消費する必要があるため、Javaはオブジェクトのライフサイクルの特徴を分析した後、新生代、旧生代の方法でオブジェクトを収集し、GCによるアプリケーションの一時停止をできるだけ短縮します.
(1)新生代の対象の収集をminor GCと呼ぶ.
(2)旧生代の対象の収集をFull GCと呼ぶ.
(3)プログラムでアクティブにSystemを呼び出す.gc()が強制的に実行するGCはFull GCである.
GCにはいくつかの資源と時間を消費する必要があるため、Javaはオブジェクトのライフサイクルの特徴を分析した後、
の方式でオブジェクトの収集を行い、すなわち新生代、旧生代の方式でオブジェクトを収集し、GCによるアプリケーションの一時停止をできるだけ短縮する.新生代ヤングジェネレーション
旧世代Old Generation/tenuredと同様に,より長い時間のインスタンスが存在し,オブジェクトの複数回の回収がクリアされず,S 1からtenureに移行した.
十一、梱包
十二、kvm