029_尚硅谷大数据技术_用户行为数据分析Flink项目_恶意登录检测（三）_代码时效性改进

你已经把这个恶意登录监控的这一部分代码做了一个简单实现，大家会发现最后的功能是实现了，呃，确实是检测到842~844之间连续三次登录失败，但是其实大家发现这个代码我们在实现的过程当中有一点问题，就是比方说这里842 843 844连续三次登录失败，你看他其实是842的时候注册了一个两秒之后的定时器，然后是不是他就在那儿愣等着呀，一直等对吧？哎，等到843来了之后，他。这个根本不会触发任何的报警，他是要一直等，等到两秒钟到时间，然后才会做一个判断，结果发现我们这里边连续有三次登录失败了，对吧？啊，超过了这个上限，所以在这个过程当中，大家会发现我们现在检测这个连续登陆失败，这个两秒钟其实并不像之前我们说的这个十秒之内温度连续上升，它就是要呃，对这个温度的变化要有一个时间范围，而我们这里边的两两秒钟限制其实是。

我们是希望他尽快的检测到对吧，是希望这个连续登录失败的事件不要发生超过两秒钟之外就可以了，那你说像这里842843，这是不是连续两次登录失败呢。那在这种情况下，我是一定要等到两秒之后才去报警，还是说检测到现在这个这842843是在两秒钟之内，对吧？呃，那那然后他是两次登录失败，是不是就应该直接报警了呢。诶，所以大家会想到从这个时效性上去考虑的话，这里边其实我们应该做一个改进，就是你不要愣等对吧，等等到这个两秒钟之后才去做这个触发计算，你这个时效性就太差了嘛，我们说实际如果说遇到这个黑客攻击的话，很可能一秒钟之内它就可以尝试，呃，就是几十次上百次的这个登登陆的这种尝试，对吧？哎，那我们这里边如果说你是一定要等到两秒之后才出发，这显然就呃有可能就已经被他破解了，破解了破译了，而且这里边还有另外一个更加严重的问题，就哪怕说诶就是后边，呃，大家大家可能会想到啊，就哪怕说我这里边是等到两秒钟之后，如果说要能触发能够报警也算的，那他想如果出现破译的那种状况的话，是不是他可能在两秒钟之内尝试了100多次，200多次，然后在中间的某个时间点是不是直接就登录成功了呀？那大家想按照我们的逻辑，登录成功之后会怎么样，是不是直接清空定时定时器？

直接状态都清空不报警了呀，所以他那大家看我们看到最后效果是不是什么都没有啊，对吧，这破解了之后，我们也根本检测不出来，所以这个在代码逻辑上其实是有问题的，所以接下来我们希望做一个改进，那大家想我们现在的这个改进思路是什么呢？那我们发现对现在是不是就不要按照这个注册定时器两秒钟之后再去做判断了，对吧？这里边我们是注册了一个两秒之后的定时器，呃，到这个onheim才去判断，那我们现在是不是就完全干脆就完全按照事件触发来一个数据，我是不是直接就判断他跟前一次，前一次如果是登录失败的话，我就判断前一次他俩之间的时间戳是不是在两秒范围内，对吧？如果在两秒范围内，那就不用什么定时器直接触发报警对吧？啊，如果是两秒范围之外的话，那相当于诶之前那个数据两秒之内没有继续登录失败了，那就作废，那接下来我以新的这个数据作为新的登录失败的计计算的起点，对吧？接下来继续等就可以了，所以我们这里边的一个简单的思路就是，诶，那我就把这个。

这里啊，大家看到这个on timer和这里的这个process element这个代码是不是就相当于我需要重新重写一下呀？啊，我把这个直接注掉。呃，那关于前面的这个状态的定义，大家可能会发现这个应该也还差不多对吧？啊，比方说这里边我还有一个最大的这个登录失败的次数，然后呢，之前我所有就是已经这个登录失败的事件，我还是先保存到一个呃，当前的这个list state里，当然了，这里边也就不需要再有这个定时器时间戳了，对吧？呃，这个就不需要有了啊，那在open生命周期里边也就去掉，去掉了这个定时器时间戳这个定义啊，那那如果这么麻烦的话，有同学可能想到我何必这么麻烦呢，我干脆重新写一下得了，对吧？啊，那在这个重新实现的这个K的process function里边，我可以把前面的这一部分open截止到open生生命周期这一部分我全部copy下来，在下边我们单独的再做一个实现，当然了，上边这个我可以重新做一个定义啊，就之前我们前面实现的这个自定义的process function，我把它叫做。

Log detect warning，呃，我把可以把它叫做零对吧，然后下边这个给一个零。

