优雅的接口防刷处理方案

前言

本文为描述通过Interceptor以及Redis实现接口访问防刷Demo

这里会通过逐步找问题，逐步去完善的形式展示

原理

  • 通过ip地址+uri拼接用以作为访问者访问接口区分

  • 通过在Interceptor中拦截请求，从Redis中统计用户访问接口次数从而达到接口防刷目的

如下图所示

工程

项目地址：

https://github.com/Tonciy/interface-brush-protection

其中，Interceptor处代码处理逻辑最为重要

/**
 * @author: Zero
 * @time: 2023/2/14
 * @description: 接口防刷拦截处理
 */
@Slf4j
public class AccessLimintInterceptor  implements HandlerInterceptor {
    @Resource
    private RedisTemplate<String, Object> redisTemplate;

    /**
     * 多长时间内
     */
    @Value("${interfaceAccess.second}")
    private Long second = 10L;

    /**
     * 访问次数
     */
    @Value("${interfaceAccess.time}")
    private Long time = 3L;

    /**
     * 禁用时长--单位/秒
     */
    @Value("${interfaceAccess.lockTime}")
    private Long lockTime = 60L;

    /**
     * 锁住时的key前缀
     */
    public static final String LOCK_PREFIX = "LOCK";

    /**
     * 统计次数时的key前缀
     */
    public static final String COUNT_PREFIX = "COUNT";


    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        String uri = request.getRequestURI();
        String ip = request.getRemoteAddr(); // 这里忽略代理软件方式访问，默认直接访问，也就是获取得到的就是访问者真实ip地址
        String lockKey = LOCK_PREFIX + ip + uri;
        Object isLock = redisTemplate.opsForValue().get(lockKey);
        if(Objects.isNull(isLock)){
            // 还未被禁用
            String countKey = COUNT_PREFIX + ip + uri;
            Object count = redisTemplate.opsForValue().get(countKey);
            if(Objects.isNull(count)){
                // 首次访问
                log.info("首次访问");
                redisTemplate.opsForValue().set(countKey,1,second, TimeUnit.SECONDS);
            }else{
                // 此用户前一点时间就访问过该接口
                if((Integer)count < time){
                    // 放行，访问次数 + 1
                    redisTemplate.opsForValue().increment(countKey);
                }else{
                    log.info("{}禁用访问{}",ip, uri);
                    // 禁用
                    redisTemplate.opsForValue().set(lockKey, 1,lockTime, TimeUnit.SECONDS);
                    // 删除统计
                    redisTemplate.delete(countKey);
                    throw new CommonException(ResultCode.ACCESS_FREQUENT);
                }
            }
        }else{
            // 此用户访问此接口已被禁用
            throw new CommonException(ResultCode.ACCESS_FREQUENT);
        }
        return true;
    }
}

在多长时间内访问接口多少次，以及禁用的时长，则是通过与配置文件配合动态设置

当处于禁用时直接抛异常则是通过在ControllerAdvice处统一处理 （这里代码写的有点丑陋）

下面是一些测试（可以把项目通过Git还原到“【初始化】”状态进行测试）

  • 正常访问时

  • 访问次数过于频繁时

 

自我提问

上述实现就好像就已经达到了我们的接口防刷目的了

但是，还不够

为方便后续描述，项目中新增补充Controller，如下所示

简单来说就是

  • PassCotroller和RefuseController

  • 每个Controller分别有对应的get，post，put，delete类型的方法，其映射路径与方法名称一致

接口自由

  • 对于上述实现，不知道你们有没有发现一个问题

  • 就是现在我们的接口防刷处理，针对是所有的接口（项目案例中我只是写的接口比较少）

  • 而在实际开发中，说对于所有的接口都要做防刷处理，感觉上也不太可能（写此文时目前大四，实际工作经验较少，这里不敢肯定）

  • 那么问题有了，该如何解决呢？目前来说想到两个解决方案

拦截器映射规则

项目通过Git还原到"【Interceptor设置映射规则实现接口自由】"版本即可得到此案例实现

我们都知道拦截器是可以设置拦截规则的，从而达到拦截处理目的

1.这个AccessInterfaceInterceptor是专门用来进行防刷处理的，那么实际上我们可以通过设置它的映射规则去匹配需要进行【接口防刷】的接口即可

2.比如说下面的映射配置

