• 一、背景

  • 1.为什么要做风控?

  • 2.为什么要自己写风控?

  • 3.其它要求

• 二、思路

  • 1.风控规则的实现

  • 2.调用方式的实现

• 三、具体实现

  • 1.风控计数规则实现

  • 2.注解的实现

• 四、测试一下

  • 1.写法

  • 2.Debug看看

一、背景

1.为什么要做风控?

 

这不得拜产品大佬所赐，我们的业务目前广泛使用了各种人工智能能力，如OCR识别、语音测评等。这些先进的能力往往需要大量资金和资源来支持，因此我们在产品层面也希望对用户的使用次数进行一定的限制。为了保护我们的业务和客户，风控措施是必不可少的。我们还在不断努力研究和开发新的AI技术，以提高我们的能力和服务质量，同时也在积极寻求更多的资金和资源，以满足业务的不断发展和扩张。我们坚信，只有不断创新和努力，才能为客户提供更好的服务和体验，同时也为我们的企业带来更大的发展和成功。 

2.为什么要自己写风控?

那么多开源的风控组件,为什么还要写呢?是不是想重复发明轮子呀.

 

要想回答这个问题,需要先解释下我们业务需要用到的风控(简称业务风控),与开源常见的风控(简称普通风控)有何区别: 

因此,直接使用开源的普通风控,一般情况下是无法满足需求的

3.其它要求 

支持实时调整限制

很多限制值在首次设置的时候,基本上都是拍定的一个值,后续需要调整的可能性是比较大的,因此可调整并实时生效是必须的

 

二、思路 

要实现一个简单的业务风控组件,要做什么工作呢?

1.风控规则的实现

a.需要实现的规则:

• 自然日计数

• 自然小时计数

• 自然日+自然小时计数

自然日+自然小时计数 这里并不能单纯地串联两个判断,因为如果自然日的判定通过,而自然小时的判定不通过的时候,需要回退,自然日跟自然小时都不能计入本次调用!

b.计数方式的选择:

目前能想到的会有:

• mysql+db事务 持久化、记录可溯源、实现起来比较麻烦,稍微“重”了一点

• redis+lua 实现简单,redis的可执行lua脚本的特性也能满足对“事务”的要求

• mysql/redis+分布式事务 需要上锁,实现复杂,能做到比较精确的计数,也就是真正等到代码块执行成功之后,再去操作计数

目前没有很精确技术的要求,代价太大,也没有持久化的需求,因此选用 redis+lua 即可

2.调用方式的实现

a.常见的做法 先定义一个通用的入口

 

在service中调用该方法 

在编写代码的过程中，我们时常会寻求更优雅的实现方式。对于传入的 content 参数，由于它与业务有关，因此我们需要使用 SpEL（Spring Expression Language）来将参数构建成相应的 content。但是我们可以考虑使用注解的方式来实现，这样可以更好地将参数与业务逻辑分离开。当然，这种做法也有一些争议，需要根据具体情况来决定是否使用。

 

三、具体实现

1.风控计数规则实现

a.自然日/自然小时

自然日/自然小时可以共用一套lua脚本,因为它们只有key不同,脚本如下:

 

在这个函数中，KEYS[1] 是与日/小时相关的键，ARGV[1] 是上限值，ARGV[2] 是过期时间。该函数返回当前计数值加 1 后的结果。如果已经达到上限，则实际上不会计数。通过该函数，我们可以轻松地跟踪某个特定时间段内的操作次数。例如，我们可以使用这个函数来记录我们网站的每日或每小时访问量，以便更好地了解网站流量的变化趋势。

b.自然日+自然小时 如前文提到的,两个的结合实际上并不是单纯的拼凑,需要处理回退逻辑

在此代码中，KEYS[1]是由天生成的关联密钥，KEYS[2]是由小时生成的关联密钥。ARGV[1]表示天的最大值，ARGV[2]表示小时的最大值，ARGV[3]表示天的过期时间，ARGV[4]表示小时的过期时间。函数返回与上述代码相同的值。

需要注意的是，虽然上述代码粗略地表达了其意图，但是可以进一步完善以增强其可读性。具体而言，当两个条件判断中有一个未能满足时，另一个条件也需要回滚。因此，可以进一步解释该代码的逻辑，并增加注释以使其更易于理解。

2.注解的实现 

a.定义一个@Detect注解

 

其中content是需要经过表达式解析出来的,所以接受的是个String

b.定义@Detect注解的处理类

需要将参数放入到上下文中,并起名为arg1、arg2....

四、测试一下

1.写法

使用注解之后的写法:

 

2.Debug看看 

 

• 注解值获取成功

• 表达式解析成功