在我們開始之前，先介紹一下我是誰以及為什么它在這種情況下很重要。我是筆記本制造公司的軟件開發(fā)人員，過去兩年在這里工作。在我現(xiàn)在所在的團隊中，我是唯一的開發(fā)人員，負責使用 Go 和 Grafana 創(chuàng)建、監(jiān)控和維護數(shù)據(jù)管道、自動化以及監(jiān)控系統(tǒng)。
我還要補充一點，前一年我是實習生。而且我是自學的。

好吧，但是為什么這很重要呢？

嗯，當我遇到自己無法解決的障礙或問題時，我沒有高級開發(fā)人員，也沒有任何形式的內部指導可以指導我，這就是我寫作的主要原因。我認為這是一件有趣的事情并且想要分享。它不會是一個令人驚嘆的軟件，一個突破或類似的東西，但它提醒我們從頭開始構建東西是可能的。您不需要成為百萬分之一的 10 倍開發(fā)人員或類似的人。

P.S：順便說一句，我使用 neovim。

一百萬行

這個數(shù)字可能看起來有些夸張或類似的東西，盡管我希望如此，但事實并非如此?？?，在制造環(huán)境中工作時，有時我們不會考慮需要多少個項目，以及當您必須跟蹤每個組件的許多制造隊列的每個點時它會生成多少數(shù)據(jù)。
無論是一個小螺絲，還是上一代 CPU，都必須被跟蹤，帶有時間戳！
所以，是的，生成的數(shù)據(jù)量是正確的，而這只是開始。以下是使問題變得很酷的其他酷點（在我看來）：

• 該數(shù)據(jù)的來源沒有經(jīng)過壓縮或類似的處理，因此天氣好的時候平均請求時間接近 2 到 3 分鐘。如果源代碼滯后，它可能會超過 5 分鐘（這是一個比我更舊的 java 系統(tǒng)。）。
• 關于格式，我可以選擇處理 XML 響應或 CSV 響應，當然我選擇了 CSV 路線。我不是受虐狂。
• 并且需要選擇數(shù)據(jù)獲取的間隔，至少一小時（不，我不知道為什么，是的，我嘗試過較小的間隔）。
• 源沒有延遲加載或緩存系統(tǒng)，因此兩個相同的請求將生成相同的響應，但時間不同。
• 最后，讓事情變得更有趣的是，它是 Microsoft 的產品，稱為 SQL Server Reporting Services，但也有一些晦澀的警告。哦，而且我需要使用的數(shù)據(jù)庫是 MSSQL，這很痛苦。

這就是整個上下文，現(xiàn)在有趣的部分開始。

第一次迭代——DMP

我喜歡使用軟件的方式非常簡單。讓它變得丑陋且?guī)缀醪黄鹱饔?->保持丑陋并改進功能 ->仍然丑陋，但優(yōu)化得更好 ->漂亮、優(yōu)化且工作 ->然后你的經(jīng)理說你所做的工作太好了，源無法處理它，導致中斷。臥槽。

無論如何，DMP 代表 Dumb Mode Protocol，只要讓它以最愚蠢的方式工作即可，這意味著勉強可以工作。

所以，對于第一輪，我的目標很簡單，進行身份驗證，發(fā)出請求，解析數(shù)據(jù)，發(fā)送到數(shù)據(jù)庫。很簡單，對吧？而且，在紙面上，它是，直到我發(fā)現(xiàn)我必須使用的身份驗證和授權方法是 ntlmssp，這是一種我不知道存在的質詢響應身份驗證方法。事實上，我必須進入舊版 .NET 4 代碼才能找到它。我沒學過C#。
在瀏覽了比我年長的遺留代碼之后，我在嘗試理解它時遇到了困難，因為出于某種原因，編寫它的人認為將其隱藏到 5 層抽象、構造函數(shù)和 OOP 中是一個好主意。不有趣，令人羞愧的經(jīng)歷。然后我成功了。一小時后，我的用戶被屏蔽，因為顯然該來源有速率限制。但沒有緩存或延遲加載。

好吧，在這一切之后，我只需要傳遞查詢參數(shù)并獲取數(shù)據(jù)，不再需要源的復雜性。好吧，我們來查一下查詢參數(shù)的文檔。

...