3.这样就初步达到了我们的目的，通过映射规则的配置，只针对那些需要进行【接口防刷】的接口才会进行处理

4.至于为啥说是初步呢？下面我就说说目前我想到的使用这种方式进行【接口防刷】的不足点：

所有要进行防刷处理的接口统一都是配置成了 x 秒内 y 次访问次数，禁用时长为 z 秒

  • 要知道就是要进行防刷处理的接口，其 x, y, z的值也是并不一定会统一的

  • 某些防刷接口处理比较消耗性能的，我就把x, y, z设置的紧一点

  • 而某些防刷接口处理相对来说比较快，我就把x, y, z 设置的松一点

  • 这没问题吧

  • 但是现在呢？x, y, z值全都一致了，这就不行了

  • 这就是其中一个不足点

  • 当然，其实针对当前这种情况也有解决方案

  • 那就是弄多个拦截器

  • 每个拦截器的【接口防刷】处理逻辑跟上述一致，并去映射对应要处理的防刷接口

  • 唯一不同的就是在每个拦截器内部，去修改对应防刷接口需要的x, y, z值

  • 这样就是感觉会比较麻烦

防刷接口映射路径修改后维护问题

  • 虽然说防刷接口的映射路径基本上定下来后就不会改变

  • 但实际上前后端联调开发项目时，不会有那么严谨的Api文档给我们用（这个在实习中倒是碰到过，公司不是很大，开发起来也就不那么严谨，啥都要自己搞，功能能实现就好）

  • 也就是说还是会有那种要修改接口的映射路径需求

  • 当防刷接口数量特别多，后面的接手人员就很痛苦了

  • 就算是项目是自己从0到1实现的，其实有时候项目开发到后面，自己也会忘记自己前面是如何设计的

  • 而使用当前这种方式的话，谁维护谁蛋疼

自定义注解 + 反射

咋说呢

  • 就是通过自定义注解中定义 x 秒内 y 次访问次数，禁用时长为 z 秒

  • 自定义注解 + 在需要进行防刷处理的各个接口方法上

  • 在拦截器中通过反射获取到各个接口中的x, y, z值即可达到我们想要的接口自由目的

下面做个实现

声明自定义注解

Controlller中方法中使用

Interceptor处逻辑修改（最重要是通过反射判断此接口是否需要进行防刷处理，以及获取到x, y, z的值）

/**
 * @author: Zero
 * @time: 2023/2/14
 * @description: 接口防刷拦截处理
 */
@Slf4j
public class AccessLimintInterceptor  implements HandlerInterceptor {
    @Resource
    private RedisTemplate<String, Object> redisTemplate;
    /**
     * 锁住时的key前缀
     */
    public static final String LOCK_PREFIX = "LOCK";

    /**
     * 统计次数时的key前缀
     */
    public static final String COUNT_PREFIX = "COUNT";


    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
//        自定义注解 + 反射 实现
        // 判断访问的是否是接口方法
        if(handler instanceof HandlerMethod){
            // 访问的是接口方法，转化为待访问的目标方法对象
            HandlerMethod targetMethod = (HandlerMethod) handler;
            // 取出目标方法中的 AccessLimit 注解
            AccessLimit accessLimit = targetMethod.getMethodAnnotation(AccessLimit.class);
            // 判断此方法接口是否要进行防刷处理（方法上没有对应注解就代表不需要，不需要的话进行放行）
            if(!Objects.isNull(accessLimit)){
                // 需要进行防刷处理，接下来是处理逻辑
                String ip = request.getRemoteAddr();
                String uri = request.getRequestURI();
                String lockKey = LOCK_PREFIX + ip + uri;
                Object isLock = redisTemplate.opsForValue().get(lockKey);
                // 判断此ip用户访问此接口是否已经被禁用
                if (Objects.isNull(isLock)) {
                    // 还未被禁用
                    String countKey = COUNT_PREFIX + ip + uri;
                    Object count = redisTemplate.opsForValue().get(countKey);
                    long second = accessLimit.second();
                    long maxTime = accessLimit.maxTime();

                    if (Objects.isNull(count)) {
                        // 首次访问
                        log.info("首次访问");
                        redisTemplate.opsForValue().set(countKey, 1, second, TimeUnit.SECONDS);
                    } else {
                        // 此用户前一点时间就访问过该接口，且频率没超过设置
                        if ((Integer) count < maxTime) {
                            redisTemplate.opsForValue().increment(countKey);
                        } else {

                            log.info("{}禁用访问{}", ip, uri);
                            long forbiddenTime = accessLimit.forbiddenTime();
                            // 禁用
                            redisTemplate.opsForValue().set(lockKey, 1, forbiddenTime, TimeUnit.SECONDS);
                            // 删除统计--已经禁用了就没必要存在了
                            redisTemplate.delete(countKey);
                            throw new CommonException(ResultCode.ACCESS_FREQUENT);
                        }
                    }
                } else {
                    // 此用户访问此接口已被禁用
                    throw new CommonException(ResultCode.ACCESS_FREQUENT);
                }
            }
        }
        return  true;
    }
}

