netcore服务程序暴力退出导致的业务数据不一致的一种解决方案(优雅退出)
一: 问题提出
现如今大家写的netcore程序大多部署在linux平台上,而且服务程序里面可能会做各种复杂的操作,涉及到多数据源(mysql,redis,kafka)。成功部署成后台
进程之后,你以为这样就万事大吉了? 却不知当你更新代码时,暴力的kill掉这个进程导致你的业务出现数据不一致,业务流程被破坏等等问题。比如下面这段代码:
1. testservice
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方法出现未执行完的情况,导致数据不一致,比如下
面我简单的部署了一下,可以看到程序到了 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 命令
要解决这个问题,大家一定要从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才真正的结束自己,这样是不是就保证了业务流程免遭破坏呢?
好了,本篇就说到这里,希望对你有帮助。