此時，考慮到所有因素，您可能猜對了。文檔？這是只有硅谷才有的異國美食嗎？
不管怎樣，在絞盡腦汁之后，我決定檢查一下這個 SQL Server Reporting Services 的站點/界面，令我高興的是，然后是仇恨，它有一種方法來了解過濾器及其值。

只知道頁面中的（“全部”）過濾器，例如選擇所有生產線，只是選中所有框的抽象。好吧，讓我們復制過濾器并將其放入查詢字符串中，對其進行編碼，然后開心吧！

成功了！或者說我是這么想的。

還記得我說過我的用戶被屏蔽了嗎？好吧，看起來擁有執(zhí)行此類任務的管理員權限，并由 C-Suite 授權執(zhí)行此操作（事實上，這是他們要求的），但不足以允許我執(zhí)行多個請求。我的用戶被屏蔽了，但是，對于我的經(jīng)理來說，這就像說“什么也沒發(fā)生”。幸運的是，我很快就解封了。

與此同時，我決定按照我處理該項目其余部分的方式進行工作。此時我已經(jīng)有了一個樣本，它符合帖子的標題。看到這七位數(shù)字讓我懷疑自己是否能夠做到，因為我對這個數(shù)據(jù)量的經(jīng)驗為零。

為了將我的想法付諸實踐，我希望進入 exlidraw 并設計出我想做的事情。我知道工作池的概念，但之前沒有實現(xiàn)過。因此，我閱讀了相關內容，看到了一些實現(xiàn)，并詢問了一位對我?guī)椭艽蟮呐笥?。他是我沒有的前輩。

用偽代碼寫出來后，我心里想：

“哇，這非常簡潔，所有這些通道和 goroutine 肯定不會產生內存泄漏，對吧？”

好吧，可能不是那些確切的詞，但大致意思是這樣的。在完成第一次迭代、設法執(zhí)行請求（不會被阻止）并將其加載到內存中之后，我應用了工作池概念。

然后我就遇到了 BSOD。有趣的是，就在 CrowdStrike 罷工的同一天，我當然不認為我造成了工廠的重大停電。
另外，是的，我必須使用 Windows 來工作，但不用擔心！我使用 WSL2。

在檢查了我的第一次堆棧溢出的大量堆棧跟蹤后，我發(fā)現(xiàn)了這個錯誤。在將數(shù)據(jù)發(fā)送到消費者通道時，我沒有考慮到某些數(shù)據(jù)可能會出錯，主要是由于違反了主鍵，或者僅僅是因為，也許，我沒有正確處理錯誤。

經(jīng)驗教訓，使用錯誤通道來避免重大問題。并處理您的錯誤，無論是通過簡單的字符串檢查（丑陋，但有效），或者只是頂級記錄它，然后高興。由于我遇到的錯誤并不嚴重，所以我可以繼續(xù)。

第二次迭代。內存泄漏。

這一步產生的內存泄漏量讓我以為我在做 C。但這只是主要的技能問題。
不管怎樣，你可能會想：

“你是如何在如此簡單的過程中造成內存泄漏的？”

很簡單，我正在學習和嘗試。

這一步中的主要問題是我天真地沒有確保數(shù)據(jù)被正確插入，并且我得到的主鍵違規(guī)量違反了我的記憶。這是我知道如何解決的問題，讓我們緩存數(shù)據(jù)吧！
等等，考慮到每一行都是唯一的，如何為每一行創(chuàng)建一個唯一標識符？

現(xiàn)在，這是很多人會嘲笑我的部分，因為，公平地說，這是最讓我崩潰的部分。我只是簡單地加入當前行的信息并將其解析為哈希函數(shù)，該哈希就成為我在映射中的鍵。

“為什么不使用 Redis？” - 你可能會問自己。

很簡單，官僚主義。這不是一家小公司。事實上，你們中的許多人可能正在使用他們制造的筆記本電腦。請求一個 Redis 實例這個簡單的行為至少需要三個工作日、四次會議、對官僚之神的犧牲，以及一份解釋原因和方式的完整文檔。
所以，是的，讓我們使用一個簡單的哈希圖并在第一次運行之前對其進行預初始化。它會增加整體加載時間，但會比請求更快。

通過這樣做，整個過程得到了改善，就像有了一個新電機一樣，memleaks 停止了，批次不會每次都失敗，錯誤和斷開連接的數(shù)量也減少了，非常好，對吧？對嗎？

現(xiàn)在，您知道有些事情變得混亂了。

