3 天前，運(yùn)行的社區(qū)系統(tǒng)報告，很多老的歷史照片都無法作為附件加載 —— 小鯊魚，快來解決問題。

很多人都問題，為什么程序員每天不是在調(diào) Bug 就是在調(diào) Bug 的路上。

其實呀，計算機(jī)是一個邏輯性非常強(qiáng)的東西，每一步都應(yīng)該是原因的，所以我們要通過邏輯性找到不同的原因。

這個和把大象關(guān)進(jìn)籠子里有幾步差不多。

調(diào)試的方法其實就是針對問題去找到原因，為什么會出現(xiàn)這個問題。

對 Web 系統(tǒng)來說，無非就是程序和數(shù)據(jù)，首先需要確定數(shù)據(jù)丟了沒有，如果數(shù)據(jù)丟了，怎么調(diào)試都沒有用，因此先恢復(fù)數(shù)據(jù)，保障系統(tǒng)運(yùn)行永遠(yuǎn)是第一位的。

Step 1 有沒有快速的解決方案

為什么會出現(xiàn)這個問題，不是好好的嗎？原來是因為更換了域名，同時更換了云存儲的存儲路徑。

現(xiàn)在問題就是主題中的內(nèi)容都沒有丟，但是當(dāng)主題重新生成 HTML 后，只要主題中有附件的部分，全部都沒有正確生成 HTML。

快點檢查存儲在云端的附件有沒有被刪掉。找到一個老的主題已經(jīng)生成的 HTML，然后檢查丟失的圖片對比的服務(wù)器地址。

云存儲的附件都還在，沒有被丟掉，如果直接把絕對 URL 拷貝過來，問題就解決了。

趕緊的，有備份嗎？

有備份，趕快恢復(fù)一次。

Step 2 數(shù)據(jù)恢復(fù)

恢復(fù)備份后無法解決問題。

備份恢復(fù)了，問題依舊。怎么辦？

有多少主題被影響到？

往前面找 3 個月，1 個月，2 個星期的隨機(jī)帖子，貌似各種情況都有，但是大量丟的都在 幾個星期之前的，幾乎都無法顯示。

那應(yīng)該是在生成 HTML 的短 Hash 代碼轉(zhuǎn)碼回去的時候出現(xiàn)問題了。

這個數(shù)量已經(jīng)非常大了，沒有辦法通過手工恢復(fù)的方式完成了。

這里有個判斷，如果只影響到幾個主題，通常我們都可以手工恢復(fù)的，如果影響的主題超過幾十個，這個時候是沒有辦法手工恢復(fù)，只能找到原因讓程序去做了。

Step 3 調(diào)試存儲桶路徑

因為我們知道存儲桶路徑換了，是不是因為存儲桶的名字問題呢？

把服務(wù)器上存儲桶的名字重新改回來，問題依舊。

現(xiàn)在這個和存儲桶的路徑應(yīng)該沒有太大的關(guān)系。

Step 4 調(diào)試 Hash 算法

是不是因為在 Base 62 Hash 算法的時候因為 SHA1 的不同而導(dǎo)致了算法沒有被正常解碼？

讀了下程序，貌似問題也不在這里。

這個 Base62 算法，程序中沒有加摘要擾亂計算。

Step 5 查詢數(shù)據(jù)庫的數(shù)據(jù)

現(xiàn)在我們得從數(shù)據(jù)庫查看了，因為沒有辦法確定到底是程序還是數(shù)據(jù)的問題。

貌似在備份前 3 天的數(shù)據(jù)是好的，我們應(yīng)該要把數(shù)據(jù)庫的數(shù)據(jù)恢復(fù)下看看。

服務(wù)器現(xiàn)在在運(yùn)行的，好在新加的主題沒有問題，那就讓服務(wù)器運(yùn)行著吧。

我們把服務(wù)器上的數(shù)據(jù) Dump 下來，導(dǎo)入到我們本地的 PGSQL 數(shù)據(jù)庫中吧。

這個導(dǎo)入過程可能要一天也可能是幾個小時，因為導(dǎo)入數(shù)據(jù)比較容易出錯。

Step 6 如何進(jìn)入服務(wù)器 Docker 容器內(nèi)查詢

數(shù)據(jù)本地拿到了，Hash 前的和 Hash 后的數(shù)據(jù)都在呀，那問題在哪呢？

到 Docker 容器內(nèi)去查詢下現(xiàn)有的服務(wù)器數(shù)據(jù)吧。

