問題の状況：トラックがサービスのAPPポイントを埋設されています。流行、APPのユーザトラフィックの急増、サーバリソースの制約、サービスの一時的な閉鎖のためにいくつかの時間前。それだけで蓄積されたデータである、と多くの需要統計はありませんので、我々はすべて再び行くサービスを忘れてしまった...新しい統計的な要件があるまで。モバイルデータは、再試行してプッシュするSDKの終わり以来、データ損失の問題を心配しないでください。しかし、サービスの再起動後、503に指示します。今、トラブルシューティングのプロセスを扱う：アプリケーションの最も外側の層は、不確実性のサービスやnginxの設定の問題であるため、ネットワークサービス要求でサーバーに直接ログイン、nginxのある、我々は明らかに、深刻な残業、復帰に30秒以上の要求を見つけましたサービスに問題。
動向について、何ら直接的なデータがアップされていないために、ログのgrafanaは、数百の後にQPSを参照してください。プロメテウスの方法は、タイミングデータ取得要求です/actuator/prometheus。サービスのタイムアウトの多くは、プロメテウスは、Tomcatが既に運ぶことができなかったためか、データを取得する方法はありません。
解決プロセス：最初の考えは、過去の経験に基づいているソリューションのTomcatのスレッドの数を増やしたいと考えています。直接ノード上のパラメータにスタートアップを変更するには-Dserver.tomcat.max-threads=1000、アイデア、または8Kに死んで、再び、直接変更してくるフローがスタートした後カードを検証する試みの後に少し良くした後、grafanaにはほとんどが少しアップQPSを見ることができますが、数分、grafana曲線と壊れて、この時間、わずか数百QPS、その要求が10秒以上かかります。...または私は耐えたケースである、コードからパフォーマンスの問題を見つけることを試みるようになったことがわかっていませんでした。埋没サービス・インターフェースは、単純な分析は、カフカ投げ出さ要求を受信した後、データを行う唯一のモバイル端末への呼び出しと、このインタフェースで、コードはカフカに情報を送ることに加えて、他の場所は非常に可能性が消費されない、非常に簡単ですときに長い時間。コードを変更しようとすると、時間のかかるを記録したカフカにメッセージを送信すると、コードはおそらく
long startTime = System.currentTimeMillis();
//发送消息到kafka
log.info("耗时:{}",(System.currentTimeMillis()-startTime));
复制代码サービスを再起動し、時間のかかるログミリ秒の初めだけを印刷するには、ゆっくり秒になって、その後、数十秒に変わります。この場所は問題があります！バッチサイズのカフカプロデューサーをチェックし、のみ50、少し小さいです。シンプルで粗製のサービスが数分以上付着より再開され、1Kにバッチサイズのプロデューサーを増加したが、まだぶら下がっ。
二つの流れ、そして自分が落ち着かせてみてください。データ報告が成功しなかった場合は閉じるヶ月程度のサービスに今、再試行が報告されたが、これは実際に比較的大量のデータとなり、新たなデータの中に蓄積し続けることにします。トラフィックはそれほど大きくないの後しかし、わずか数日のピーク、それは今だけ一時的に遭遇する問題であり、これらの処理されたデータは、トラフィックが安定化されます。
ピークフローは503に押圧されるサービス、ソリューションの一つが制限されてしまいます。おそらく、リクエストの処理能力を超えて、容量とサービス、ロックされた流れを運ぶ推定し、リターンは500が直接、再試行します埋設SDKは、データが失われることはありません。グアバはRateLimiterと呼ばれるツール、ダイレクトラインを持っており、次のようにコードがあるだけまで
public static final RateLimiter RATE_LIMITER = RateLimiter.create(1000);
@RequestMapping
public ResponseDataWrapper<Object> trackEvent(SADataWrapper saDataWrapper) {
if (RATE_LIMITER.tryAcquire()) {
throw new RateLimitException();
}
//省略业务处理代码
}
复制代码予想通り、ライン、1K周りの流れの安定の初めに、秋の後、これまでのところ、問題が解決され、
背中に書かれました
問題が処理された後、リコールや多くの欠陥を発見しました。
まず：あまり変更コードを直接回線に送信され、複雑ではありませんが、確認するためにテストされていないが、それはワイヤーに新たな問題をもたらす可能性があります
第二：何もデータが直接ありませんがハンドルにTomcatの中プロメテウス、、、パラメータを調整どのくらいの実際の圧力、見ると心が何の下を持っていない時にコードを変更する方法はありません
第三：増加、時間のかかるログコードは実際には必要ではない、ちょうど診断ツールなどを使用しArthasは
第四：流量制限が、最も簡単で効果的な方法この問題を解決するためではなく、します。Tomcatはありserver.tomcat.accept-count、このパラメータをセットが比較的小さい場合、余分な要求が処理されません、また、Tomcatのスレッドの占有率を減らすことができます。コード変更の危険性よりもはるかに小さいです