然后上面我们这里边传的是logging field detect warning，所以下边这才是真正的这个实现啊，那这里边我们还是定义了一个最大连续登录失败的次数，呃，甚至大家想在这种场景下，呃，可能我这个连最大登陆失败次数这个用途都不大对吧？因为这个我们我们具体来讲，如果要是说你想判断这个登录失败几次的话，是不是应该在逻辑里边体现出来啊。是不是我们后边现在你就不是直接把它放到一个列表里边取有几次了嘛，那是不是后边就相当于是假如说我现在是连续登录失败三次的话，你不是是不是就得比对，之前是不是已经有了两次登录失败呀，对吧？那另外还有一种情况是之前已经有了一次登录失败，是不是我要继续把它添加进去，接下来再来登录失败的时候再去比对，对吧？哎，所以这里边其实主要就是做这个，这个起到这个作用啊，我们现在是只判断连续两次登录失败，其实比较简单，这个列表里面是不是我只存一个就可以了。

对吧，相当于就是类似于我们之前只存上一个上一个温度值啊，这里只存上一个登录失败就可以，呃，这个过程我还是不变了啊，就把这个都放在这儿，然后当前这个时间戳的定义都去掉，下边这里还少了一个这个。少了一个这个花括号对吧？呃，这是当前我们这个类本身啊，Logging field detect warning的花括号，然后下边必须还要实现一个process element方法，所以接下来我们的所有的代码的改进都是在process element方法里边来一个判断一次，来一个判断一次对吧？都在这里处理就可以了，大家想一下现在的这个逻辑啊啊，我我我们这里就是给大家在上面先写一下这个注释啊，啊，就是当前我们是以。

就是事件登录事件。作为判断报警的触发条件。不再注册定时器，所以接下来我们的逻辑就是各种判断，对吧？哎，那大家想这个要判断的是什么，判断的是不是就是当前到底是成功还是失败啊，对吧，判断当前事件。登录状态，首先我们还是这个逻辑啊，判断的就是是否是F对吧，如果是f equals，当前的value.get login state的话，这里边是第一种情况，大家想第一种情况其实就是我们所说的，如果是登录失败。

那么接下来大家会想到我是不是先得判断之前有没有登录失败啊，对吧，就是当前是一个登录失败，那之前有登录失败和没有登录失败是两种情况了，如果没有的话，我就直接把它添加进去就完事了，对吧？如果有的话，那是不是相当于我就直接要做判断要报警了呀啊，所以接下来是继续，呃，就是要获取状态中之前的登录失败事件。继续判断。呃，是否已有失败，失败事件，所以呃，这是我们的第一种情况，那其实就是在他并行的第二种情况里面是比较简单的，所以我们可以直接把它这个第二种情况写出来，大家想else的话，Else是不是成功啊，如果来了成功怎么办？如果是登录成功，对，那是不是直接清空状态就完事了呀？

现在也不存在定时器对吧，直接清空状态，等之后的那个登录失败事件再来再说就完事了，直接清空状态，所以这里边直接就是logging fair event list state，直接clear对吧，直接做这个，那前面这里稍微麻烦一点，我这里边是不是先得判断之前到底有没有啊啊，所以我判断那个的话，我先把那个迭代器拿到吧。之前我们那个它的get直接get之后不是可迭代类型吗？不是有这个迭代器吗？把这个迭代器先拿到，然后大家看这个判断是不是就是if。如果当前。呃，这个如果has next的话，这是一种情况，这就是我们说1.1的情况下，如果已经有登录失败事件，那是不是直接，呃，就是相当于要判断他们的这个呃对应的那个时间戳是不是在两秒之内啊对吧，继续判断时间戳是否在两秒之内，那对应的else。

这里边的这个1.2的这种成情形，那其实就是对，如果如果没有登录失败，那是不是直接把当前的这个事件存进去就完事了，对吧，直接将当前事件存入列表状态list state啊这个也非常简单，Logging film list state直接ADD当前的这个value value进来，对吧。好，所以现在最复杂的逻辑应该是在这个1.1这个判断里面。

如果当前已经有的话，那我们首先把当前这个是不是先拿到啊，对吧，获取。已有的登录失败事件，现在我们的逻辑比较简单，因为我确定现在，因为我只判断连续两次登录失败嘛，那假如有的话，是不是里边肯定是只有一个呀，哎，那在想如果说我的这个逻辑要是复杂一点的话，我要判断连续三次登录失败，那是不是里边就有可能有两种情况，一种是有两个，一种是有一个，是不是又得分开判断了啊，所以现在这个比较简单啊，我们只判断有，那就是只有一个直接拿出来完事了，这个类型叫logging event，对吧，这个我叫first fill event，那就是interator迭代器，直接nes拿到就完事，对吧？呃，接下来那就是要做if判断了，继续做判断，我们判断的是如果当前的value，它的时间戳减掉first few event，它的时间戳如果要在两秒之内小于等。

