分散セキリングシステムの構築から電流制限のトリックについて話しましょう

序文

諺にあるように、厚さ 3 フィートの氷は一夜にして形成されるものではなく、一滴の水は時間をかけて石を削り取るものであり、ローマは一日にして成らずです。 2週間前、フラッシュセール事件の初期形態が、中国人ユーザー向けのウェブサイト「Mayun」で共有された。同時に、友人たちからもたくさんの提案や苦情をいただきました。配布、クラスタリング、フラッシュセールが大企業の専売特許であるべきだとは決して思いません。今日のインターネット時代では、常に武装していなければなりません。そうすれば、明日あなたの春が来るかもしれません。

フラッシュセールシステムケースの開発過程では、主に共有キュー、キャッシュ、ロック、分散ロック、静的化などを採用しました。キャッシュの目的は、システムアクセス速度を向上させ、システム処理能力を強化することです。分散ロックは、クラスター内のデータのセキュリティと一貫性の問題を解決します。静的化により、キャッシュ層と DB 層への負荷が軽減されることは間違いありません。

[[233265]]

電流制限

しかし、マシンがどれだけ強力であっても、設計がどれだけ最適化されていても、特別なシナリオを特別に処理する必要があります。フラッシュセールを例に挙げてみましょう。買いに駆け込むユーザーは多いかもしれませんが、商品の数はユーザー数よりはるかに少ないです。これらすべてのリクエストがキューまたはクエリキャッシュに入ると、最終結果には意味がなく、バックグラウンドで大量のデータが増えるだけです。この点では、リソースの無駄を減らし、バックエンドの負荷を軽減するために、フラッシュセールの流れを制限し、一部のユーザーに対してのみ通常のサービスを保証する必要があります。

フラッシュセールインターフェースに関しては、アクセス頻度や同時リクエストが許容範囲を超えた場合、予期しないリクエストによるシステムへの過度の負荷によるシステム麻痺を防ぐために、インターフェースの可用性を確保するために電流制限を考慮する必要があります。通常の戦略は、冗長アクセスを拒否するか、冗長アクセスをサービス用にキューに入れることです。

電流制限アルゴリズム

いかなる電流制限も無意味なものではなく、スイッチで解決できる問題でもありません。一般的に使用される電流制限アルゴリズムには、トークンバケットとリーキーバケットがあります。

トークンバケット

トークンバケットアルゴリズムは、ネットワークトラフィックシェーピングとレート制限で最も一般的に使用されるアルゴリズムです。通常、トークンバケットアルゴリズムは、ネットワークに送信されるデータの量を制御し、バーストデータの送信を許可するために使用されます (Wikipedia)。

フラッシュセールでは、ユーザーのリクエスト率は固定されていません。ここでは 10r/s と仮定します。トークンは 1 秒あたり 5 個の速度でトークンバケットに入れられ、バケットには最大 20 個のトークンを保存できます。よく考えてみてください。破棄されるリクエストも必ず存在します。

漏れやすいバケツ

リーキーバケットアルゴリズムの主な目的は、ネットワークにデータが注入される速度を制御し、ネットワーク上のバーストトラフィックを平滑化することです。リーキーバケットアルゴリズムは、ネットワークに安定したフローを提供するためにバーストトラフィックを ××× できるメカニズムを提供します (百科事典)。

トークンバケットとは、流入速度がどれだけ速くても、事前に決められた速度で処理することを意味します。バケットがいっぱいの場合、サービスは拒否されます。

アプリケーション電流制限

トムキャット

Tomcat コンテナでは、スレッドプールをカスタマイズし、最大接続数、要求処理キュー、その他のパラメータを構成することで、電流制限の目的を達成できます (インターネットからの画像)。

