訂餐系統之定時器Timer不定時

經過幾天漫長的問題分析、處理、測試、驗證，定時器timer終於定時了，於是開始了這篇文章，希望對還在糾結於「定時器timer不定時」的同學有所幫助，現在的方案，在系統日誌中會有警告，如果您有更好的方案，也請不吝賜教。

問題描述

先交代下背景吧：「訂單審核後，商家3分鐘內未確認的訂單，自動生成催單記錄，客服通過催單記錄聯絡商家，於是，我們就用的system.threading.timer 來作來定時器」。下圖為timer初始化部分**：

因為是重要客戶，我們本地測試伺服器都經過自認為嚴格的測試後，才提交正式伺服器。可是，每次提交正式伺服器後，每天總有幾個時間段不定時生成催單記錄，然後我們自己測試又都正常，於是不了了之！反覆幾次，客戶不高興了，領導怒了，做為程式設計師的我，才開始冷靜了，到底**出了問題？

問題分析及處理

1.消失的33分鐘

當然，首先，還是檢查**中程式記錄的日誌，因為我們定時程式是每分鐘執行一次（因為是多個任務，每個任務執行的時間間隔是不一樣的，所以每分鐘判斷哪個任務可以執行），所以日誌是比較容易查詢的，於是，看到了下圖：

**在這個時間點上，沒任何錯誤資訊，伺服器在這個點上也沒任何人為操作。當確認程式上基本沒有問題，我開始查詢系統日誌了。

2.應用程式池工作程序被**

知道這個時間點出問題了，在系統日誌中我很快找到了此時間的日誌，於是看到了下圖：

原來是沒有訪問，被**了，直到有人訪問時，再建立程序，到這裡才明白，為什麼我們測試都正常，因為我們測試時，一直在訪問，所以一切正常。

3.讓**自己訪問自己

當知道問題後，就開始糾結處理方案了，有人說寫伺服器程式，建立乙個服務，讓此服務去生成催單，但因為是正式伺服器，我們沒辦法鏈結的，所以此方案雖好，但對我們來說不切實際；google了下，找到乙個自認為簡單、可行的方案，如下圖（不記得**了，見諒）：

4.程序在關閉過程中超出時間限制

雖然結果還是一樣，但是我們離真相越來越近了，找到出錯時間點前後的**日誌和系統日誌，看到了下圖的資訊：

系統日誌：

5.程式池配置

看到上圖的問題，我最先想到的還是對程式池進行配置，之前對這方便了解也不多，也google了乙個比較文明的配置，然後根據情況調整了幾個引數：

修改配置後，問題依然存在，路在何方？

6.失敗不可怕，再來一次！

**時，訪問失敗，如果過15s再訪問呢，是的，失敗不可怕，再來一次，於是，有了下面的**：

發布、測試，1小時正常，3小時正常，8小時正常，24小時正常，30小時正常，心總算能踏實了，但是回頭想了下，程序都**了，為什麼再訪問一次程式會執行，iis日誌中每次**時，都只有一條訪問記錄，只有得空時再好好研究下了！結語

寫了幾年**，還是第一次，通過這麼多日誌，特別是伺服器的日誌來解決問題，過程雖然漫長，但還是苦並快樂著！！！

30小時正常，也許到80小時，160小時，又會有問題了，持續關注中...

成為一名優秀的程式設計師！