服务程序暴力退出导致的业务数据不一致

netcore服务程序暴力退出导致的业务数据不一致的一种解决方案（优雅退出）

https://www.cnblogs.com/huangxincheng/p/9576795.html

一： 问题提出

　　现如今大家写的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 （退出）

4. SIGKILL (强制终止）

5. 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才真正的结束自己，这样是不是就保证了业务流程免遭破坏呢？

好了，本篇就说到这里，希望对你有帮助。