Spring Cloud分布式定时器之ShedLock的实现

2024-11-29 08:10:08

在实际的项目开发工作中，我们经常会遇到需要做一些定时任务的工作，那么在Spring Cloud中是如何实现的？今天来介绍下其中的一种解决方案——轻量级分布式定时锁ShedLock

ShedLock

ShedLock是一个在分布式环境中使用的定时任务框架，用于解决在分布式环境中的多个实例的相同定时任务在同一时间点重复执行的问题。

解决思路是通过对公用的数据库中的某个表进行记录和加锁，使得同一时间点只有第一个执行定时任务并成功在数据库表中写入相应记录的节点能够成功执行而其他节点直接跳过该任务。
目前已经实现的支持数据存储类型不仅仅只有关系型数据库，还包括MongoDB，Zookeeper，Redis，Hazelcast。

1. pom文件添加相关依赖

在pom文件中添加shedLock相关依赖

 <!--shedlock-->
    <dependency>
      <groupId>net.javacrumbs.shedlock</groupId>
      <artifactId>shedlock-spring</artifactId>
      <version>2.2.0</version>
    </dependency>
    <dependency>
      <groupId>net.javacrumbs.shedlock</groupId>
      <artifactId>shedlock-provider-jdbc-template</artifactId>
      <version>2.2.0</version>
    </dependency>

2. 添加相关配置

在启动类添加@EnableScheduling和@EnableSchedulerLock(defaultLockAtMostFor = "PT30S")注解，表示要启动ShedLock定时任务

defaultLockAtMostFor要设置值，不设置会报错；设置值一般设置比定时任务大点值，一般在每个定时任务中都会配置defaultLockAtMostFor值，会覆盖启动类中的值

@EnableScheduling
@EnableSchedulerLock(defaultLockAtMostFor = "PT30S")
public class OneStopServiceApplication {
  public static void main(String[] args) {
    SpringApplication.run(OneStopServiceApplication.class, args);
  }

}

3.添加ShedLock配类

shedLock支持关系型数据库，以mysql为例，配置mysql以及表名；shedLock默认表名为shedlock,可以设置自定义表名。

@Configuration
public class ScheduledLockConfig {
  @Bean
  public LockProvider lockProvider(DataSource dataSource) {
    //自定义表名
    return new JdbcTemplateLockProvider(dataSource,"ccsy_shedlock");
  }
}

4.ShedLock定时任务

@Component
public class HourTask {
  /**
   * 最小锁定时间,一般设置成定时任务小一点
   */
  private static final int MIN_LOCK_TIME = 1000;//单位毫秒
  /**
   * 最大锁定时间,一般设置成比正常执行时间长的值
   */
  private static final int MAX_LOCK_TIME = 1000 * 2;//单位毫秒

  @Scheduled(cron = "0/1 * * * * ? ")
  @SchedulerLock(name = "测试", lockAtMostFor = MAX_LOCK_TIME, lockAtLeastFor = MIN_LOCK_TIME)
  public void visitCountTaskByTwoHour() {
    SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    System.out.println("现在时间是" + format.format(new Date())+ Thread.currentThread().getName());
  }
}

@SchedulerLock注解一共支持五个参数，分别是

name 用来标注一个定时服务的名字，被用于写入数据库作为区分不同服务的标识，如果有多个同名定时任务则同一时间点只有一个执行成功
lockAtMostFor 成功执行任务的节点所能拥有独占锁的最长时间，单位是毫秒ms
lockAtMostForString 成功执行任务的节点所能拥有的独占锁的最长时间的字符串表达，例如“PT14M”表示为14分钟
lockAtLeastFor 成功执行任务的节点所能拥有独占所的最短时间，单位是毫秒ms
lockAtLeastForString 成功执行任务的节点所能拥有的独占锁的最短时间的字符串表达，例如“PT14M”表示为14分钟

5.创建mysql数据库中定时任务ccsy_shedlock表

CREATE TABLE ccsy_shedlock (
 NAME VARCHAR ( 64 ),
 lock_until TIMESTAMP ( 3 ) NULL,
 locked_at TIMESTAMP ( 3 ) NULL,
locked_by VARCHAR ( 255 ),
PRIMARY KEY ( NAME ))

到此这篇关于Spring Cloud分布式定时器之ShedLock的实现的文章就介绍到这了,更多相关Spring Cloud分布式定时器内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

Spring Cloud学习教程之DiscoveryClient的深入探究

