编译flink遇到的问题记录

编译flink遇到的问题记录

今天编译flink遇到的几个问题简单的记录下。

1.第一个问题Blocked mirror for repositories

1
2
3
Could not resolve dependencies for project
Could not transfer artifact
Blocked mirror for repositories

我们maven3.8.1在以上版本默认会禁止非https的请求，我们需要降低版本，我使用了maven3.6.8版本

2.第二个问题，maven的settings.xml,可以使用阿里的

1
2
3
4
5
6
<mirror>
   <id>nexus-aliyun</id>
   <mirrorOf>central</mirrorOf>
   <name>Nexus aliyun</name>
   <url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>

展开全文 >>

通过aop注解实现防止重复提交

通过aop注解实现防止重复提交

通过注解和aop来实现，后端的重复提交校验

1.定义防止重复提交的注解
1
2
3
4
5
6
7
8
9
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface PreventDuplicateSubmissions {

    /** 过期时间 */
    long expire() default 3;
}
2.实现防止重复提交的拦截器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
@Aspect
@Component
@Slf4j
public class PreventDuplicateSubmissionsInterceptor {

    @Autowired private Cache cache;

    @Before("@annotation(preventDuplicateSubmissions)")
    public void interceptor(PreventDuplicateSubmissions preventDuplicateSubmissions) {

        try {
            Long count = cache.incr(getParams(), preventDuplicateSubmissions.expire());
            // 如果超过2或者设置的参数，则表示重复提交了
            if (count.intValue() >= 2) {
                throw new ServiceException(ResultCode.LIMIT_ERROR);
            }
        }
        // 如果参数为空，则表示用户未登录，直接略过，不做处理
        catch (NullPointerException ignored) {
        } catch (ServiceException e) {
            throw e;
        } catch (Exception e) {
            log.error("防重复提交拦截器异常", e);
            throw new ServiceException(ResultCode.ERROR);
        }
    }

    /**
     * 获取表单参数
     *
     * @return
     */
    private String getParams() {
        HttpServletRequest request =
                ((ServletRequestAttributes)
                                Objects.requireNonNull(RequestContextHolder.getRequestAttributes()))
                        .getRequest();
        // 请求地址
        return request.getRequestURI()
                + Objects.requireNonNull(UserContext.getCurrentUser()).getId()
                + UserContext.getCurrentUser().getUsername();
    }
}
3.具体的使用
1
2
3
4
5
6
@PreventDuplicateSubmissions(expire = 5)
@GetMapping("/retry")
public String retry() {
    log.info("aop执行");
    throw new RetryException("aop执行");
}

展开全文 >>

通过aop注解实现自动重试的功能

通过aop注解实现自动重试的功能

有时候，我们在程序中不得不对某些方法进行重试，比如说，请求某个接口，如果我们每次，都通过while和count–的写法无疑会让代码，变的很不优雅。因此我们这边用spring的aop设计一下这个功能。

1.我们定义一个Exception，如果我们想重试的方法，可以指定抛出RetryException异常
1
2
3
4
5
6
7
8
9
10
@EqualsAndHashCode(callSuper = true)
@Data
public class RetryException extends RuntimeException {

    private static final long serialVersionUID = 7886918292771470846L;

    public RetryException(String message) {
        super(message);
    }
}
2.定义我们的retry注解
1
2
3
4
5
6
7
8
9
10
11
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface RetryOperation {
    /** 重试次数 */
    int retryCount() default 3;

    /** 重试间隔 */
    int waitSeconds() default 10;
}
3.实现我们的interceptor逻辑

稍微解释一下下面的代码，我们around环绕，可以让我们在method执行之前对他进行拦截，然后只catch我们指定的RetryException,

对整个代码进行重新调用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@Aspect
@Component
@Slf4j
public class RetryAspect {

