始める前に、私が誰なのか、そしてなぜそれがこの場(chǎng)合重要なのかについて少し説明します。私は Notebook Manufacturing Company のソフトウェア開発者で、過去 2 年間ここで働いています。私が現(xiàn)在いるチームでは、私が唯一の開発者で、データ パイプライン、自動(dòng)化、Go と Grafana を使用した監(jiān)視システムの作成、監(jiān)視、保守を擔(dān)當(dāng)しています。
もう一つ付け加えさせていただくと、前年、私はインターンをしていました。そして私は獨(dú)學(xué)です。

わかりましたが、なぜそれが重要なのでしょうか?

そうですね、私には上級(jí)開発者もいなかったし、自分だけでは解決できない障害や問題に直面したときに私を?qū)Гい皮欷雰?nèi)部からの指導(dǎo)もありませんでした。それが私がこの記事を書いている主な理由です。とても楽しかったのでシェアしたいと思います。それは素晴らしいソフトウェアや畫期的なものではありませんが、物事をゼロから構(gòu)築することが可能であることを思い出させてくれます。 100 萬人に 1 人の 10x 開発者である必要はありません。

追伸: ちなみに私は neovim を使っています。

100萬行

この數(shù)字は誇張か何かのように見えるかもしれません、そして、そうであってほしいと思いますが、そうではありません。ほら、製造業(yè)のコンテキストで作業(yè)する場(chǎng)合、部品ごとに多くの製造キューのすべてのポイントを追跡する必要があるときに、必要なアイテムの數(shù)と、それによって生成されるデータの量が考慮されないことがあります。
それが小さなネジであっても、前世代の CPU であっても、タイムスタンプを使用して追跡する必要があります!
つまり、はい、生成されるデータの量は適切であり、それは単なる始まりにすぎません。 (私の観點(diǎn)から) この問題をクールにしているその他の優(yōu)れた點(diǎn)は次のとおりです:

• このデータのソースは圧縮などされていなかったため、平均リクエスト時(shí)間は良い日でも 2 ～ 3 分近くかかりました。ソースに遅れがあると、5 分以上かかる可能性があります (私よりも古い Java システムです)。
• 形式については、XML 応答を処理するか CSV 応答を処理するかを選択できましたが、もちろん CSV を選択しました。私はマゾヒストではありません。
• また、データを取得する間隔を最低 1 時(shí)間で選択する必要がありました (いいえ、理由はわかりません。はい、マイナーな間隔を試してみました)。
• ソースには遅延読み込みやキャッシュ システムがなかったため、2 つの等しいリクエストは異なる時(shí)間で同じ応答を生成します。
• そして最後に、事態(tài)をさらに盛り上げるために、これは SQL Server Reporting Services として知られる Microsoft の製品であり、獨(dú)自のあいまいな注意事項(xiàng)があります。ああ、データベースは MSSQL を使用する必要があるのですが、これが面倒です。

これが全體のコンテキストです。ここから楽しい部分が始まります。

最初の反復(fù) - DMP

私がソフトウェアに取り組む方法は非常にシンプルです。醜くてほとんど機(jī)能しないものにします ->見た目はそのままにして機(jī)能を改善 ->まだ醜いですが、より最適化されています ->美しく、最適化され、機(jī)能します ->そして、マネージャーは、あなたの仕事があまりにも優(yōu)れていたため、ソースがそれを処理できず、機(jī)能停止が発生したと言いました。 FML.

とにかく、DMP は Dumb Mode Protocol の略です。できる限り愚かな方法で動(dòng)作させるだけです。つまり、かろうじて動(dòng)作するようにすることを意味します。

そのため、最初のラウンドでは、私の目標(biāo)は単純で、認(rèn)証、リクエストの作成、データの解析、データベースへの送信でした。とてもシンプルですよね？そして、紙面では、使用しなければならなかった認(rèn)証および認(rèn)可方法が ntlmssp であることを発見するまで、そうでした。これは、存在を知らなかったチャレンジ/レスポンス認(rèn)証方法である ntlmssp でした。実際のところ、それを見つけるにはレガシー .NET 4 コードを使用する必要がありました。 C# をやったことがありません。
私よりも古いレガシーコードを調(diào)べた後、コードを理解するのに苦労しました。なぜなら、コードを書いた人は、何らかの理由で、それを抽象化、コンストラクター、および OOP の 5 層に隠すのが良い考えだと考えたからです。楽しくない、謙虛な経験。そして、それを機(jī)能させました。 1 時(shí)間後、どうやら送信元にレート制限があるため、ユーザーがブロックされました。ただし、キャッシュや遅延読み込みはありません。

すべてが終わったら、クエリ パラメータを渡してデータを取得するだけで済み、ソースを複雑にする必要はありません。わかりました。クエリ パラメーターのドキュメントを調(diào)べてみましょう。

...

この時(shí)點(diǎn)では、すべてのことを考慮すると、おそらくあなたの推測(cè)は正しかったでしょう。ドキュメンテーション？これはシリコンバレーでのみ提供されるある種のエキゾチックな食べ物ですか?
とにかく、知恵を絞った結(jié)果、この SQL Server Reporting Services のサイト/インターフェイスを検査することにしました。そして、嬉しいことに、そして憎しみにも、フィルターとその値を知る方法があったのです。