由于不好演示效果，这里就不贴测试结果图片了

项目通过Git还原到"【自定义主键+反射实现接口自由"版本即可得到此案例实现，后面自己可以针对接口做下测试看看是否如同我所说的那样实现自定义x, y, z 的效果

嗯，现在看起来，可以针对每个要进行防刷处理的接口进行针对性自定义多长时间内的最大访问次数，以及禁用时长，哪个接口需要，就直接+在那个接口方法出即可

感觉还不错的样子，现在网上挺多资料也都是这样实现的

但是还是可以有改善的地方

先举一个例子，以我们的PassController为例，如下是其实现

下图是其映射路径关系

同一个Controller的所有接口方法映射路径的前缀都包含了/pass

我们在类上通过注解@ReqeustMapping标记映射路径/pass，这样所有的接口方法前缀都包含了/pass，并且以致于后面要修改映射路径前缀时只需改这一块地方即可

这也是我们使用SpringMVC最常见的用法

那么，我们的自定义注解也可不可以这样做呢？先无中生有个需求

假设PassController中所有接口都是要进行防刷处理的，并且他们的x, y, z值就一样

如果我们的自定义注解还是只能加载方法上的话，一个一个接口加，那么无疑这是一种很呆的做法

要改的话，其实也很简单，首先是修改自定义注解，让其可以作用在类上

接着就是修改AccessLimitInterceptor的处理逻辑

AccessLimitInterceptor中代码修改的有点多，主要逻辑如下

与之前实现比较，不同点在于x, y, z的值要首先尝试在目标类中获取

其次，一旦类中标有此注解，即代表此类下所有接口方法都要进行防刷处理

如果其接口方法同样也标有此注解，根据就近优先原则，以接口方法中的注解标明的值为准

/**
 * @author: Zero
 * @time: 2023/2/14
 * @description: 接口防刷拦截处理
 */
@Slf4j
public class AccessLimintInterceptor implements HandlerInterceptor {
    @Resource
    private RedisTemplate<String, Object> redisTemplate;

    /**
     * 锁住时的key前缀
     */
    public static final String LOCK_PREFIX = "LOCK";