    @Around(value = "@annotation(retryOperation)")
    public Object retryOperation(ProceedingJoinPoint joinPoint, RetryOperation retryOperation)
            throws Throwable {

        log.info("指定方法异常重试开始");
        Object response = null;
        int retryCount = retryOperation.retryCount();
        int waitSeconds = retryOperation.waitSeconds();
        boolean successful = false;

        do {
            try {
                response = joinPoint.proceed();
                successful = true;
            } catch (RetryException ex) {
                log.info("Operation failed, retries remaining: {}", retryCount);
                retryCount--;
                if (retryCount < 0) {
                    successful = true;
                    log.error(ex.getMessage());
                }
                if (waitSeconds > 0 && !successful) {
                    log.info("Waiting for {} second(s) before next retry", waitSeconds);
                    Thread.sleep(waitSeconds * 1000L);
                }
            }
        } while (!successful);

        return response;
    }
}
4.测试代码
1
2
3
4
5
@RetryOperation(retryCount = 3, waitSeconds = 10)
@GetMapping("/retry")
public String retry() {
    throw new RetryException("aop执行");
}

通过console打印结果，得到了我们需要的效果

image-20221010191629311

展开全文 >>

Spring aop的执行顺序

Spring aop的执行顺序

笔者在写spring aop通过注解的时候，遇到了一些注解代码不执行的情况，所以写下这篇文档，记录下aop大部分算子的执行周期。

1.首先我们实现一个注解，让他可以设置在方法上面
1
2
3
4
5
6
7
8
9
/**
 * 这个注解只是为了引入aop，没有其他的意思
 */
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Aop {
}
2.实现一个Aop拦截器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@Aspect
@Component
@Slf4j
public class AopInterceptor {