Tomcat はデフォルトで独自の接続プールを使用します。ここで実装をカスタマイズすることもできます。 /conf/server.xml ファイルを開き、コネクタの前にスレッドプールを構成します。

 <エグゼキュータ名= "tomcatThreadPool"  
        名前プレフィックス = "tomcatThreadPool-"  
        最大スレッド数 = "1000"  
        最大アイドル時間 = "300000"  
        最小スペアスレッド数 = "200" />

name: 共有スレッドプールの名前。これは、コネクタがスレッドプールを共有するために参照する名前です。この名前は一意である必要があります。デフォルト値: なし;
namePrefix: JVM では、実行中の各スレッドに名前文字列を設定できます。このプロパティは、スレッドプール内の各スレッドの名前文字列のプレフィックスを設定し、Tomcat はこのプレフィックスの末尾にスレッド番号を追加します。デフォルト値: tomcat-exec-;
maxThreads: スレッドプールが収容できるスレッドの最大数。デフォルト値: 200
maxIdleTime: Tomcat がスレッドを閉じるまでアイドルスレッドが継続できる時間 (ミリ秒単位)。アイドルスレッドは、現在アクティブなスレッドの数が minSpareThread の値より大きい場合にのみ閉じられます。デフォルト値: 60000 (1 分)。
minSpareThreads: Tomcat が常に開いている必要がある非アクティブスレッドの最小数。デフォルト値: 25。

コネクタの設定

<コネクタ executor= "tomcatThreadPool"  
           ポート = "8080"プロトコル = "HTTP/1.1"  
           接続タイムアウト = "20000"  
           リダイレクトポート = "8443"  
           最小プロセッサ数 = "5"  
           最大プロセッサ数 = "75"  
           受け入れ回数 = "1000" />

executor: パラメータ値に対応するスレッドプールを示します。
minProcessors: サーバーがリクエストの処理を開始するときに作成されるスレッドの数。
maxProcessors: ***リクエストを処理するために作成できるスレッドの数。
acceptCount: リクエストの処理に使用可能なすべてのスレッドが使用された場合に、処理キューに配置できるリクエストの数を指定します。この数を超えるリクエストは処理されません。

API電流制限

フラッシュセール中は、インターフェースへのリクエスト数が通常の数百倍、あるいは数千倍にまで増加し、インターフェースが利用できなくなり、連鎖反応が引き起こされてシステム全体がクラッシュし、他のサービスにも影響が及ぶ可能性があります。

では、このような突然の出来事にどう対処すればよいのでしょうか?ここでは、オープンソースツールキット guava によって提供されるレート制限ツールクラス RateLimiter を使用して、API フローを制限します。このクラスは「トークンバケットアルゴリズム」に基づいており、すぐに使用できます。

 /**
 * カスタム注釈電流制限
 */
 @Target({ElementType.PARAMETER, ElementType.METHOD})
 @保持(保持ポリシー.RUNTIME)
 @文書化済み
パブリック@interface ServiceLimit {
     文字列の説明()デフォルト  "" ;
 }

カスタムの側面

/**
 * 電流制限AOP
 */
 @成分
@範囲
@側面
パブリッククラスLimitAspect {
    // 1 秒あたり 100 トークンのみが発行されます。これは、単一プロセス サービスの現在の制限です。トークンポーキングアルゴリズムは内部で使用されます。
    プライベート静的RateLimiter rateLimiter = RateLimiter.作成（100.0）; 
 
    //サービス層カットポイント電流制限
    @ポイントカット( "@annotation(com.itstyle.seckill.common.aop.ServiceLimit)" )
パブリックvoid ServiceAspect() { 
 
    } 
 
    @Around( "ServiceAspect()" )
パブリックオブジェクトaround(ProceedingJoinPoint joinPoint) {
        ブールフラグ = rateLimiter.tryAcquire();
        オブジェクト obj = null ;
        試す {
            if(フラグ){
                obj = joinPoint.proceed();
            }
        } キャッチ (Throwable e) {
            e.printStackTrace();
        }
 objを返します。
    }
 }