這個時候，你就可能需要時間去了解下如何進(jìn)入 Docker，如何在 Docker 連接數(shù)據(jù)庫后運(yùn)行 SQL。

因為這個庫是在容器內(nèi)的，你是沒有辦法通過其他數(shù)據(jù)庫工具直接連接到數(shù)據(jù)庫上運(yùn)行 SQL 的，通常生成服務(wù)器也不允許你這么做。

查詢的結(jié)果，發(fā)現(xiàn)是本地有的記錄，服務(wù)器上沒有。

大概率知道數(shù)據(jù)庫映射出了問題。

Step 7 把本地的備份數(shù)據(jù)恢復(fù) 1 條

把本地備份的 1 條數(shù)據(jù)恢復(fù)到服務(wù)器上，然后刷下效果，看是不是就是因為數(shù)據(jù)丟了？

太棒了，恢復(fù)的這條數(shù)據(jù)被顯示出來了，主題正常了。

原來就是丟數(shù)據(jù)了，備份不應(yīng)該是備份全部的嗎？看來應(yīng)該是恢復(fù)哪里或者某個表出問題了。

Step 8 獲得具體有多少數(shù)據(jù)被影響

因為我們知道那個表現(xiàn)在有問題了， Select Count(*) 唄。

發(fā)現(xiàn)一共了 4000 多條記錄被影響。

趕緊把本地的這些記錄組織成 SQL 到服務(wù)器上運(yùn)行吧，都是 Insert 應(yīng)該問題大。哪怕是重復(fù)數(shù)據(jù)，因為有 Key，重復(fù)數(shù)據(jù)會被忽略掉。

導(dǎo)入后問題解決了。

Step 9 解決問題后 2 天同樣的問題又出現(xiàn)了

先查 Count，后來發(fā)現(xiàn) Count 數(shù)據(jù)被刪掉了 2000 多。

這肯定是有自動運(yùn)行進(jìn)程對數(shù)據(jù)進(jìn)行清理了。

上網(wǎng)考古下，發(fā)現(xiàn)貌似有一個無用附件清理進(jìn)程會對程序認(rèn)為無用的附件進(jìn)行清理。

先不管了，把這 2000 多條數(shù)據(jù)恢復(fù)再說。

Step 10 關(guān)閉清理進(jìn)程

先關(guān)閉清理進(jìn)程，然后看為什么這個程序會把我們實際是需要的數(shù)據(jù)給清理掉？

讀代碼，在清理之前，程序會判斷那些數(shù)據(jù)是需要清理的，這里有一個 Join 的 SQL 查詢。

這里 Join 了另外一個表。

Step 11 對比 JOIN 表數(shù)據(jù)量

馬上對比另外表的數(shù)據(jù)量。

這里了明顯又丟了好幾千條記錄。

原來在主題和附件的關(guān)系映射表中的數(shù)據(jù)丟了部分，導(dǎo)致整個附件表的有用數(shù)據(jù)被當(dāng)做無效數(shù)據(jù)清理掉了。

Step 12 數(shù)據(jù)恢復(fù)

把 JOIN 的映射表數(shù)據(jù)進(jìn)行恢復(fù)。

然后等待重構(gòu)運(yùn)行結(jié)果，保持清理進(jìn)程開啟，2 天后查看結(jié)果。

同時增加服務(wù)器備份數(shù)量，從保留 30 天的備份，到現(xiàn)在增加到保留 300 天。

Step 13 問題總結(jié)和記錄

把整個過程總結(jié)下來，花個 10 多分鐘記錄下問題。

上面是針對一個問題進(jìn)行調(diào)試的小過程，如果你對系統(tǒng)比較熟悉的話，很快就會定位到映射部分。如果對系統(tǒng)不熟悉的話，上面的步驟就是一個幾乎完整的 Debug 流程。

在上面的流程中到處都是坑，這就是為什么有些人看起來只需要幾個小時或者幾分鐘就解決問題了，你卻用了幾天的時候，甚至幾天都沒有進(jìn)展。

相信我，不是因為你不夠優(yōu)秀，僅僅是因為你對已有的這套系統(tǒng)的設(shè)計，數(shù)據(jù)，邏輯不熟悉而已，這沒什么大不了的，時間問題。

解決一個程序問題需要多少步——確定我們沒有在摸魚 - 程序人生 - iSharkFly文章來源地址http://www.zghlxwxcb.cn/news/detail-700990.html

到了這里，關(guān)于解決一個程序問題需要多少步——確定我們沒有在摸魚的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！