    /**
     * 统计次数时的key前缀
     */
    public static final String COUNT_PREFIX = "COUNT";


    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

//      自定义注解 + 反射 实现， 版本 2.0
        if (handler instanceof HandlerMethod) {
            // 访问的是接口方法，转化为待访问的目标方法对象
            HandlerMethod targetMethod = (HandlerMethod) handler;
            // 获取目标接口方法所在类的注解@AccessLimit
            AccessLimit targetClassAnnotation = targetMethod.getMethod().getDeclaringClass().getAnnotation(AccessLimit.class);
            // 特别注意不能采用下面这条语句来获取，因为 Spring 采用的代理方式来代理目标方法
            //  也就是说targetMethod.getClass()获得是class org.springframework.web.method.HandlerMethod ,而不知我们真正想要的 Controller
//            AccessLimit targetClassAnnotation = targetMethod.getClass().getAnnotation(AccessLimit.class);
            // 定义标记位，标记此类是否加了@AccessLimit注解
            boolean isBrushForAllInterface = false;
            String ip = request.getRemoteAddr();
            String uri = request.getRequestURI();
            long second = 0L;
            long maxTime = 0L;
            long forbiddenTime = 0L;
            if (!Objects.isNull(targetClassAnnotation)) {
                log.info("目标接口方法所在类上有@AccessLimit注解");
                isBrushForAllInterface = true;
                second = targetClassAnnotation.second();
                maxTime = targetClassAnnotation.maxTime();
                forbiddenTime = targetClassAnnotation.forbiddenTime();
            }
            // 取出目标方法中的 AccessLimit 注解
            AccessLimit accessLimit = targetMethod.getMethodAnnotation(AccessLimit.class);
            // 判断此方法接口是否要进行防刷处理
            if (!Objects.isNull(accessLimit)) {
                // 需要进行防刷处理，接下来是处理逻辑
                second = accessLimit.second();
                maxTime = accessLimit.maxTime();
                forbiddenTime = accessLimit.forbiddenTime();
                if (isForbindden(second, maxTime, forbiddenTime, ip, uri)) {
                    throw new CommonException(ResultCode.ACCESS_FREQUENT);
                }
            } else {
                // 目标接口方法处无@AccessLimit注解，但还要看看其类上是否加了(类上有加，代表针对此类下所有接口方法都要进行防刷处理)
                if (isBrushForAllInterface && isForbindden(second, maxTime, forbiddenTime, ip, uri)) {
                    throw new CommonException(ResultCode.ACCESS_FREQUENT);
                }
            }
        }
        return true;
    }

    /**
     * 判断某用户访问某接口是否已经被禁用/是否需要禁用
     *
     * @param second        多长时间  单位/秒
     * @param maxTime       最大访问次数
     * @param forbiddenTime 禁用时长 单位/秒
     * @param ip            访问者ip地址
     * @param uri           访问的uri
     * @return ture为需要禁用
     */
    private boolean isForbindden(long second, long maxTime, long forbiddenTime, String ip, String uri) {
        String lockKey = LOCK_PREFIX + ip + uri; //如果此ip访问此uri被禁用时的存在Redis中的 key
        Object isLock = redisTemplate.opsForValue().get(lockKey);
        // 判断此ip用户访问此接口是否已经被禁用
        if (Objects.isNull(isLock)) {
            // 还未被禁用
            String countKey = COUNT_PREFIX + ip + uri;
            Object count = redisTemplate.opsForValue().get(countKey);
            if (Objects.isNull(count)) {
                // 首次访问
                log.info("首次访问");
                redisTemplate.opsForValue().set(countKey, 1, second, TimeUnit.SECONDS);
            } else {
                // 此用户前一点时间就访问过该接口，且频率没超过设置
                if ((Integer) count < maxTime) {
                    redisTemplate.opsForValue().increment(countKey);
                } else {
                    log.info("{}禁用访问{}", ip, uri);
                    // 禁用
                    redisTemplate.opsForValue().set(lockKey, 1, forbiddenTime, TimeUnit.SECONDS);
                    // 删除统计--已经禁用了就没必要存在了
                    redisTemplate.delete(countKey);
                    return true;
                }
            }
        } else {
            // 此用户访问此接口已被禁用
            return true;
        }
        return false;
    }
}

好了，这样就达到我们想要的效果了

项目通过Git还原到"【自定义注解+反射实现接口自由-版本2.0】"版本即可得到此案例实现，自己可以测试万一下

这是目前来说比较理想的做法，至于其他做法，暂时没啥了解到

时间逻辑漏洞

这是我一开始都有留意到的问题

也是一直搞不懂，就是我们现在的所有做法其实感觉都不是严格意义上的x秒内y次访问次数

特别注意这个x秒，它是连续，任意的（代表这个x秒时间片段其实是可以发生在任意一个时间轴上）

我下面尝试表达我的意思，但是我不知道能不能表达清楚

假设我们固定某个接口5秒内只能访问3次，以下面例子为例

底下的小圆圈代表此刻请求访问接口

按照我们之前所有做法的逻辑走

  1. 第2秒请求到，为首次访问，Redis中统计次数为1（过期时间为5秒）

  2. 第7秒，此时有两个动作，一是请求到，二是刚刚第二秒Redis存的值现在过期

  3. 我们先假设这一刻，请求处理完后，Redis存的值才过期

  4. 按照这样的逻辑走

  5. 第七秒请求到，Redis存在对应key，且不大于3， 次数+1

  6. 接着这个key立马过期

  7. 再继续往后走，第8秒又当做新的一个起始，就不往下说了，反正就是不会出现禁用的情况

按照上述逻辑走，实际上也就是说当出现首次访问时，当做这5秒时间片段的起始