ページ內(nèi)の (「すべて」) フィルターで、たとえばすべての製造ラインを選択することは、すべてのボックスをチェックすることを抽象化したものにすぎないことだけがわかります。 OK、フィルターをコピーしてクエリ文字列に入れ、エンコードして満足しましょう!

うまくいきました！あるいはそう思いました。

ユーザーがブロックされたと私が言ったことを覚えていますか?そうですね、そのようなタスクを?qū)g行するための管理者権限があり、経営幹部からその実行を許可されている (実際、それは経営幹部から要求されています) だけでは、複數(shù)の要求を?qū)g行するには十分ではなかったようです。ユーザーはブロックされましたが、マネージャーにとっては「何も起こらなかった」と言っているのと同じでした。幸いなことに、私はかなり早くブロックを解除することができました。

それまでの間、私はこのプロジェクトの殘りの部分にどのように取り組むかを検討することにしました。この時(shí)點(diǎn)で私はすでにそのサンプルを持っており、それは投稿のタイトルどおりのものでした。 7 桁を見て、このデータ量を扱った経験がまったくなかった私にそれができるかどうか自問しました。

自分のアイデアを形にするために、excalidraw に參加して、やりたいことをデザインしました。ワーカー プールの概念は知っていましたが、これまで実裝したことはありませんでした。そこで、それについて読んで、いくつかの実裝を見て、非常に助けてくれた友人に尋ねました。彼は私にいなかった先輩です。

疑似コードで書き出した後、次のように思いました。

「おお、これはなかなかいいですね。これらすべてのチャネルとゴルーチンでメモリ リークが発生することは確実にありませんね?」

わかりました、その言葉通りではなかったかもしれませんが、その通りでした。最初の反復(fù)を?qū)g行し、(ブロックされることなく) リクエストを処理し、メモリにロードした後、ワーカー プールの概念を適用しました。

そしてBSODに直面しました。面白いことに、それはクラウドストライクのストライキと同じ日でした。私はまさか自分が工場(chǎng)に大規(guī)模な停止を引き起こしたとは思っていませんでした。
もちろん、仕事には Windows を使用する必要がありますが、心配する必要はありません。 WSL2を使用しています。

最初のスタック オーバーフローの膨大なスタック トラックを調(diào)べた後、間違いに気づきました。データをコンシューマ チャネルに送信するときに、主に主キーの違反、または単にエラーを適切に処理していなかったことが原因で、一部のデータでエラーが発生する可能性があることを考慮していませんでした。

教訓(xùn)として、エラー チャネルを使用して重大な問題を回避してください。そして、単純な文字列チェック (醜いですが機(jī)能します) を介してエラーを処理するか、単にトップレベルでログを記録するだけで、満足することができます。直面したエラーは重大なものではなかったので、続行することができました。

2 回目の反復(fù)。メモリリーク。

このステップで発生したメモリ リークの量を見て、C を?qū)g行しているのではないかと思いました。しかし、それは単なる大きなスキルの問題でした。
とにかく、あなたは次のように考えているかもしれません。

「このような単純なプロセスで、どのようにしてメモリ リークが発生したのですか?」

それは簡(jiǎn)単です。私は學(xué)び、試していました。

このステップでの主な問題は、私が素樸にデータが適切に挿入されていることを確認(rèn)できず、主キーの違反の量が私の記憶を侵害していたことでした。これは解決方法がわかっていた問題です。データをキャッシュしましょう!
待ってください。各行が一意であることを考慮して、各行の一意の識(shí)別子を作成するにはどうすればよいですか?

さて、これは多くの人が私を笑うところでしょう。なぜなら、公平を期すために、それが私を最もイライラさせる部分だからです?，F(xiàn)在の情報(bào)行を単純に結(jié)合してハッシュ関數(shù)に解析すると、そのハッシュがマップ內(nèi)のキーになりました。

「なぜ Redis ではないのですか?」 - あなたは自問しているかもしれません。

それは単純です、官僚主義。小さな會(huì)社ではありません。実際のところ、おそらく皆さんの多くは自社製のラップトップを使用しているでしょう。 Redis インスタンスをリクエストするという単純な行為には、少なくとも 3 営業(yè)日、4 回の會(huì)議、官僚制の神への犠牲、そしてその理由と方法を説明する完全な文書が必要になります。
そうですね、単純なハッシュ マップを使用して、最初の実行前に事前初期化しましょう。全體的な読み込み時(shí)間は長くなりますが、リクエストよりも早くなります。

そうすることで、新しいモーターを持ったかのように全體的なプロセスが改善され、メモリリークが停止し、バッチが毎回失敗することもなくなり、エラーや切斷の量も減少しました。とても良いことですよね?そうですよね?

もう、何かがごちゃ混ぜになっていることがわかります。

3回目の反復(fù)。人生は良いものかもしれない。