事業実施：

 @オーバーライド
@サービス制限
@トランザクション
パブリック結果startSeckill(longseckillId, longuserId) {
    //一部のビジネスコードは省略します。詳細については、2 番目の販売ソース コードを参照してください。
 }

分散電流制限

エンギンクス

#httpドメインで均一に設定する
#リクエストの制限
limit_req_zone $binary_remote_addr $uri ゾーン=api_read:20m レート=50r/s;
 #IPで接続ゾーンを設定する
limit_conn_zone $binary_remote_addr ゾーン=perip_conn:10m;
 #サーバーに応じて接続ゾーンを設定する
limit_conn_zone $server_name ゾーン=perserver_conn:100m;
サーバー{
        聞く 80;
        サーバー名 seckill.52itstyle.com;
索引 インデックス.jsp;
        位置 / {
              #バースト通過の現在の制限キューを要求します。デフォルトは 0 です。
              limit_req ゾーン=api_read バースト=5;
              #接続制限、各IP同時リクエストは2
              制限接続 ペリプ接続 2;
              #サービスによって制限される接続数（つまり、サーバーへの同時接続数が制限される）
              limit_conn パーサーバー接続 1000;
              #接続速度制限
              制限レート 100k;
              proxy_pass http://seckill;
        }
 }
上流セキル {
        公平;
        サーバー 172.16.1.120:8080 重み=1 max_fails=2 fail_timeout=30s;
        サーバー 172.16.1.130:8080 重み=1 max_fails=2 fail_timeout=30s;
 }

設定手順

参加する

セッションステータスを保存するためのコンテナが IP ごとに定義されます。この例では、100 MB のコンテナが定義されており、32 バイト/セッションで 3,200,000 セッションを処理できます。

制限レート 300k;

各接続の速度を 300k に制限します。これは接続速度の制限であり、IP 速度の制限ではないことに注意してください。 IP が 2 つの同時接続を許可する場合、この IP のレート制限は limit_rate×2 になります。

バースト=5;

これはバケットのサイズに相当します。リクエストがシステムの処理速度を超えた場合、リクエストはバケットに配置され、処理を待機します。バケットがいっぱいの場合、残念ながらリクエストは直接 503 を返し、クライアントはサーバーがビジーであるという応答を受け取ります。システムがリクエストをゆっくりと処理する場合、バケット内のリクエストは永久にそこに留まることはできません。一定の時間を超えると、サーバーがビジー状態であるという応答が直接返されます。

オープンレスティ

後ろ姿は見覚えがありますか？はい、これは直接「理解万歳」と叫んだ羅永浩です。 2015年、Luo Yonghao氏はSmartisan Technology T2発表カンファレンスのチケット収益をOpenRestyに寄付しました。私も羅永浩は感情を持った太った男だと信じています。

ここでは、OpenResty のオープンソースの電流制限ソリューションを使用します。テストケースでは、lua-resty-limit-traffic モジュールとケースが付属する OpenResty1.13.6.1*** バージョンを使用しているため、実装が容易になります。

同時インターフェース/リクエストの総数を制限する

フラッシュセール中は、突然のトラフィックの急増によりシステム全体の安定性に影響が及び、クラッシュが発生する可能性があります。この場合、フラッシュセールインターフェースの合計同時実行数/リクエスト数を制限する必要があります。

ここでは、lua-resty-limit-traffic の resty.limit.count モジュールを使用します。記事が長いため、具体的なコードについてはソースコード openresty/lua/limit_count.lua を参照してください。

インターフェース時間ウィンドウ要求の数を制限する

フラッシュセールのシナリオでは、必ずしも人間のマウスが使用されるとは限りません。たとえば、12306 のチケット取得ソフトウェアは、人間のマウスよりもはるかに高速にチケットをスワイプできます。この時点で、チケットブラッシングが蔓延しないように、クライアント上の単位時間あたりのリクエスト数を制限する必要があります。もちろん、解決策は常に存在します。チケットを盗むソフトウェアは、常に防御を回避する方法を見つけます。一方で、技術の進歩も促進します。