第2秒是，第8秒也是

但是有没有想过，实际上这个5秒时间片段实际上是可以放置在时间轴上任意区域的

上述情况我们是根据请求的到来情况人为的把它放在【2-7】，【8-13】上

而实际上这5秒时间片段是可以放在任意区域的

那么，这样的话，【7-12】也可以放置

而【7-12】这段时间有4次请求，就达到了我们禁用的条件了

是不是感觉怪怪的

想过其他做法，但是好像严格意义上真的做不到我所说的那样（至少目前来说想不到）

之前我们的做法，正常来说也够用，至少说有达到防刷的作用

后面有机会的话再看看，不知道我是不是钻牛角尖了

路径参数问题

假设现在PassController中有如下接口方法

也就是我们在接口方法中常用的在请求路径中获取参数的套路

但是使用路径参数的话，就会发生问题

那就是同一个ip地址访问此接口时，我携带的参数值不同

按照我们之前那种前缀+ip+uri拼接的形式作为key的话，其实是区分不了的

下图是访问此接口，携带不同参数值时获取的uri状况

这样的话在我们之前拦截器的处理逻辑中，会认为是此ip用户访问的是不同的接口方法,而实际上访问的是同一个接口方法

也就导致了【接口防刷】失效

接下来就是解决它，目前来说有两种

  1. 不要使用路径参数

这算是比较理想的做法，相当于没这个问题

但有一定局限性，有时候接手别的项目，或者自己根本没这个权限说不能使用路径参数

  1. 替换uri

  • 我们获取uri的目的，其实就是为了区别访问接口

  • 而把uri替换成另一种可以区分访问接口方法的标识即可

  • 最容易想到的就是通过反射获取到接口方法名称，使用接口方法名称替换成uri即可

  • 当然，其实不同的Controller中，其接口方法名称也有可能是相同的

  • 实际上可以再获取接口方法所在类类名，使用类名 + 方法名称替换uri即可

  • 实际解决方案有很多，看个人需求吧

真实ip获取

在之前的代码中，我们获取代码都是通过request.getRemoteAddr()获取的

但是后续有了解到，如果说通过代理软件方式访问的话，这样是获取不到来访者的真实ip的

至于如何获取，后续我再研究下http再说，这里先提个醒

总结

说实话，挺有意思的，一开始自己想【接口防刷】的时候，感觉也就是转化成统计下访问次数的问题摆了。后面到网上看别人的写法，又再自己给自己找点问题出来，后面会衍生出来一推东西出来，诸如自定义注解+反射这种实现方式。

以前其实对注解 + 反射其实有点不太懂干嘛用的，而从之前的数据报表导出，再到基本权限控制实现，最后到今天的【接口防刷】一点点来进步去补充自己的知识点，而且，感觉写博客真的是件挺有意义的事情，它会让你去更深入的了解某个点，并且知识是相关联的，探索的过程中会牵扯到其他别的知识点，就像之前的写的【单例模式】实现，一开始就了解到懒汉式，饿汉式

后面深入的话就知道其实会还有序列化/反序列化，反射调用生成实例，对象克隆这几种方式回去破坏单例模式，又是如何解决的，这也是一个进步的点，后续为了保证线程安全问题，牵扯到的synchronized，voliate关键字，继而又关联到JVM，JUC，操作系统的东西。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/15134.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

不应使用Excel进行项目资源规划的 7 个原因

不应使用Excel进行项目资源规划的 7 个原因

项目资源规划早期仅限于基本分配和调度。因此&#xff0c;企业使用自制工具或excel表来执行这一简单功能。然而&#xff0c;随着技术和业务流程的发展&#xff0c;资源规划变得复杂&#xff0c;并包括其他组成部分&#xff0c;如预测和容量规划&#xff0c;优化等。 由于传统…
阅读更多...
掌握好这几款TikTok数据分析工具，让你轻松提高曝光率！

掌握好这几款TikTok数据分析工具，让你轻松提高曝光率！

为什么别人在TikTok发的普普通通的视频却有那么高的流量、几天内疯狂涨粉&#xff0c;而自己想破脑袋装饰自己的视频&#xff0c;结果却不如人意。 其实原因很简单&#xff0c;TikTok不像国内的抖音只面向中华民族&#xff0c;而是覆盖了150多个国家和75种语言用户&#xff0c…
阅读更多...
【通信接口】UART、IIC、SPI