等于二的话，那接下来是不是就要做一个报警啊，哎，所以接下来这里边我们判断的啊，这个这个应该叫1.1.1对吧。这个是如果在两秒之内，那是不是直接输出报警啊，out.collect因为我们现在的输出的数据类型不就是那个warning吗？哎，所以直接你有一个logging field warning，这里边我们要当前的user ID，然后要当前的第一次登录失败的时间戳，最后一次登录失败时间戳还有一个报警信息啊，那这个非常明显了，有value嘛，那我也不用那个获取当前key了，是吧？我直接get user ID是不是就可以了，然后第一次登录失败的时间戳first few event get time s拿出来，然后另外最后一次是不是就是当前这个value的time呀，拿出来对吧？后面再来一个报警信息，这个大家知道就是logging feel是不是？呃，两次对吧？Two times在两秒钟之内啊，这个就是非常明确的，肯定就是两。

两次了直接输出，然后大家想，那如果说要是啊，就是这里边我输出了，那大家想是不是接下来还应该把这个状态直接清空掉，然后重新开始进行处理啊，那我们可能还考虑到一点，就是假如说你是两次连续登录失败，那我把当前其实是只需要怎么样。只需要清掉最初的那一次登录失败，现在最新的这个登录失败是不是还可以保存进去，再作为下一次判断的起点啊，诶，所以这个就看我们逻辑具体怎么定义了啊，如果是这么定义的话，那我就清掉状态，然后把当前的这个最新的value再保存进去，是不是就完事了啊啊那另外大家想，如果这个是说的我这个叔叔报警啊，那如果要是不在两秒钟之内呢？

那是不是就是不输出报警，但是是不是相当于也要有这个把状态更新的这个过程啊，哎，所以这里边我干脆就把这个直接提提炼到外边来啊，这个另外的这个分支1.1.2就没了，是吧？啊，干脆就什么都不做，所以这里边提炼到外边，我们说不管报不报警，是不是这次都已处理完毕，我们可以就是直接更新状态，当然这里的更新状态我们本来是list set吧，列表状态，你可以先把当前最新的那个value，把它放在一个a list里边，然后直接那个update对吧？呃，直接把之前的那个list state做一个做一个update操作，或者呢，其实大家知道有更简单的方式怎么做。

是不是直接把logging state先做一个清空，然后是不是在在ADD当前这个value进去就可以了呀，这是不是也相当于一个update啊啊，对吧，这个我们写起来稍微简单一点，不用再包装那个呃a release了啊啊，这就是整个这个处理流程啊，大家看这个过程其实就是每来一个数据直接就做一个判断，根据之前的状态去做一个判断，这里边我们判断的只是连续两次登录失败，所以说呃，逻辑尽管稍微的有一点绕，但是大家把这个if else分支条件都搞清楚的话，还是比较清晰的。但是其实大家能想到，呃，如果要是三次登录失败的话，我这个怎么该怎么判断了，那是不是就是这里边如果当前就是有数据的话，是一种处理对吧？呃，没有数据的话，就是直接把这个当前添加进去，如果有数据的话，是不是还得判断到底是有一个还是两个。对吧？如果要是有两个的话，是不是现在第三个登录失败来了，就可以直接判断这个时间戳在都在和第一个登录失败的那个判断，如果是时间出在两秒之内的话，那接下来是不是直接输出报警啊，那假假如说是之前只有一个的话，那是不是现在相当于只有两次登录失败还不报警对吧？啊，但是是不是也得判断时间戳是不是在两秒钟之内啊，如果已经超出了两秒钟范围，是不是也得更新状态了？哎，所以这个就逻辑就复杂很多了啊，就如果要是说呃，这个判断的次数更多的话，这里面的if else就会多很多逻辑，而且大家会发现之前我们那个代码这个扩展好像很简单粗暴，你如果要是判断三次登陆失败，是不是直接我把这个改一个就可以了，但现在不行，现在你如果要是这么给的话。

大家其实想到我这儿这个二传进来是不是其实没什么用啊，我是逻辑里边的逻辑是不是已经写死了。一定就是只判断两个对吧，哎，所以这个二其实就没起到作用，那如果说这里边变成三的话，那里边的整段逻辑我们都得改啊，这是当前这个代码的一个，也是一个缺陷吧，然后我们先看一下当前它的这个测试结果是什么样的啊。

还是我们当前那个数据，大家再重新测一下，呃，上边我们这个还是logging field detect warning对吧？呃，现在我们是换用了重新定义的这样的一个process element啊，直接就是以事件出发。看一下计算的结果。大家看到这里输出的结果，现在是不是就变成了对两次报警了，他只要检测到842843，诶两次登录失败，他是不是直接就报警了，然后后面我们当时不是这个已经报警之后是要更新吗？那是不是接下来这个状态里面就变成八十四八四三了，然后843和844是不是又是一次报警啊，所以大家看这样的话就比较符合我们的预期，就是你不要管它，呃，这个到没到两秒，只要检测到，然后它发生的时间是在两秒之内，你就马上报警，对吧，立即报警，这个时效性就会更好一点，这是我们对于之前的那个代码的一个，呃，时效性上的改进。