ここでは、lua-resty-limit-traffic の resty.limit.conn モジュールを使用します。具体的なコードについては、ソースコード openresty/lua/limit_conn.lua を参照してください。

インターフェースリクエストの数をスムーズに制限する

以前のフロー制限方法ではバーストトラフィックが許可されていましたが、これは瞬間的なトラフィックが許可されることを意味します。突然のトラフィックを制限しないと、システム全体の安定性に影響を及ぼします。したがって、フラッシュセールのシナリオでは、リクエストレートは平均レート ×××、つまり 20r/s で処理される必要があります。

ここでは、lua-resty-limit-traffic の resty.limit.req モジュールを使用して、リーキーバケット電流制限とトークンバケット電流制限を実装します。

実際、リーキーバケットとトークンバケットの根本的な違いは、リクエストレートを超えるリクエストをどのように処理するかにあります。リーキーバケットは、平均速度で処理されるのを待つためにリクエストをキューに入れ、キューがいっぱいになるとサービスを拒否します。トークンバケットは、バケット容量が許せば、これらのバースト要求を直接処理します。

漏れやすいバケツ

バケット容量がゼロより大きく、遅延モードになっています。バケットがいっぱいでない場合、リクエストはリクエストキューに入り、一定の速度で処理を待機します。いっぱいの場合は、リクエストは拒否されます。

トークンバケット

バケット容量はゼロより大きく、非遅延モードです。バケット内にトークンが存在する場合はバーストが許可され、存在しない場合は要求は拒否されます。

ストレステスト

上記の構成効果をテストするために、AB ストレステストを使用します。 Linux で次のコマンドを実行します。

 ＃ インストール
yum -y httpd-toolsをインストールします
# ab バージョンを表示
アブ-v
 # ヘルプを表示
ab --ヘルプ

テストコマンド:

 ab -n 1000 -c 100 http://127.0.0.1/

テスト結果:

サーバーソフトウェア: openresty/1.13.6.1 #サーバーソフトウェア
サーバーホスト名: 127.0.0.1 #IP
サーバーポート: 80 #リクエストポート番号
 
ドキュメントパス: / #ファイルパス
ドキュメントの長さ: 12 バイト #ページ内のバイト数
 
同時実行レベル: 100 #同時リクエスト数
テストにかかった時間: 4.999 秒
完了したリクエスト: 1000 #合計リクエストツリー
失敗したリクエスト: 0 #失敗したリクエストの数
書き込みエラー: 0
転送合計: 140000 バイト #要求されたデータの合計サイズ
転送された HTML: 12000 バイト #HTML ページの実際の合計バイト数
1秒あたりのリクエスト数: 200.06 [#/秒] (平均) #1秒あたりのリクエスト数。これはサーバーのスループットを表す非常に重要なパラメータ値です。
リクエストあたりの時間: 499.857 [ms] (平均) #ユーザーリクエストの平均待機時間
リクエストあたりの時間: 4.999 [ms] (平均、すべての同時リクエスト全体) # 平均サーバー処理時間。サーバースループットの逆数です。
転送速度: 27.35 [Kbytes/sec] 受信 #1秒あたりに受信されるデータ長
 
接続時間 (ミリ秒)
最小平均[+/- 標準偏差] 中央値最大値 
接続: 0 0 0.8 0 4
処理: 5 474 89.1 500 501
待機中: 2 474 89.2 500 501
合計: 9 475 88.4 500 501 
 
一定時間内に処理されたリクエストの割合（ミリ秒）
  50% 500
  66% 500
  75% 500
  80% 500
  90% 501
  95% 501
  98% 501
  99% 501
 100% 501 (最長リクエスト)