一: 問題提出mysql
現現在你們寫的netcore程序大多部署在linux平臺上,並且服務程序裏面可能會作各類複雜的操做,涉及到多數據源(mysql,redis,kafka)。成功部署成後臺linux
進程以後,你覺得這樣就萬事大吉了? 殊不知當你更新代碼時,暴力的kill掉這個進程致使你的業務出現數據不一致,業務流程被破壞等等問題。好比下面這段代碼:redis
1. TestServicesql
1 public class TestService 2 { 3 public static void Run() 4 { 5 while (true) 6 { 7 Console.WriteLine($"{DateTime.Now}: 1. 獲取mysql"); 8 System.Threading.Thread.Sleep(2000); 9 Console.WriteLine($"{DateTime.Now}: 2. 獲取redis"); 10 System.Threading.Thread.Sleep(2000); 11 Console.WriteLine($"{DateTime.Now}: 3. 更新monogdb"); 12 System.Threading.Thread.Sleep(2000); 13 Console.WriteLine($"{DateTime.Now}: 4. 通知kafka"); 14 System.Threading.Thread.Sleep(2000); 15 Console.WriteLine($"{DateTime.Now}: 5. 全部業務處理完畢"); 16 System.Threading.Thread.Sleep(2000); 17 } 18 } 19 }
2. Main程序後端
1 public static void Main(string[] args) 2 { 3 var bgtask = Task.Run(() => { TestService.Run(); }); 4 5 bgtask.Wait(); 6 }
這裏不考慮程序的健壯性,只表達這裏可能出現的問題,當程序退出後,這裏必然會遇到TestService.Run方法出現未執行完的狀況,致使數據不一致,好比下centos
面我簡單的部署了一下,能夠看到程序到了 5:03:24s以後就結束了,顯然破壞了業務邏輯。程序沒有完整的執行結束,那問題該怎麼解決呢?安全
[root@localhost netcore]# nohup dotnet ConsoleApp4.dll & [1] 4101 [root@localhost netcore]# nohup: ignoring input and appending output to ‘nohup.out’ [root@localhost netcore]# ps -ef | grep dotnet root 4101 2865 0 17:03 pts/0 00:00:00 dotnet ConsoleApp4.dll root 4118 2865 0 17:03 pts/0 00:00:00 grep --color=auto dotnet [root@localhost netcore]# kill 4101 [root@localhost netcore]# tail nohup.out 9/2/18 5:03:06 PM: 2. 獲取redis 9/2/18 5:03:08 PM: 3. 更新monogdb 9/2/18 5:03:10 PM: 4. 通知kafka 9/2/18 5:03:12 PM: 5. 全部業務處理完畢 9/2/18 5:03:14 PM: 1. 獲取mysql 9/2/18 5:03:16 PM: 2. 獲取redis 9/2/18 5:03:18 PM: 3. 更新monogdb 9/2/18 5:03:20 PM: 4. 通知kafka 9/2/18 5:03:22 PM: 5. 全部業務處理完畢 9/2/18 5:03:24 PM: 1. 獲取mysql [1]+ Done nohup dotnet ConsoleApp4.dll [root@localhost netcore]#
二:思考 kill 命令app
要解決這個問題,你們必定要從kill命令入手, 在centos上進行kill -x pid 的時候,不知道有多少人瞭解了這個命令,除了常見的 kill -9 pid ,其實還有不少其函數
他的數字,則表明其餘的意思,能夠經過kill -l 看一下。測試
1 [root@localhost ~]# kill -l 2 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 3 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 4 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 5 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 6 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 7 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 8 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 9 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 10 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 11 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 13 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 14 63) SIGRTMAX-1 64) SIGRTMAX
其中裏面的
2. SIGNIT (Ctrl+C)
3. SIGQUIT (退出)
9. SIGKILL (強制終止)
15. SIGTERM (終止)
均可以讓程序退出,好了,線索出來了,那我能不能讓程序捕獲到kill命令發出的這Sigxxx信號呢??? 經過尋找資料以後的一陣渾身痙攣,你明白了原來只有
-9是不能讓程序捕獲到,其餘的程序都能捕獲,那麼既然能捕獲,我就能夠在捕獲的事件中作程序的安全退出。 大概的腦圖就像下面這樣:
三:研究如何捕獲
在core 2.0以後,獲取sigterm就很是簡單了,能夠在當前應用程序域中掛載一個ProcessExit 事件,在ProcessExit中讓應用程序安全的退出。
而後還有一個問題就是,如何在ProcessExit中通知TestService結束執行呢? 這裏就用到了CancellationTokenSource 這種線程安全的取消協調機制,思考以後
畫出來的腦圖大概是這個樣子,不必定對,可是邏輯大概出來了。。。
四: 問題解決
有了上面的腦圖,寫起代碼就快啦~~~
1. Main函數
1 public static void Main(string[] args) 2 { 3 var cts = new CancellationTokenSource(); 4 5 var bgtask = Task.Run(() => { TestService.Run(cts.Token); }); 6 7 AppDomain.CurrentDomain.ProcessExit += (s, e) => 8 { 9 Console.WriteLine($"{DateTime.Now} 後臺測試服務,準備進行資源清理!"); 10 11 cts.Cancel(); //設置IsCancellationRequested=true,讓TestService今早結束 12 bgtask.Wait(); //等待 testService 結束執行 13 14 Console.WriteLine($"{DateTime.Now} 恭喜,Test服務程序已正常退出!"); 15 16 Environment.Exit(0); 17 }; 18 19 Console.WriteLine($"{DateTime.Now} 後端服務程序正常啓動!"); 20 21 bgtask.Wait(); 22 }
Main函數中作了如上的變動,將CancellationToken傳遞給 Run方法,這樣當我執行Cancel的時候,Run方法就能感知到Token的變化,而後就是調用Wait等待
TestService執行結束。
2. TestService
1 public class TestService 2 { 3 public static void Run(CancellationToken token) 4 { 5 while (true) 6 { 7 if (token.IsCancellationRequested) break; 8 9 Console.WriteLine($"{DateTime.Now}: 1. 獲取mysql"); 10 System.Threading.Thread.Sleep(2000); 11 Console.WriteLine($"{DateTime.Now}: 2. 獲取redis"); 12 System.Threading.Thread.Sleep(2000); 13 Console.WriteLine($"{DateTime.Now}: 3. 更新monogdb"); 14 System.Threading.Thread.Sleep(2000); 15 Console.WriteLine($"{DateTime.Now}: 4. 通知kafka"); 16 System.Threading.Thread.Sleep(2000); 17 Console.WriteLine($"{DateTime.Now}: 5. 全部業務處理完畢"); 18 System.Threading.Thread.Sleep(2000); 19 } 20 } 21 }
TestService的while循環裏面,在週期輪訓的開頭,加上一個IsCancellationRequested的判斷,若是Cancel()方法被調用,IsCancellationRequested就會變
成true,從而讓本方法感知到外界讓我結束,因此本邏輯就再也不進行下一個週期了,從而保證業務邏輯的完整。
五:部署
爲了更好的表達效果,我加了不少的日誌,仍是採用nohup的模式來觀察一下程序的流轉過程。
1 [root@localhost netcore]# nohup dotnet ConsoleApp1.dll & 2 [2] 4487 3 [root@localhost netcore]# nohup: ignoring input and appending output to ‘nohup.out’ 4 5 [root@localhost netcore]# ps -ef | grep dotnet 6 root 4487 2865 1 17:11 pts/0 00:00:00 dotnet ConsoleApp1.dll 7 root 4496 2865 0 17:11 pts/0 00:00:00 grep --color=auto dotnet 8 [1]- Done nohup dotnet ConsoleApp1.dll 9 [root@localhost netcore]# kill 4487 10 [root@localhost netcore]# tail -100 nohup.out 11 9/2/18 5:11:17 PM: 1. 獲取mysql 12 9/2/18 5:11:17 PM 後端服務程序正常啓動! 13 9/2/18 5:11:19 PM: 2. 獲取redis 14 9/2/18 5:11:21 PM: 3. 更新monogdb 15 9/2/18 5:11:23 PM: 4. 通知kafka 16 9/2/18 5:11:25 PM: 5. 全部業務處理完畢 17 9/2/18 5:11:27 PM: 1. 獲取mysql 18 9/2/18 5:11:29 PM: 2. 獲取redis 19 9/2/18 5:11:31 PM: 3. 更新monogdb 20 9/2/18 5:11:33 PM: 4. 通知kafka 21 9/2/18 5:11:35 PM: 5. 全部業務處理完畢 22 9/2/18 5:11:37 PM: 1. 獲取mysql 23 9/2/18 5:11:39 PM: 2. 獲取redis 24 9/2/18 5:11:41 PM: 3. 更新monogdb 25 9/2/18 5:11:43 PM: 4. 通知kafka 26 9/2/18 5:11:45 PM: 5. 全部業務處理完畢 27 9/2/18 5:11:47 PM: 1. 獲取mysql 28 9/2/18 5:11:49 PM: 2. 獲取redis 29 9/2/18 5:11:50 PM 後臺測試服務,準備進行資源清理! 30 9/2/18 5:11:51 PM: 3. 更新monogdb 31 9/2/18 5:11:53 PM: 4. 通知kafka 32 9/2/18 5:11:55 PM: 5. 全部業務處理完畢 33 9/2/18 5:11:57 PM 恭喜,Test服務程序已正常退出!
你們能夠清楚的看到,5:11:49 收到了system給過來的kill通知,可是程序仍是等到了5:11:57才真正的結束本身,這樣是否是就保證了業務流程免遭破壞呢?
好了,本篇就說到這裏,但願對你有幫助。