【Spring Cloud System】 - 軽量高可用性ツール Keepalive の詳細説明

【Spring Cloud System】 - 軽量高可用性ツール Keepalive の詳細説明


ここに画像の説明を挿入します

I. 概要

Keepalive は、Linux 向けの次の軽量高可用性ソリューションです。高可用性 (略して HA) は、ホストの冗長性と引き継ぎです。

基本機能: ハートビートの検出、リソースの引き継ぎ、クラスター内のサービスの検出、クラスター ノード間での IP アドレス所有者の共有。

Keepalive は主に経路の冗長化による高可用性機能を実装しており、構成は 1 つの構成ファイルだけで完了するシンプルなものです。

Keepalive はもともと LVS (Liunx Virtual Server 仮想サーバー クラスター ロード バランシング システム) 用に設計されました。クラスター システム内の各サービス ノードのステータスを監視するために特別に使用されます。TCP/TCP の 3 層、4 層、および 5 層に基づいています。 IP参照モデル. レイヤスイッチ機構により各サービスノードの状態を検出. サーバーノードに異常や作業障害が発生した場合, Keepalivedがそれを検出し, 障害が発生したサーバーノードをクラスタシステムから削除します. これらの作業はすべて自動的に完了します.手動による介入は必要なく、手動で行う必要があるのは、障害が発生したサービス ノードを修復することだけです。

2. キープアライブの分類

KeepAlive は、TCP の KeepAlive と HTTP の Keep-Alive に分かれており、両者はまったく異なる概念であるため、混同することはできません。

2.1 TCP キープアライブ

  • クライアントとサーバー間の接続を維持することに重点が置かれており、一方の当事者が他方の当事者にハートビート パケットを時々送信します。一方の当事者が電話を切ると、電話を切っていない方はハートビート パケットを定期的に数回送信します。間隔をあけて何度か送信すると相手がACKではなくRSTを返してくるので、現在のコネクションは解放されます。
  • TCP のキープアライブは、クライアントとサーバーの両方がオンラインであるかどうかを確認し、一方がオンラインでない場合に接続を解放します。これにより接続が解放されなくなり、サーバー リソースが無駄に消費されます。

2.2 HTTPのキープアライブ

通常の http 接続では、クライアントはサーバーに接続し、リクエストが完了すると、クライアントまたはサーバーが http 接続を閉じます。次回リクエストが送信されると、クライアントは接続を開始し、データを送信し、接続を閉じます。このプロセスは繰り返されますが、クライアントが connection:keep-alive ヘッダーをサーバーに送信し、サーバーがキープアライブを受け入れると、双方のパスワードが一致し、接続が再利用できるようになります。別の http データはこの接続から直接送信されます。

HTTP キープアライブの役割: TCP 接続の作成と切断の消費を削減します。

2.3 TCP のキープアライブと HTTP のキープアライブの違い

HTTP のキープアライブの目的は、接続を短期間に再利用することであり、同じ接続上で短時間に複数の要求/応答が行われることが期待されます。

TCP の KeepAlive メカニズムは、キープアライブ、ハートビート、および接続エラーの検出を目的としています。TCP 接続の両端で長期間 (通常、デフォルト設定は 2 時間) データ送信がない場合、リンクが生きているかどうかを検出するためにキープアライブ プローブが送信されます。

3. nginxキープアライブ設定

3.1 キープアライブを維持するには nginx は何をすべきですか?

  1. クライアントから nginx への接続は長い接続です
  2. nginx からサーバーへの接続は長い接続です

3.2 nginxファイル構成

  1. TCP 層キープアライブ検出メカニズムの 3 つのパラメーターを構成します。

    #情况1
    http {
          
          
    server {
          
          
        listen 127.0.0.1:3306 so_keepalive=on;#开启keepalive探活,探测策略走系统默认
        }
    }
    #情况2
    http {
          
          
        server {
          
          
            listen 127.0.0.1:3306 so_keepalive=7m:75s:9;#把空闲时长从系统默认的5分钟改为了7分钟
        }
    }
    
    

    このうち、so_keepalive は以下の選択構成となっています。

    so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]
    *   on: 开启,探测参数更加系统默认值
    *   off: 关闭
    *   keepidle: 连接空闲等待时间 
    *   keepintvl: 发送探测报文间隔时间
    *   keepcent: 探测报文重试次数
    
    

    nginx が so_keepalive 構成を設定しない場合は、システムのデフォルトの検出ポリシーが使用されます。

  2. nginx とクライアント (通常はブラウザー、APP など) の間で維持される長時間の接続の管理を制限します。

    http {
          
          
        keepalive_timeout  120s 120s;
        keepalive_requests 100;
    }
    
    keepalive_timeout timeout [header_timeout];
    

    最初のパラメータ: サーバーがアイドル状態のときのクライアント接続のタイムアウト値 (デフォルトは 75 秒)。値 0 はキープアライブを無効にし、デフォルトでは長時間の接続が有効にならないことを意味します。2 番目のパラメータ: のヘッダー フィールド応答 「Keep-Alive: timeout=time」に「Keep-Alive: timeout=time」を設定し、長時間の接続を維持する時間をブラウザに伝えます。

    keepalive_requests number;
    

    keepalive_requests: デフォルトは 100 で、これは長い接続がリクエストを連続的に処理できる回数の制限です。この回数を超えると、長い接続は閉じられます。接続によって占有されているメモリを解放する必要がある場合は、リンクを閉じる必要があります。メモリが大きくない場合は、メモリを大きく開くことはお勧めできません。この構成。QPS が高いシナリオでは、このパラメータを増やす必要があります。

  3. nginx は上流サーバーとの接続を長時間維持します

    http {
        upstream  BACKEND {
            server 127.0.0.1:8000;
            server 127.0.0.1:8001;
            server 127.0.0.1:8002;
            keepalive 300; //空闲连接数   
            keepalive_timeout  120s;//与上游空闲时间
            keepalive_requests 100;//与上游请求处理最大次数
        }
        server{
            listen 8080;
            location /{
                proxy_pass http://BACKEND;
                proxy_http_version 1.1;
                proxu_set_header Connection "";
            }
        }
    }
    

    keepalive: nginx のワーカーのアイドル接続の最大数を制限します。ワーカーとアップストリーム サービスの間の長い接続の合計数は、ここでは制限されません。 keepalive_timeout : nginx とアップストリームの間の長い接続の最大アイドル時間、デフォルト値は次のとおりです
    。 60s;
    keepalive_requests: nginx とアップストリーム間の長い接続の最大数 インタラクティブなリクエストの数、デフォルト値は 100。

おすすめ

転載: blog.csdn.net/songjianlong/article/details/132818171