第一回合
最开始大概是半个月前，我突然发现我的百度云服务器上的MySQL连接不上。
但是前一晚还用了。因此可以确定不是账号密码，以及服务器上设置的问题。
于是乎，就登陆到云服务器上，准备去查看一下mysql的运行情况。然后突然敲命令也很卡，感觉可能系统响应太慢了，用t o p toptop指令去看下
（上面这个图是我第三回合排查的时候截的图，前面两个回合都没有注意，所以没有截图。）
当我看到这个的时候，吓了一跳。怎么突然有个进程占用了那么多的CPU资源，导致CPU几乎没有其他的处理能力了。
于是二话不说，看到这个kwsapd0进程对应的pid，一上来就直接用kill -9 972902给干掉了。
然后重新用top命令查看了一下，突然发现释放了很多资源。CPU占有率也不高了，沾沾自喜还以为成功了。
结果没想到，过了几天后，又是这个进程继续出现这种情况，开始有点怀疑了，这个进程为啥每次都会占用CPU资源如此多呢？
于是乎，开始了我第二回合的斗智斗勇。
第二回合
第二回合：
我一开始想的是为啥每次都是同一个进程出现的这种情况呢？于是我开始去百度，想看下这个进程到底是啥？
于是百度看到了这篇博客，感觉突然找到了共鸣的地方。https://blog.csdn.net/jzz601264258/article/details/105850816
看着这篇博客
我就知道，看来有不少人都遇到过同样的情况。于是乎，我就按照博主的操作，先用
netstat -antlp
命令筛选出来，结果也发现了也是45.9.148.125和45.9.148.99 两个ip,对应的进程名也是kswapd0和
rsync。
这里补充一点：
kswapd0进程：它是虚拟内存管理中, 负责换页的， 操作系统每过一定时间就会唤醒kswapd ，看看内存是否紧张，如果不紧张，则睡眠，在 kswapd 中，有2 个阀值, pages_hige和pages_low,当空闲内存页的数量低于 pages_low 的时候, kswapd进程就会扫描内存并且每次释放出32 个free pages,直到 free page 的数量到达pages_high。rsync进程：rsync 是一个常用的 Linux 应用程序，用于文件同步。它可以在本地计算机与远程计算机之间，或者两个本地目录之间同步文件（但不支持两台远程计算机之间的同步）。它也可以当作文件复制工具，替代cp和mv命令。它名称里面的r指的是 remote，rsync 其实就是"远程同步"（remote sync）的意思。与其他文件传输工具（如 FTP 或 scp）不同，rsync 的最大特点是会检查发送方和接收方已有的文件，仅传输有变动的部分（默认规则是文件大小或修改时间有变动）。
大概就知道可能是在一直传输数据。
而且我还特地去 https://www.ip138.com/ 这里验证了一下，这两个ip到底是不是上面那篇博主说的荷兰的ip地址，结果一查还真的发现是，于是我觉得上面那篇博客已经写的足够详细了，等会按照那篇博客去操作应该就没事了。
接下来我继续一步一步按照博主的操作，把这两个进程都kill掉了。而且清空了对应的文件夹的脚本文件。
但此时因为我看这个应用对应的用户是dev，我突然想到我的dev用户的密码就是123456。当时纯属省心，没有想到还真的会有人去试这些东西。我就立马用
su dev
切换到dev用户。
紧接着我用
sudo passwd
修改dev用户的密码。
并且我看这个IP和那篇博客帖子里的IP一模一样，我就想着把这个ip添加进黑名单。
参考了这篇博客https://blog.csdn.net/lck_csdn/article/details/116499017 ，终于把45.9.148.125和45.9.148.99添加进了黑名单。
然后再用top命令去查看，发现CPU使用率正常了。
第三回合
今天，我在准备去登陆服务器启动kafka的时候，结果突然又用top命令看到和之前一样的情况。我内心想：“我不是已经改了账号和密码了吗？为啥对方还一直可以登陆到我的服务器？”一脸懵！！！
于是开启了第三回合的斗智斗勇。
1. 首先还是用top命令去查看
2.查看对应IP的通信进程
第一次的时候，我用
netstat -antlp | grep 45.9.148.125
结果如下图展示的一样
竟然那个ip没有进行通信了？难道是另外的人搞的？
于是乎，我根据上次的两个不同的IP特征，想着用正则表达式筛一遍。
netstat -antlp | grep 45.9.148.*
果不其然，还是那个荷兰IP45.9.148.125同网关的另外两个IP45.9.148.99和45.9.148.129
3.去看这两个进程是由哪两个脚本文件运行生成的
紧接着，我打算去看下这两个进程到底是在哪个路径下的程序运行的
ls -al /proc/972895/exe ls -al /proc/972902/exe
分别查看了一下
然后发现972902进程号也就是kswapd0进程是/home/dev/.configrc/a/kswapd0这个脚本执行的。
先去到/home/dev路径下
ll -al
查看这个路径下有哪些文件和目录
于是我继续往下去查看
cd .configrc/ ll -al
当我看到cron.d的时候，我突然明白了定时任务，似乎知道为什么每次我清理掉对方的进程之后，过几天还是会出现类似的情况。
我就迫不及待的想打开这个文件，查看里面的脚本到底是定时执行啥任务
cat cron.d
1 1 */2 * * /home/dev/.configrc/a/upd>/dev/null 2>&1 @reboot /home/dev/.configrc/a/upd>/dev/null 2>&1 5 8 * * 0 /home/dev/.configrc/b/sync>/dev/null 2>&1 @reboot /home/dev/.configrc/b/sync>/dev/null 2>&1 0 0 */3 * * /dev/shm/.X1129/.rsync/c/aptitude>/dev/null 2>&1
就是一个这样的脚本文件。
这里补充几个知识点：
- cron规则表达式
5位Cron代表的结构
# 文件格式說明 # ——分钟（0 - 59） # | ——小时（0 - 23） # | | ——日（1 - 31） # | | | ——月（1 - 12） # | | | | ——星期（0 - 7，星期日=0或7） # | | | | | # * * * * * 被執行的命令
2. >dev/null 2>&1
>/dev/null 2>&1的作用就是让标准输出重定向到/dev/null中（丢弃标准输出），然后错误输出由于重用了标准输出的描述符，所以错误输出也被定向到了/dev/null中，错误输出同样也被丢弃了。执行了这条命令之后，该条shell命令将不会输出任何信息到控制台，也不会有任何信息输出到文件中。
第一行：每个月每个星期每隔2每隔1小时零1分钟开始执行/home/dev/.configrc/a路径下的upd脚本
第二行：重启电脑之后开始执行/home/dev/.configrc/a路径下的upd脚本不打印任何信息
第三行：每个月的每个周日每隔8小时零5分钟开始执行/home/dev/.configrc/b路径下的sync脚本
第四行：重启电脑之后开始执行/home/dev/.configrc/b路径下的sync脚本
第五行：每个月每个星期每隔3天每时每分执行/dev/shm/.X1129/.rsync/c/路径下的aptitude脚本
那么接下来我会去看
/home/dev/.configrc/a路径下的upd文件/home/dev/.configrc/b路径下的sync文件/dev/shm/.X1129/.rsync/c/路径下的aptitude文件