【通信接口】UART、IIC、SPI

目录 一、预备知识 1、串行与并行 2、单工与双工 3、波特率 二、UART 三、IIC 四、SPI &#xff08;一对一、一对多&#xff09; 五、IIC、SPI异同点 参考文章&#xff1a;这些单片机接口&#xff0c;一定要熟悉&#xff1a;UART、I2C、SPI、TTL、RS232、RS422、RS485…
阅读更多...
【Java EE初阶】计算机简介及多线程之创建线程

【Java EE初阶】计算机简介及多线程之创建线程

目录 1.计算机发展史 2.冯诺依曼体系 3.操作系统 操作系统的作用&#xff1a; 4.进程 1.PID&#xff08;进程编号&#xff09; 2.内存指针 应用程序申请到的内存中的首地址 3.文件描述符表 问&#xff1a;什么是并发&#xff1f;什么是并行&#xff1f; 4.进程的优先级&a…
阅读更多...
卡尔曼滤波原理及代码

卡尔曼滤波原理及代码

目录 一.简介 二.原理 1.先验估计原理 2.后验估计原理 3.总结 三.示例 一.简介 卡尔曼滤波&#xff08;Kalman filtering&#xff09;是一种利用线性系统状态方程&#xff0c;通过系统输入输出观测数据&#xff0c;对系统状态进行最优估计的算法&#xff0c;它可以在任意…
阅读更多...
StarRocks 3.0 集群安装手册

StarRocks 3.0 集群安装手册

本文介绍如何以二进制安装包方式手动部署最新版 StarRocks 3.0集群。 什么是 StarRocks StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing) 数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理&#xff0c;就可以…
阅读更多...
同步辐射X射线断层扫描成像在各行业的应用

同步辐射X射线断层扫描成像在各行业的应用

同步辐射X射线断层扫描成像在各行业的应用 同步辐射X射线断层扫描成像&#xff08;synchrotron radiation X-ray computed tomography&#xff0c;SRCT&#xff09;是一种非侵入式、高分辨率的成像技术&#xff0c;利用同步辐射光束产生的高强度、高亮度、单色性和相干性的X射线…
阅读更多...
【面试】MySQL事务的12连问

【面试】MySQL事务的12连问

文章目录 前言1. 什么是数据库事务&#xff1f;2. 事务的四大特性3. 事务的隔离级别有哪些&#xff1f;MySQL的默认隔离级别是什么&#xff1f;4. Mysql为什么选择RR作为默认隔离级别&#xff1f;5. 很多大厂为什么选择RC数据库隔离级别&#xff1f;6. 并发场景&#xff0c;数据…
阅读更多...
Qt连接MySql数据库(本地和远程数据库均可)

Qt连接MySql数据库(本地和远程数据库均可)

提示&#xff1a;文章写完后&#xff0c;目录可以自动生成&#xff0c;如何生成可参考右边的帮助文档 文章目录 三种方法方法一 略方法二 使用ODBC设置mysql为数据源库1. 添加ODBC数据源&#xff0c;在控制面板中找到管理工具&#xff0c;其中有ODBC数据源 64位的&#xff0c;打…
阅读更多...
数字孪生与元宇宙：数字化科技的双向融合之路

数字孪生与元宇宙：数字化科技的双向融合之路

概念 &#xff08;1&#xff09;元宇宙&#xff08;Metaverse&#xff09;是一个虚拟的三维世界&#xff0c;由数字内容和物理世界中的现实空间相互交织而成&#xff0c;能够提供各种虚拟体验&#xff0c;例如虚拟现实、增强现实、虚拟社交、虚拟经济等。在元宇宙中&#xff0…
阅读更多...
8种不同类型的防火墙

8种不同类型的防火墙

什么是防火墙&#xff1f; 防火墙是一种监视网络流量并检测潜在威胁的安全设备或程序&#xff0c;作为一道保护屏障&#xff0c;它只允许非威胁性流量进入&#xff0c;阻止危险流量进入。 防火墙是client-server模型中网络安全的基础之一&#xff0c;但它们容易受到以下方面的…
阅读更多...
连ChatGPT都不懂的五一调休，到底怎么来的？