私が考慮していなかった點(diǎn)の 1 つは、バッチ挿入を行うことでデータが検証されるという事実でした。流れを簡(jiǎn)単に表すと次のようになります。

データの取得 ->データのハッシュがハッシュマップに存在するかどうかを確認(rèn)します。バッチ&挿入

それで、何が問題なのでしょうか?では、バッチ內(nèi)の 1 つの挿入が失敗した場(chǎng)合はどうなるでしょうか。エントリなしで再試行されるのでしょうか?その場(chǎng)合、システムを混亂させたり、ワーカー プール実裝の利點(diǎn)を失わずに、どれくらいの再試行を行うことができますか?
それを知る方法はたった一つ！確認(rèn)してみましょう。
1 つ追加できる點(diǎn)は、このソースが 25 列を超える列を返したという事実です。そのため、MSSQL の制限である 2100 パラメーターを超えないよう、バッチごとに挿入するデータの量に注意する必要がありました。

この時(shí)點(diǎn)で、私はすでに、限られたリソースで実稼働スペースを模倣する Docker コンテナーで物事を?qū)g行していました。コンテキストを追加するために、このプロセスは 1 GB の RAM と約 0.5 CPU で実行されました。もっと多くのリソースを割り當(dāng)てることもできましたが、それは単に強(qiáng)引なやり方になってしまいます。
この新しい反復(fù)をコンテナー內(nèi)で実行し、いくつかのタイムスタンプを追加し、後で分析するためにファイルにログアウトします。再試行の量により、約 5 分増加することがわかりました。これは機(jī)能しません?！弗扩`ティ」エントリを削除するという選択肢はありませんでした。

4 回目の反復(fù)。人生は良いものです。

この問題を解決するために、労働者の數(shù)を増やしました。私は約 50 人ほどのワーカーを使用していましたが、ThePriimagen の最上位にいる Discord ユーザーのランダムな推測(cè)のおかげで、ワーカーを 1000 人に増やし、各ワーカーがトランザクション內(nèi)の各エントリを検証するようにしました。トランザクションが失敗した場(chǎng)合は、単にロールバックしました。
そうすることで、中心的な問題を解決し、このプロセス全體の速度を全體的に向上させることができました。今度は、それを prod に入れて監(jiān)視するときが來ました。なぜなら、prod ゴブリンがソフトウェアを混亂させる可能性があるからです。 (スキルの問題とも呼ばれますが、この名前は禁止されています。)

このシステムのフェッチ間隔を減らすことが要求され、ほぼリアルタイム (つまり、遅延に気付かないほど十分な速度) にすることが要求されることを知って、今回はもう少し堅(jiān)牢な新しいコンテナを作成しました。負(fù)荷に耐えられるかどうかを確認(rèn)し、間隔を 3 分に設(shè)定します。平均フェッチ?xí)r間を考慮すると、多少の重複はあるかもしれませんが、実際にどうなるか見てみたかったのです。

一晩実行し、後で確認(rèn)するために結(jié)果をログに記録しました。そして驚いたことに、勤務(wù)時(shí)間が終了する前にマネージャーから電話を受けました。言っておきますが、彼は技術(shù)者などではありません。

「ねえ、[私が公開できないシステム名] と対話するものを「私たち」は導(dǎo)入しましたか?」

「はい、リクエストに応じてリアルタイムでデータ取得システムを?qū)毪筏蓼筏?。なぜです?」

「うーん、止めてもらえますか? 停電が発生したため、ここでは作業(yè)できません。」_

これは、ギャディとレントルマン、まったく別のレベルの畫期的な製品です。文字通り、20 以上の生産ラインを 1 分間ほど停止しました。とにかく、システムを停止したところ、すべてが正常に戻りました。
翌日、取得の間隔を 3 分ではなく 30 分に増やすように言われました。まあ、大丈夫でしょう。噓はつきません。最高速度でのパフォーマンスを見ることができなくなるのは少し殘念でしたが、少なくとも、うまく機(jī)能するようになりました。

この新しいシステムにより、このデータを使用したレポートの平均更新時(shí)間は 8 ～ 10 秒に短縮され、その結(jié)果、管理者によって同じソースのレポートが同様に要求されることが多くなりました。良い仕事には、より多くの仕事が與えられます!

考慮事項(xiàng)

それは主に、Go が実際にどれほど強(qiáng)力であるかを?qū)g感させられたという事実により、楽しい経験でした。 Google Chrome よりも少ないメモリ、Microsoft アプリよりも少ないストレージ、Windows 電卓よりも少ない CPU パワーを使用して、文字通り総當(dāng)たりで処理を進(jìn)めていた古いプロセスを改善することができました (文字通り、挿入前にデータベース內(nèi)の各行をチェックしていました。前の人がそれが良いアイデアだとどう考えたのかはわかりません。)本當(dāng)に楽しかったです

とにかく、このプロセス全體を通してあなたの考えを自由に共有してください。どのようにアプローチするか、別の方法で何をしただろうか。私には開発者の同僚がいないので、それについての意見をもっと知りたいです。

以上がリクエストごとのエントリの処理方法 - Go! を使用しての詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。