前言当我们使用@DiscoveryClient注解的时候,会不会有如下疑问:它为什么会进行注册服务的操作,它不是应该用作服务发现的吗?下面我们就来深入的探究一下其源码. 一.Springframework的LifeCycle接口要搞明白这个问题我们需要了解一下这个重要的接口: /* * Copyright 2002-2015 the original author or authors. * * Licensed under the Apache License, Version 2.0 (
Springcloud-nacos实现配置和注册中心的方法

最近,阿里开源的nacos比较火,可以和springcloud和dubbo共用,对dubbo升级到springcloud非常的方便.这里学习一下他的配置和注册中心.我主要记录一下它的使用方式和踩得坑. nacos简单介绍 Nacos 致力于帮助您发现.配置和管理微服务.Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现.服务配置.服务元数据及流量管理. Nacos 帮助您更敏捷和容易地构建.交付和管理微服务平台. Nacos 是构建以"服务"为中心的现代应用架构 (例如
详解Spring Cloud Feign 熔断配置的一些小坑

1.在使用feign做服务调用时,使用继承的方式调用服务,加入Hystrix的熔断处理fallback配置时,会报错,已解决. 2.使用feign默认配置,熔断不生效,已解决. 最近在做微服务的学习,发现在使用feign做服务调用时,使用继承的方式调用服务,加入Hystrix的熔断处理fallback配置时,会报错,代码如下: @RequestMapping("/demo/api") public interface HelloApi { @GetMapping("user/
Spring Cloud升级最新Finchley版本的所有坑

Spring Boot 2.x 已经发布了很久,现在 Spring Cloud 也发布了基于 Spring Boot 2.x 的 Finchley 版本,现在一起为项目做一次整体框架升级. 升级前 => 升级后 Spring Boot 1.5.x => Spring Boot 2.0.2 Spring Cloud Edgware SR4 => Spring Cloud Finchley.RELEASE Eureka Server Eureka Server 依赖更新升级前: <
详解Spring Cloud Zuul中路由配置细节

上篇文章我们介绍了API网关的基本构建方式以及请求过滤,小伙伴们对Zuul的作用应该已经有了一个基本的认识,但是对于路由的配置我们只是做了一个简单的介绍,本文我们就来看看路由配置的其他一些细节. 首先我们来回忆一下上篇文章我们配置路由规则的那两行代码: zuul.routes.api-a.path=/api-a/** zuul.routes.api-a.serviceId=feign-consumer 我们说当我的访问地址符合/api-a/**规则的时候,会被自动定位到feign-consume
在idea环境下构建springCloud项目

springCloud是基于springboot搭建的微服务.它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册.配置中心.消息总线.负载均衡.断路器.数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署. spring cloud官方文档:http://projects.spring.io/spring-cloud/ spring cloud 中文网 : https://springcloud.cc/ 最终搭建后的工程源代码:http
Spring Cloud中关于Feign的常见问题总结

一.FeignClient接口,不能使用@GettingMapping 之类的组合注解代码示例: @FeignClient("microservice-provider-user") public interface UserFeignClient { @RequestMapping(value = "/simple/{id}", method = RequestMethod.GET) public User findById(@PathVariable(&quo
深入理解Spring Cloud Zuul过滤器

前言过滤器是Zuul的核心组件,这篇文章我们来详细讨论Zuul的过滤器.下面话不多说,来看看详细的介绍吧. 过滤器类型与请求生命周期 Zuul大部分功能都是通过过滤器来实现的.Zuul中定义了四种标准过滤器类型,这些过滤器类型对应于请求的典型生命周期. (1) PRE:这种过滤器在请求被路由之前调用.我们可利用这种过滤器实现身份验证.在集群中选择请求的微服务.记录调试信息等. (2) ROUTING:这种过滤器将请求路由到微服务.这种过滤器用于构建发送给微服务的请求,并使用Apache Htt
Spring Cloud学习教程之Zuul统一异常处理与回退

前言 Zuul 是Netflix 提供的一个开源组件,致力于在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架.也有很多公司使用它来作为网关的重要组成部分,碰巧今年公司的架构组决定自研一个网关产品,集动态路由,动态权限,限流配额等功能为一体,为其他部门的项目提供统一的外网调用管理,最终形成产品(这方面阿里其实已经有成熟的网关产品了,但是不太适用于个性化的配置,也没有集成权限和限流降级). 本文主要给大家介绍了关于Spring Cloud Zuul统一异常处理与回退的相关内容,分享出来供大家
Spring Cloud分布式定时器之ShedLock的实现

在实际的项目开发工作中,我们经常会遇到需要做一些定时任务的工作,那么在Spring Cloud中是如何实现的?今天来介绍下其中的一种解决方案--轻量级分布式定时锁ShedLock ShedLock ShedLock是一个在分布式环境中使用的定时任务框架,用于解决在分布式环境中的多个实例的相同定时任务在同一时间点重复执行的问题. 解决思路是通过对公用的数据库中的某个表进行记录和加锁,使得同一时间点只有第一个执行定时任务并成功在数据库表中写入相应记录的节点能够成功执行而其他节点直接跳过该任务. 目前
详解spring cloud分布式关于熔断器

spring cloud分布式中,熔断器就是断路器,其实都是一个意思. 为什么要使用熔断器呢? 在分布式中,我们会根据业务或功能将项目拆分为多个服务单元,各个服务单元之间通过服务注册和订阅的方式相互依赖和调用功能,随着项目和业务的不断拓展,服务单元数量也逐渐增多,相互之间的依赖关系也越来越复杂,这时候,可能会某个服务单元出现问题或网络原因依赖调用出错或延迟,此时如果调用该依赖的请求不断增加,那么要调用该服务的服务将都会等待或者出现故障,如果后续连锁反应越来越多,Servlet容器的线程资源会被消
详解spring cloud分布式整合zipkin的链路跟踪

为什么使用zipkin? 上篇主要写了:spring cloud分布式日志链路跟踪从上篇中可以看出服务之间的调用,假设现在有十几台服务,那么在查找日志的时候比较繁琐.复杂,而且在查看调用的时候也会像蜘蛛网一样,量太大. 这时候zipkin可以把链路调用整个过程给升级起来,只需要到一个地方去查找,就可以知道哪一步出错. zipkin也分为服务器和客户端,服务器就是zipkin,微服务就是客户端. 首先,建立服务器zipkin 在此服务build.gradle加上zipkin的依赖: compil
详解spring cloud分布式日志链路跟踪

首先要明白一点,为什么要使用链路跟踪? 当我们微服务之间调用的时候可能会出错,但是我们不知道是哪个服务的问题,这时候就可以通过日志链路跟踪发现哪个服务出错. 它还有一个好处:当我们在企业中,可能每个人都负责一个服务,我们可以通过日志来检查自己所负责的服务不会出错,当调用其它服务时,这时候出现错误,那么就可以判定出不是自己的服务出错,从而也可以发现责任不是自己的. 基于微服务之间的调用开始,如果看不懂的小伙伴,请先参考我上篇博客:spring cloud中微服务之间的调用以及eureka的自我保护
spring cloud 分布式链路追踪的方法

一篇讲了微服务之间的调用spring cloud eureka 微服务之间的调用微服务之间进行调用那么如果我负责一个模块别人负责另一个模块我调用了他的方法测试那边却报了错那是我的问题还是他的问题这个时候大家应该就能想到日志可以解决这个问题如何使用日志呢先在配置文件中加 logging: path: D:\logs\poppy-mall #日志的存放地址最好再加个项目名的文件夹可以更容易的区分 level: org.poppy.mall: info #日志的级别 org.po
详解spring cloud config整合gitlab搭建分布式的配置中心

在前面的博客中,我们都是将配置文件放在各自的服务中,但是这样做有一个缺点,一旦配置修改了,那么我们就必须停机,然后修改配置文件后再进行上线,服务少的话,这样做还无可厚非,但是如果是成百上千的服务了,这个时候,就需要用到分布式的配置管理了.而spring cloud config正是用来解决这个问题而生的.下面就结合gitlab来实现分布式配置中心的搭建.spring cloud config配置中心由server端和client端组成, 前提:在gitlab中的工程下新建一个配置文件config
spring cloud config分布式配置中心的高可用问题

在前面的文章中,我们实现了配置文件统一管理的功能,但是我们可以发现,我们仅仅只用了一个server,如果当这个server挂掉的话,整个配置中心就会不可用,下面,我们就来解决配置中心的高可用问题. 下面我们通过整合Eureka来实现配置中心的高可用,因为作为架构内的配置管理,本身其实也是可以看作架构中的一个微服务,我们可以把config server也注册为服务,这样所有客户端就能以服务的方式进行访问.通过这种方法,只需要启动多个指向同一Gitlab仓库位置的config server端就能实现
SpringCloud之分布式配置中心Spring Cloud Config高可用配置实例代码

一.简介当要将配置中心部署到生产环境中时,与服务注册中心一样,我们也希望它是一个高可用的应用.Spring Cloud Config实现服务端的高可用非常简单,主要有以下两种方式. 传统模式:不需要为这些服务端做任何额外的配置,只需要遵守一个配置规则,将所有的Config Server都指向同一个Git仓库,这样所有的配置内容就通过统一的共享文件系统来维护.而客户端在指定Config Server位置时,只需要配置Config Server上层的负载均衡设备地址即可, 就如下图所示的结构. 服
Spring Cloud Config实现分布式配置中心

在分布式系统中,配置文件散落在每个项目中,难于集中管理,抑或修改了配置需要重启才能生效.下面我们使用 Spring Cloud Config 来解决这个痛点. Config Server 我们把 config-server 作为 Config Server,只需要加入依赖: <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-ser
利用Spring Cloud Config结合Bus实现分布式配置中心的步骤

概述假设现在有个需求: 我们的应用部署在10台机器上,当我们调整完某个配置参数时,无需重启机器,10台机器自动能获取到最新的配置. 如何来实现呢?有很多种,比如: 1.将配置放置到一个数据库里面,应用每次读取配置都是直接从DB读取.这样的话,我们只需要做一个DB变更,把最新的配置信息更新到数据库即可.这样无论多少台应用,由于都从同一个DB获取配置信息,自然都能拿到最新的配置. 2.每台机器提供一个更新配置信息的updateConfig接口,当需要修改配置时,挨个调用服务器的updateConf