连ChatGPT都不懂的五一调休，到底怎么来的？

今天是周几&#xff1f; 你上了几天班了&#xff1f; 还要上几天班放假&#xff1f; 五一啥安排&#xff1f; 出行的票抢到了吗&#xff1f; 调休到底是谁发明的&#xff1f;&#xff01; 五一劳动节是要劳动吗&#xff1f; 为什么昨天是周一&#xff0c;今天还是周一&a…
阅读更多...
差分优化算法——DE

差分优化算法——DE

&#x1f34e;道阻且长&#xff0c;行则将至。&#x1f353; 目录 一、DE1.步骤2.特点 二、DE Optimiza1.函数最小值问题2.差分进化算法求解2.Java 实现与结果绘图 一、DE 差分进化算法是一种基于群体智能的优化算法&#xff0c;由Storn和Price于1995年提出&#xff0c;最早用…
阅读更多...
基于DSP+FPGA+ADS1282支持32Bit高精度数据采集方案（三）系统性能测试

基于DSP+FPGA+ADS1282支持32Bit高精度数据采集方案（三）系统性能测试

系统性能分析与测试 本章将首先对系统电路的噪声和温漂进行分析&#xff0c;而后对采集系统的性能进行 测试&#xff0c;并对测试数据进行分析。 5.1 高精度 AD 转换电路噪声和温漂分析 5.1.1 电阻噪声与温漂 1 、电阻的噪声 电阻是一种噪声源&#xff0c;其严重程度取…
阅读更多...
嵌入式就业怎么样?

嵌入式就业怎么样?

嵌入式就业怎么样? 现在的IT行业,嵌入式是大热门&#xff0c;下面也要来给大家介绍下学习嵌入式之后的发展以及就业怎么样。 首先是好找工作。嵌入式人才目前是处于供不应求的状态中&#xff0c;据权威统计机构统计在所有软件开发类人才的需求中&#xff0c;对嵌入式工程师的…
阅读更多...
matlab 点云滤波（中值、均值、高斯滤波）代码

matlab 点云滤波（中值、均值、高斯滤波）代码

点云中值、均值、高斯滤波 介绍一下滤波函数 smoothdata: 对含噪数据进行平滑处理 B smoothdata(___,method) 为上述任一语法指定平滑处理方法。例如&#xff0c;B smoothdata(A,sgolay) 使用 Savitzky-golay 滤波器对 A 中的数据进行平滑处理。Method-平滑处理方法 "…
阅读更多...
Springboot获取jar包中resources资源目录下的文件

Springboot获取jar包中resources资源目录下的文件

阿萨斯多问题现象&#xff1a; 今天在项目中遇到一个业务场景&#xff0c;需要用到resources资源目录下的文件&#xff0c;然后就在思考一个问题&#xff1a; 当项目打成jar后&#xff0c;Springboot要如何获取resources资源目录下的文件呢&#xff1f; 问题分析&#xff1a; 如…
阅读更多...
GitLABJenkins

GitLABJenkins

GitLAB & Jenkins 目录 实践&#xff1a;基于Jenkins提交流水线(测试成功)-2023.4.25 目的&#xff1a;掌握通过触发器将GitLab和Jenkins集成&#xff0c;实现提交流水线。 1、触发Jenkins构建 安装Generic Webhook Trigger插件 重启后&#xff0c;进入一个Pipeline项目设…
阅读更多...
用Java创建可扩展的OpenAI GPT应用程序

用Java创建可扩展的OpenAI GPT应用程序

ChatGPT 值得深入使用的方面之一是它的引擎&#xff0c;它不仅为基于Web的聊天机器人提供动力&#xff0c;还可以集成到Java应用程序中。 ▌Budget Journey App 想象一下&#xff0c;你想去一个城市旅行并且设置好了预算&#xff0c;你应该如何分配你的钱并让你的旅行难忘&am…
阅读更多...
实例分割算法BlendMask

实例分割算法BlendMask

实例分割算法BlendMask 论文地址&#xff1a;https://arxiv.org/abs/2001.00309 github代码&#xff1a;https://github.com/aim-uofa/AdelaiDet 我的个人空间&#xff1a;我的个人空间 密集实例分割 ​ 密集实例分割主要分为自上而下top-down与自下而上bottom-up两类方法…
阅读更多...
最新文章

Copyright @ 2022~2023