一： 问题提出
现如今大家写的netcore程序大多部署在linux平台上，而且服务程序里面可能会做各种复杂的操作，涉及到多数据源（mysql，redis，kafka）。成功部署成后台
进程之后，你以为这样就万事大吉了？ 却不知当你更新代码时，暴力的kill掉这个进程导致你的业务出现数据不一致，业务流程被破坏等等问题。比如下面这段代码：
1. TestService
public class TestService
{
public static void Run()
{
while (true)
{
Console.WriteLine($"{DateTime.Now}: 1. 获取mysql");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 2. 获取redis");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 3. 更新monogdb");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 4. 通知kafka");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 5. 所有业务处理完毕");
System.Threading.Thread.Sleep();
}
}
}
2. Main程序
public static void Main(string[] args)
{
var bgtask = Task.Run(() => { TestService.Run(); }); bgtask.Wait();
}
这里不考虑程序的健壮性，只表达这里可能出现的问题，当程序退出后，这里必然会遇到TestService.Run方法出现未执行完的情况，导致数据不一致，比如下
面我简单的部署了一下，可以看到程序到了 5:03:24s之后就结束了，显然破坏了业务逻辑。程序没有完整的执行结束，那问题该怎么解决呢？
[root@localhost netcore]# nohup dotnet ConsoleApp4.dll &
[]
[root@localhost netcore]# nohup: ignoring input and appending output to ‘nohup.out’ [root@localhost netcore]# ps -ef | grep dotnet
root : pts/ :: dotnet ConsoleApp4.dll
root : pts/ :: grep --color=auto dotnet
[root@localhost netcore]# kill
[root@localhost netcore]# tail nohup.out
// :: PM: . 获取redis
// :: PM: . 更新monogdb
// :: PM: . 通知kafka
// :: PM: . 所有业务处理完毕
// :: PM: . 获取mysql
// :: PM: . 获取redis
// :: PM: . 更新monogdb
// :: PM: . 通知kafka
// :: PM: . 所有业务处理完毕
// :: PM: . 获取mysql
[]+ Done nohup dotnet ConsoleApp4.dll
[root@localhost netcore]#
二：思考 kill 命令
要解决这个问题，大家一定要从kill命令入手， 在centos上进行kill -x pid 的时候，不知道有多少人了解了这个命令，除了常见的 kill -9 pid ，其实还有很多其
他的数字，则代表其他的意思，可以通过kill -l 看一下。
[root@localhost ~]# kill -l
) SIGHUP ) SIGINT ) SIGQUIT ) SIGILL ) SIGTRAP
) SIGABRT ) SIGBUS ) SIGFPE ) SIGKILL ) SIGUSR1
) SIGSEGV ) SIGUSR2 ) SIGPIPE ) SIGALRM ) SIGTERM
) SIGSTKFLT ) SIGCHLD ) SIGCONT ) SIGSTOP ) SIGTSTP
) SIGTTIN ) SIGTTOU ) SIGURG ) SIGXCPU ) SIGXFSZ
) SIGVTALRM ) SIGPROF ) SIGWINCH ) SIGIO ) SIGPWR
) SIGSYS ) SIGRTMIN ) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+
) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+
) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMIN+
) SIGRTMIN+ ) SIGRTMIN+ ) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX-
) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX-
) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX- ) SIGRTMAX-
) SIGRTMAX- ) 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函数
public static void Main(string[] args)
{
var cts = new CancellationTokenSource(); var bgtask = Task.Run(() => { TestService.Run(cts.Token); }); AppDomain.CurrentDomain.ProcessExit += (s, e) =>
{
Console.WriteLine($"{DateTime.Now} 后台测试服务，准备进行资源清理！"); cts.Cancel(); //设置IsCancellationRequested=true，让TestService今早结束
bgtask.Wait(); //等待 testService 结束执行 Console.WriteLine($"{DateTime.Now} 恭喜，Test服务程序已正常退出！"); Environment.Exit();
}; Console.WriteLine($"{DateTime.Now} 后端服务程序正常启动！"); bgtask.Wait();
}
Main函数中做了如上的变更，将CancellationToken传递给 Run方法，这样当我执行Cancel的时候，Run方法就能感知到Token的变化，然后就是调用Wait等待
TestService执行结束。
2. TestService
public class TestService
{
public static void Run(CancellationToken token)
{
while (true)
{
if (token.IsCancellationRequested) break; Console.WriteLine($"{DateTime.Now}: 1. 获取mysql");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 2. 获取redis");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 3. 更新monogdb");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 4. 通知kafka");
System.Threading.Thread.Sleep();
Console.WriteLine($"{DateTime.Now}: 5. 所有业务处理完毕");
System.Threading.Thread.Sleep();
}
}
}
TestService的while循环里面，在周期轮训的开头，加上一个IsCancellationRequested的判断，如果Cancel()方法被调用，IsCancellationRequested就会变
成true，从而让本方法感知到外界让我结束，所以本逻辑就不再进行下一个周期了，从而保证业务逻辑的完整。
五：部署
为了更好的表达效果，我加了很多的日志，还是采用nohup的模式来观察一下程序的流转过程。
[root@localhost netcore]# nohup dotnet ConsoleApp1.dll &
[]
[root@localhost netcore]# nohup: ignoring input and appending output to ‘nohup.out’ [root@localhost netcore]# ps -ef | grep dotnet
root : pts/ :: dotnet ConsoleApp1.dll
root : pts/ :: grep --color=auto dotnet
[]- Done nohup dotnet ConsoleApp1.dll
[root@localhost netcore]# kill
[root@localhost netcore]# tail - nohup.out
// :: PM: . 获取mysql
// :: PM 后端服务程序正常启动！
// :: PM: . 获取redis
// :: PM: . 更新monogdb
// :: PM: . 通知kafka
// :: PM: . 所有业务处理完毕
// :: PM: . 获取mysql
// :: PM: . 获取redis
// :: PM: . 更新monogdb
// :: PM: . 通知kafka
// :: PM: . 所有业务处理完毕
// :: PM: . 获取mysql
// :: PM: . 获取redis
// :: PM: . 更新monogdb
// :: PM: . 通知kafka
// :: PM: . 所有业务处理完毕
// :: PM: . 获取mysql
// :: PM: . 获取redis
// :: PM 后台测试服务，准备进行资源清理！
// :: PM: . 更新monogdb
// :: PM: . 通知kafka
// :: PM: . 所有业务处理完毕
// :: PM 恭喜，Test服务程序已正常退出！
大家可以清楚的看到，5:11:49 收到了system给过来的kill通知，但是程序还是等到了5:11:57才真正的结束自己，这样是不是就保证了业务流程免遭破坏呢？
好了，本篇就说到这里，希望对你有帮助。