第三次迭代。生活本來可以很美好。

我沒有考慮到的一點是，通過批量插入，可以驗證數(shù)據(jù)。這是流程的簡單表示。

獲取數(shù)據(jù)->檢查hashmap中是否存在數(shù)據(jù)的hash ->批量&插入

這有什么問題嗎？那么，如果我的批次中的單個插入失敗，會發(fā)生什么情況，它會在沒有條目的情況下重試嗎？如果是這樣，我可以重試多少次而不會使系統(tǒng)混亂并失去工作池實現(xiàn)的優(yōu)勢？
只有一種方法可以找出答案！我們來檢查一下。
我要補充的一點是，該源返回了超過 25 列，因此我必須小心每批插入的數(shù)據(jù)量，以免超過 2100 個參數(shù)，這是 MSSQL 的限制。

此時，我已經(jīng)在 Docker 容器中運行一些東西，該容器模仿資源有限的生產空間。為了添加上下文，該進程使用 1GB RAM 和大約 0.5CPU 運行。我本可以分配更多的資源，但這只是強行逼我出路。
通過在容器內運行這個新的迭代，添加一些時間戳并將其記錄到文件中以供以后分析。我發(fā)現(xiàn)由于重試次數(shù)增加了大約 5 分鐘。這是行不通的，刪除“臟”條目不是一個選項。

第四次迭代。生活是美好的。

為了解決這個問題，我增加了工人的數(shù)量。我使用了大約 50 名工作人員，并且由于 ThePrimagen 頂級貨架上的不和諧用戶的隨機猜測，我將其增加到 1000 名工作人員，并確保每個工作人員都驗證交易中的每個條目。萬一交易失敗，我直接回滾。
通過這樣做，我能夠解決核心問題并總體上提高該過程的整體速度?，F(xiàn)在是時候將其放入產品中并對其進行監(jiān)控了，因為，你知道，產品妖精可能會弄亂你的軟件。 （它們也被稱為技能問題，但這個名稱是禁止的。）

知道減少該系統(tǒng)的獲取間隔，要求使其接近實時（這意味著足夠快，讓他們不會注意到延遲），我創(chuàng)建了一個新容器，這一次具有更強健的功能檢查是否能夠承受負載，并將間隔設置為 3 分鐘?？紤]到平均獲取時間，這意味著我可能會有一些重疊，但我真的很想看看會發(fā)生什么。

我讓它運行了一夜，記錄結果以便稍后查看，令我驚訝的是，在工作日結束之前，我接到了經(jīng)理的電話。請注意，他不是技術人員或類似的人。

“嘿，‘我們’部署了一些與[我無法透露的系統(tǒng)名稱]交互的東西嗎？”

“是的，我按照要求實時部署了數(shù)據(jù)獲取系統(tǒng)。為什么？”

“你能，嗯，停下來嗎？它導致了停電，我們無法在這里工作?！盻

這，gadies and lentleman，完全是另一個級別的破壞性刺激。毫不夸張地說，我讓 20 多條生產線停止了一分鐘左右。無論如何，我停止了系統(tǒng)，一切都恢復正常。
第二天，我被要求將讀取之間的間隔從 3 分鐘增加到 30 分鐘，好吧，我想沒問題。我不會說謊，我有點難過，因為我無法看到它以最大速度運行，但是嘿，至少我讓它工作了。

使用這個新系統(tǒng)，使用該數(shù)據(jù)的報告的平均更新時間減少到 8~10 秒，這導致經(jīng)理以??相同的方式請求更多相同來源的報告。良好的工作會得到更多工作的回報！

注意事項

這是一次有趣的經(jīng)歷，主要是因為它讓我真正意識到 Go 的強大之處。使用比谷歌瀏覽器更少的內存，比微軟應用程序更少的存儲空間，比 Windows 計算器更少的 CPU 功率，我能夠改進一個舊的進程，這個進程實際上是暴力強制通過的（它在插入之前實際上檢查了數(shù)據(jù)庫中的每一行。我不知道）不知道前一個人怎么認為這是一個好主意。）。真的很有趣。

無論如何，請隨意分享您在整個過程中的想法，您會如何處理以及您會采取哪些不同的做法。由于我沒有開發(fā)同事，我想了解更多對此的看法。

以上是我如何處理每個請求的條目 - 使用 Go！的詳細內容。更多信息請關注PHP中文網(wǎng)其他相關文章！