    @Around("@annotation(aopAnnotation)")
    public void around(ProceedingJoinPoint joinPoint, Aop aopAnnotation) {
        log.info("around");
        try {
            joinPoint.proceed();
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    @AfterThrowing("@annotation(aopAnnotation)")
    public void afterThrowing(Aop aopAnnotation) {
        log.info("afterThrowing");
    }

    @AfterReturning("@annotation(aopAnnotation)")
    public void AfterReturning(Aop aopAnnotation) {
        log.info("AfterReturning");
    }

    @Before("@annotation(aopAnnotation)")
    public void before(Aop aopAnnotation) {
        log.info("before");
    }

    @After("@annotation(aopAnnotation)")
    public void after(Aop aopAnnotation) {
        log.info("after");
    }
}

3.我们在添加调用方法
1
2
3
4
5
6
@Aop
@GetMapping("/retry")
public String retry() {
  log.info("aop执行");
  return "hello world";
}

查看打印结果：

image-20221010185344462

由这个图我们可以看出来：

在方法不报错的情况下，执行顺序是 around => before => method执行 => afterReturning => after,

而在方法报错的情况下呢,

image-20221010185632369

从上图我们可以看出执行顺序: around => before => method执行 => afterThrowing => after,

仔细观察两者，会发现区别只有在报错的时候执行的是afterThrowing，而成功的时候执行的是afterReturning。

总结：

Spring Aop Aspect的几个执行方法的顺序是：

Around => Before => Method => AfterReturning | AfterThrowing => After

展开全文 >>

Redis使用Lua脚本保证原子性

Redis使用Lua脚本保证原子性

Redis使用同一个Lua解释器来执行所有命令，同时，Redis保证以一种原子性的方式来执行脚本：当lua脚本在执行的时候，不会有其他脚本和命令同时执行，这种语义类似于 MULTI/EXEC。从别的客户端的视角来看，一个lua脚本要么不可见，要么已经执行完。

然而这也意味着，执行一个较慢的lua脚本是不建议的，由于脚本的开销非常低，构造一个快速执行的脚本并非难事。但是你要注意到，当你正在执行一个比较慢的脚本时，所以其他的客户端都无法执行命令。

我们通过lua和java注解实现一个流量限速功能

1.创建一个limit.lua
1
2
3
4
5
6
7
8
9
10
11
12
13
local c
c = redis.call('get',KEYS[1])
-- 调用不超过最大值，则直接返回
if c and tonumber(c) > tonumber(ARGV[1]) then
    return c;
end
-- 执行计算器自加
c = redis.call('incr',KEYS[1])
if tonumber(c) == 1 then
-- 从第一次调用开始限流，设置对应键值的过期
    redis.call('expire',KEYS[1],ARGV[2])
end
return c;
2.java代码读取lua脚本，自动注入
1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 * 流量限制脚本
 *
 * @return
 */
@Bean
public DefaultRedisScript<Long> limitScript() {
    DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
    redisScript.setScriptSource(
            new ResourceScriptSource(new ClassPathResource("script/limit.lua")));
    redisScript.setResultType(Long.class);
    return redisScript;
}
3.创建注解LimitPoint
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
/**
 * 限流注解
 *
 * @author jayce
 */
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface LimitPoint {
    /**
     * 资源的名字 无实际意义，但是可以用于排除异常
     *
     * @return String
     */
    String name() default "";

    /**
     * 资源的key
     *
     * <p>如果下方 limitType 值为自定义，那么全局限流参数来自于此 如果limitType 为ip，则限流条件 为 key+ip
     *
     * @return String
     */
    String key() default "";

    /**
     * Key的prefix redis前缀，可选
     *
     * @return String
     */
    String prefix() default "";

    /**
     * 给定的时间段 单位秒
     *
     * @return int
     */
    int period() default 60;

    /**
     * 最多的访问限制次数
     *
     * @return int
     */
    int limit() default 10;

    /**
     * 类型 ip限制 还是自定义key值限制 建议使用ip，自定义key属于全局限制，ip则是某节点设置，通常情况使用IP
     *
     * @return LimitType
     */
    LimitTypeEnums limitType() default LimitTypeEnums.IP;
}
4.aop拦截操作
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
@Before("@annotation(limitPointAnnotation)")
public void interceptor(LimitPoint limitPointAnnotation) {
    LimitTypeEnums limitTypeEnums = limitPointAnnotation.limitType();

    String key;
    int limitPeriod = limitPointAnnotation.period();
    int limitCount = limitPointAnnotation.limit();
    if (limitTypeEnums == LimitTypeEnums.CUSTOMER) {
        key = limitPointAnnotation.key();
    } else {
        key =
                limitPointAnnotation.key()
                        + IpUtils.getIpAddress(
                                ((ServletRequestAttributes)
                                                Objects.requireNonNull(
                                                        RequestContextHolder
                                                                .getRequestAttributes()))
                                        .getRequest());
    }
    ImmutableList<String> keys =
            ImmutableList.of(StringUtils.join(limitPointAnnotation.prefix(), key));
    try {
        Number count = redisTemplate.execute(limitScript, keys, limitCount, limitPeriod);
        assert count != null;
        log.info("限制请求{}, 当前请求{},缓存key{}", limitCount, count.intValue(), key);
        // 如果缓存里没有值，或者他的值小于限制频率
        if (count.intValue() >= limitCount) {
            throw new ServiceException(ResultCode.LIMIT_ERROR);
        }
    }
    // 如果从redis中执行都值判定为空，则这里跳过
    catch (NullPointerException ignored) {
    } catch (ServiceException e) {
        throw e;
    } catch (Exception e) {
        log.error("限流异常", e);
        throw new ServiceException(ResultCode.ERROR);
    }
}

如上操作，我们通过下方的代码实现了流量限速，并且保证了原子性

1
Number count = redisTemplate.execute(limitScript, keys, limitCount, limitPeriod);

下面使我们的调用代码：

1
2
3
4
5
6
@LimitPoint(key = "hello", period = 60, limit = 2,limitType = LimitTypeEnums.IP)
@GetMapping("/test")
public String test() {
    cache.put("test","test");
    return "hello world";
}

然后使我们的效果截图：

image-20221010173503515

展开全文 >>

常用的一些开发经验记录

1.常用的开发总结

1.lombok @Data当中不包含继承Serializable接口，因此pojo要手动继承这个类

1
2
3
4
5
6
@Data
@AllArgsConstructor
@NoArgsConstructor
public class SearchVO implements Serializable {
		private static final long serialVersionUID = 1L;
}

2.fastjson重复引用和循环引用

循环引用：

1
2
3
4
5
6
7
8
// 循环引用的特殊情况，自引用
Map<String,Object> map = new HashMap<>();
map.put("map",map);
// map1引用了map2，而map2又引用map1，导致循环引用
Map<String,Object> map1 = new HashMap<>();
Map<String,Object> map2 = new HashMap<>();
map1.put("map",map2);
map2.put("map",map1);

一般来说，存在循环引用问题的集合/对象在序列化时（比如Json化），如果不加以处理，会触发StackOverflowError异常。

分析原因：

当序列化引擎解析map1时，它发现这个对象持有一个map2的引用，转而去解析map2。解析map2时，发现他又持有map1的引用，又转回map1。如此产生StackOverflowError异常。

1
2
//关闭FastJson的引用检测
JSON.toJSONString(object,SerializerFeature.DisableCircularReferenceDetect);

3.spring引入了RedisOperations.class才会配置这个类

1
2
//在config上使用，只有我们引入redis包的时候，才会构建bean
@ConditionalOnClass(RedisOperations.class)

4.@ConditionalOnMissingBean,只有当不存在这个bean的时候才能注册成功。

1
2
3
@Bean(name = "redisTemplate")
//当你的bean被注册之后，如果而注册相同类型的bean，就不会成功，它会保证你的bean只有一个，即你的实例只有一个，当你注册多个相同的bean时，会出现异常
@ConditionalOnMissingBean(name = "redisTemplate")

5.mybatis-plus开通二级缓存

1.mapper接口添加注解
1
2
3
4
5
@Repository
@Mapper
@CacheNamespace
public interface HisAlarmDao extends BaseMapper<HisAlarmEntity> {
}
2.application.yml开通二级缓存
1
2
3
4
#Mybatis-plus配置
mybatis-plus:
  configuration:
    cache-enabled: true #开启mybatis的二级缓存
3.启动类添加开启二级缓存注解
1
2
3
4
5
6
7
@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
@EnableCaching
public class AmsConfigApplication {
    public static void main(String[] args) {
        ConfigurableApplicationContext run = SpringApplication.run(AmsConfigApplication.class, args);
	} 
}

展开全文 >>

Spring缓存注解@Cacheable、@CacheEvict、@CachePut的使用

1.Spring缓存注解@Cacheable、@CacheEvict、@CachePut的使用

1.@Cacheable

@Cacheable可以标记在一个方法上，也可以标记在一个类上。

  • 当标记在一个方法上时表示该方法是支持缓存的
  • 当标记在一个类上时则表示该类所有的方法都是支持缓存的

Spring会在其被调用后将其返回值缓存起来，以保证下次利用同样的参数来执行该方法时可以直接从缓存中获取结果，而不需要再次执行该方法。Spring在缓存方法的返回值时是以键值对进行缓存的，值就是方法的返回结果，至于键的话，Spring又支持两种策略，默认策略和自定义策略

需要注意的是当一个支持缓存的方法在对象内部被调用时是不会触发缓存功能的。

1.1 value属性指定Cache名称 (required)

value属性是必须指定的，其表示当前方法的返回值是会被缓存在哪个Cache上的，对应Cache的名称。其可以是一个Cache也可以是多个Cache，当需要指定多个Cache时其是一个数组。

1
2
3
4
5
6
7
8
9
10
11
//Cache是发生在cache1上的
@Cacheable("cache1")
public User find(Integer id) {
  return null;
}

//Cache是发生在cache1和cache2上的
@Cacheable({"cache1", "cache2"})
public User find(Integer id) {
  return null;
}

1.2 使用key属性自定义key

key属性是用来指定Spring缓存方法的返回结果时对应的key的。该属性支持SpringEL表达式。当我们没有指定该属性时，Spring将使用默认策略生成key。我们这里先来看看自定义策略，至于默认策略会在后文单独介绍。

自定义策略是指我们可以通过Spring的EL表达式来指定我们的key。这里的EL表达式可以使用方法参数及它们对应的属性。使用方法参数时我们可以直接使用“#参数名”或者“#p参数index”。下面是几个使用参数作为key的示例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Cacheable(value="users", key="#id")
public User find(Integer id) {
  return null;
}

@Cacheable(value="users", key="#p0")
public User find(Integer id) {
  return null;
}

@Cacheable(value="users", key="#user.id")
public User find(User user) {
  return null;
}

@Cacheable(value="users", key="#p0.id")
public User find(User user) {
  return null;
}

除了上述使用方法参数作为key之外，Spring还为我们提供了一个root对象可以用来生成key。通过该root对象我们可以获取到以下信息。

属性名称 描述 示例
methodName 当前方法名 #root.methodName
method 当前方法 #root.method.name
target 当前被调用的对象 #root.target
targetClass 当前被调用的对象的class #root.targetClass
args 当前方法参数组成的数组 #root.args[0]
caches 当前被调用的方法使用的Cache #root.caches[0].name

当我们要使用root对象的属性作为key时,我们也可以将“#root”省略，因为Spring默认使用的就是root对象的属性。如：

1
2
3
4
@Cacheable(value={"users", "xxx"}, key="caches[1].name")
public User find(User user) {
	return null;
}

1.3 condition属性指定发生的条件

有的时候我们可能并不希望缓存一个方法所有的返回结果。通过condition属性可以实现这一功能。condition属性默认为空，表示将缓存所有的调用情形。其值是通过SpringEL表达式来指定的，当为true时表示进行缓存处理；当为false时表示不进行缓存处理，即每次调用该方法时该方法都会执行一次。如下示例表示只有当user的id为偶数时才会进行缓存。

1
2
3
4
5
@Cacheable(value={"users"}, key="#user.id", condition="#user.id%2==0")
public User find(User user) {
	System.out.println("find user by user " + user);
	return user;
}

2.@CachePut

  • @Cacheable标注的方法，Spring在每次执行前都会检查Cache中是否存在相同key的缓存元素，如果存在就不再执行该方法，而是直接从缓存中获取结果进行返回，否则才会执行并将返回结果存入指定的缓存中。
  • @CachePut也可以声明一个方法支持缓存功能。与@Cacheable不同的是使用@CachePut标注的方法在执行前不会去检查缓存中是否存在之前执行过的结果，而是每次都会执行该方法，并将执行结果以键值对的形式存入指定的缓存中。
  • @CachePut也可以标注在类上和方法上。使用@CachePut时我们可以指定的属性跟@Cacheable是一样的。
1
2
3
4
5
//每次都会执行方法，并将结果存入指定的缓存中
@CachePut("users")
public User find(Integer id) {
   return null;
}

3 @CacheEvict

  • @CacheEvict是用来标注在需要清除缓存元素的方法或类上的。

  • 当标记在一个类上时表示其中所有的方法的执行都会触发缓存的清除操作。

  • @CacheEvict可以指定的属性有value、key、condition、allEntries和beforeInvocation。

    其中value、key和condition的语义与@Cacheable对应的属性类似。即value表示清除操作是发生在哪些Cache上的（对应Cache的名称key表示需要清除的是哪个key，如未指定则会使用默认策略生成的key；condition表示清除操作发生的条件。

    下面我们来介绍一下新出现的两个属性allEntries和beforeInvocation。

3.1 allEntries属性

allEntries是boolean类型，表示是否需要清除缓存中的所有元素。默认为false，表示不需要。当指定了allEntries为true时，Spring Cache将忽略指定的key。有的时候我们需要Cache一下清除所有的元素，这比一个一个清除元素更有效率。

1
2
3
4
@CacheEvict(value="users", allEntries=true)
public void delete(Integer id) {
	System.out.println("delete user by id: " + id);、
}

3.2 beforeInvocation属性

清除操作默认是在对应方法成功执行之后触发的，即方法如果因为抛出异常而未能成功返回时也不会触发清除操作。使用beforeInvocation可以改变触发清除操作的时间，当我们指定该属性值为true时，Spring会在调用该方法之前清除缓存中的指定元素。

1
2
3
4
@CacheEvict(value="users", beforeInvocation=true)
public void delete(Integer id) {
	System.out.println("delete user by id: " + id);
}

4.@Caching

@Caching注解可以让我们在一个方法或者类上同时指定多个Spring Cache相关的注解。其拥有三个属性：cacheable、put和evict，分别用于指定@Cacheable、@CachePut和@CacheEvict。

1
2
3
4
@Caching(cacheable = @Cacheable("users"), evict = { @CacheEvict("cache2"), @CacheEvict(value = "cache3", allEntries = true) })
public User find(Integer id) {
	return null;
}

展开全文 >>

高并发缓存代码怎么写

高并发代码怎么写？

笔者最近从go zero框架写的代码中获得不小启发。所以写出一个文档用来总结，并且尝试把go zero的这些并发特性，用spring boot实现。

  • 没有查询条件到Primary映射的缓存
    • 通过查询条件到DB去查询行记录，然后
      • 把Primary到行记录的缓存写到redis里
      • 把查询条件到Primary的映射保存到redis里，框架的Take方法自动做了
    • 可能的过期顺序
      • 查询条件到Primary的映射缓存未过期
        • Primary到行记录的缓存未过期
          • 直接返回缓存行记录
        • Primary到行记录的缓存已过期
          • 通过Primary到DB获取行记录，并写入缓存
            • 此时存在的问题是，查询条件到Primary的缓存可能已经快要过期了，短时间内的查询又会触发一次数据库查询
            • 要避免这个问题，可以让上面粗体部分第一个过期时间略长于第二个，比如5秒
      • 查询条件到Primary的映射缓存已过期，不管Primary到行记录的缓存是否过期
        • 查询条件到Primary的映射会被重新获取，获取过程中会自动写入新的Primary到行记录的缓存，这样两种缓存的过期时间都是刚刚设置
  • 有查询条件到Primary映射的缓存
    • 没有Primary到行记录的缓存
      • 通过Primary到DB查询行记录，并写入缓存
    • 有Primary到行记录的缓存
      • 直接返回缓存结果

1.第一种情况，基于主键的缓存

image-20221009160400130

  1. 我们基于key，从缓存里查找数据
  2. 如果找到了，就返回数据
  3. 找不到，就去查询数据库查询数据
  4. 查询到数据库的数据之后，根据 key，查询到的value设置到数据库当中

2.第二种情况，基于唯一索引的缓存逻辑

image-20221009161019005

代码分为两个block，

在block1当中：

找到索引和主键的缓存的情况：

  1. 从redis当中查找唯一索引index-key的缓存，这个时候找到的话，找到的key。
  2. 如果查到了key-value的映射，直接返回value
  3. 如果找不到value，从数据库查询到value
  4. 在redis中设置key-value的缓存

找不到索引和主键的缓存情况：

  1. 通过唯一索引从数据库查找结果index-value
  2. 设置index-key的缓存
  3. 设置key-value的缓存

总结下db缓存设计:

  • 都是先更新db，然后删除缓存
  • 缓存只删除不更新
  • 行记录始终只存储一份，即主键对应行记录
  • 唯一索引仅缓存主键值，不直接缓存行记录（参考mysql索引思想）
  • 防缓存穿透设计，默认一分钟
  • 不缓存多行记录

3.业务层缓存设计

  • 增加内存缓存：通过内存缓存来存储当前可能突发访问量比较大的数据，常用的存储方案采用map数据结构来存储，map数据存储实现比较简单，但缓存过期处理则需要增加定时器来处理，另一种方案是通过go-zero库中的 Cache ，其是专门 用于内存管理.
  • 采用biz redis,并设置合理的过期时间
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
type Content struct {
    Id         string    `json:"id"`
    Title      string    `json:"title"`
    Content    string    `json:"content"`
    CreateTime time.Time `json:"create_time"`
}

const bizContentCacheKey = `biz#content#cache`

// AddContent 提供内容存储
func AddContent(r redis.Redis, c *Content) error {
    v := compress(c)
    _, err := r.Zadd(bizContentCacheKey, c.CreateTime.UnixNano()/1e6, v)
    return err
}

// DelContent 提供内容删除
func DelContent(r redis.Redis, c *Content) error {
    v := compress(c)
    _, err := r.Zrem(bizContentCacheKey, v)

    return err
}

// 内容压缩
func compress(c *Content) string {
    // todo: do it yourself
    var ret string
    return ret
}

// 内容解压
func unCompress(v string) *Content {
    // todo: do it yourself
    var ret Content
    return &ret
}

// ListByRangeTime提供根据时间段进行数据查询
func ListByRangeTime(r redis.Redis, start, end time.Time) ([]*Content, error) {
    kvs, err := r.ZrangebyscoreWithScores(bizContentCacheKey, start.UnixNano()/1e6, end.UnixNano()/1e6)
    if err != nil {
        return nil, err
    }

    var list []*Content
    for _, kv := range kvs {
        data:=unCompress(kv.Key)
        list = append(list, data)
    }

    return list, nil
}

4.内存缓存

cache 实现的功能包括

  • 缓存自动失效，可以指定过期时间
  • 缓存大小限制，可以指定缓存个数
  • 缓存增删改
  • 缓存命中率统计
  • 并发安全
  • 缓存击穿

5.缓存击穿

缓存击穿是指访问某个非常热的数据，缓存不存在，导致大量的请求发送到了数据库，这会导致数据库压力陡增，缓存击穿经常发生在热点数据过期失效时，如下图所示：

image-20221009165326507

既然缓存击穿经常发生在热点数据过期失效的时候，那么我们不让缓存失效不就好了，每次查询缓存的时候不要使用Exists来判断key是否存在，而是使用Expire给缓存续期，通过Expire返回结果判断key是否存在，既然是热点数据通过不断地续期也就不会过期了

还有一种简单有效的方法就是通过singleflight来控制，singleflight的原理是当同时有很多请求同时到来时，最终只有一个请求会最终访问到资源，其他请求都会等待结果然后返回。获取商品详情使用singleflight进行保护示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
func (l *ProductLogic) Product(in *product.ProductItemRequest) (*product.ProductItem, error) {
  v, err, _ := l.svcCtx.SingleGroup.Do(fmt.Sprintf("product:%d", in.ProductId), func() (interface{}, error) {
    return l.svcCtx.ProductModel.FindOne(l.ctx, in.ProductId)
  })
  if err != nil {
    return nil, err
  }
  p := v.(*model.Product)
  return &product.ProductItem{
    ProductId: p.Id,
    Name:      p.Name,
  }, nil
}

6.缓存穿透

缓存穿透是指要访问的数据既不在缓存中，也不在数据库中，导致请求在访问缓存时，发生缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据。此时也就没办法从数据库中读出数据再写入缓存来服务后续的请求，类似的请求如果多的话就会给缓存和数据库带来巨大的压力。

针对缓存穿透问题，解决办法其实很简单，就是缓存一个空值，避免每次都透传到数据库，缓存的时间可以设置短一点，比如1分钟，其实上文已经有提到了，当我们访问不存在的数据的时候，go-zero框架会帮我们自动加上空缓存，比如我们访问id为999的商品，该商品在数据库中是不存在的。

7.缓存雪崩

缓存雪崩时指大量的的应用请求无法在Redis缓存中进行处理，紧接着应用将大量的请求发送到数据库，导致数据库被打挂，好惨呐！！缓存雪崩一般是由两个原因导致的，应对方案也不太一样。

第一个原因是：缓存中有大量的数据同时过期，导致大量的请求无法得到正常处理。

针对大量数据同时失效带来的缓存雪崩问题，一般的解决方案是要避免大量的数据设置相同的过期时间，如果业务上的确有要求数据要同时失效，那么可以在过期时间上加一个较小的随机数，这样不同的数据过期时间不同，但差别也不大，避免大量数据同时过期，也基本能满足业务的需求。

第二个原因是：Redis出现了宕机，没办法正常响应请求了，这就会导致大量请求直接打到数据库，从而发生雪崩

针对这类原因一般我们需要让我们的数据库支持熔断，让数据库压力比较大的时候就触发熔断，丢弃掉部分请求，当然熔断是对业务有损的。

在go-zero的数据库客户端是支持熔断的，如下在ExecCtx方法中使用熔断进行保护

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
func (db *commonSqlConn) ExecCtx(ctx context.Context, q string, args ...interface{}) (
  result sql.Result, err error) {
  ctx, span := startSpan(ctx, "Exec")
  defer func() {
    endSpan(span, err)
  }()

  err = db.brk.DoWithAcceptable(func() error {
    var conn *sql.DB
    conn, err = db.connProv()
    if err != nil {
      db.onError(err)
      return err
    }

    result, err = exec(ctx, conn, q, args...)
    return err
  }, db.acceptable)

  return
}

8.缓存一致性(TODO)

展开全文 >>

DeferredResult使用解读

DeferredResult使用解读

1、为什么使用DeferredResult

项目中我们某些接口有耗时操作，例如发送邮件、发送短信等有涉及调用的第三方接口的地方，因为第三方具有不确定性，可能耗时很久才会有数据返回。数据库某些慢查询。通常一些耗时且不必马上有返回结果的我们会采用消息中间件，例如 RabbitMQ、Disruptor等，但是有一些耗时但是又需要等待结果返回的，我们可以使用DeferredResult进行异步处理。以此提高我们服务器的性能。

2、实战

R为自定义的返回结果集
tomcat并发了大概在300到500，此接口被大量访问时若没进行异步处理，服务器资源一下子就会耗完。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@GetMapping("/test")
public DeferredResult<R> test(){
  //设置10秒超时
  DeferredResult deferredResult = new DeferredResult(10000L);
  //模拟耗时操作
  try
  {
    Thread.sleep(5000);
  }
  catch (InterruptedException e)
  {
    e.printStackTrace();
  }

  deferredResult.setResult(R.ok());
  return deferredResult;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
import java.util.HashMap;

/**
 * @description: 封装返回结果类
 * @author: hs
 * @create: 2018-09-21 22:42:04
 **/
public class R<T> extends HashMap<String, Object> {
    private static final long serialVersionUID = 1L;
    
    public R(int code,String msg) {
        put("code", code);
        put("msg", msg);
        put("data", null);
        put("error",false);
    }

    public static R fail() {

        return new R(RetEnum.ERROR.getRet(),RetEnum.ERROR.getMsg());
    }
    
    public static R fail(String msg) {
        return fail(RetEnum.ERROR.getRet(), msg);
    }
    
    public static R fail(int code, String msg) {
        R r = new R(code,msg);
        r.put("error",true);
        r.put("data",null);
        return r;
    }

    public static <T> R<T> fail(T data) {
        R r = new R(RetEnum.ERROR.getRet(),RetEnum.ERROR.getMsg());
        r.put("data",data);
        r.put("error",true);
        return r;
    }


    public static <T> R<T> fail(int code,String msg,T data) {
        R r = new R(code,msg);
        r.put("data",data);
        r.put("error",true);
        return r;
    }



    public static R ok() {

        return new R(RetEnum.SUCCESS.getRet(),RetEnum.SUCCESS.getMsg());
    }



    public static R ok(String msg) {
        R r = new R(RetEnum.SUCCESS.getRet(),msg);
        r.put("data",msg);
        r.put("error",false);

        return r;
    }

    public static R ok(int code, String msg) {
        R r = new R(code,msg);
        r.put("code", code);
        r.put("msg", msg);
        r.put("data", null);
        r.put("error",false);

        return r;
    }


    public static <T> R<T> ok(T data) {
        R r = new R(RetEnum.SUCCESS.getRet(),RetEnum.SUCCESS.getMsg());
        r.put("data",data);
        r.put("error",false);
        return r;
    }


    public static <T> R<T> ok(int code,String msg,T data) {
        R r = new R(code,msg);
        r.put("data",data);
        r.put("error",false);
        return r;
    }


    @Override
    public R put(String key, Object value) {
        super.put(key, value);
        return this;
    }


}

展开全文 >>

lilishop源码解读

lilishop源码解读

1.会员架构

1.账号密码登录流程图:

token

类关系图

tokenLoginClass

1.使用账号密码登录

1、携带uuid与服务端交互，服务端记录唯一id，并且将第三方登录地址返回

2、将第三方返回的信息在redis缓存中记录，

3、返回accesstoken（访问token），以及refreshtoken（过期刷新token）

4、请求api时携带accesstoken

5、服务端校验时，将前端token带入到redis中进行判定，如果存在则认为是前端的正常请求，予以放行

刷新token

6、携带过期accesstoken请求后段，

7、api查验发现redis中没有token记录

8、返回403状态

9、前端判定到403状态，携带refreshtoken去请求刷新token接口

10、判定redis中的refreshtoken是否有效

11、根据refreshtoken中信息，从新构建accesstoken以及refreshtoken

12、返回accesstoken（访问token），以及refreshtoken（过期刷新token）

13、前端刷新当前页面，重新请求api

14、正确响应

2.第三方登录

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

小本科一枚<br/><br/>就职于Artefact<br/>大数据开发