解决分布式集群环境下定时任务执行多次的方法汇总

在开发的过程中，项目中使用定时器已经不是一个新鲜的事情了，但是如果你的项目后期部署到集群环境下，如果不做处理，就会出现意想不到的问题，原因：由于我们项目同时部署在多台集群机器上，因此到达指定的定时时间时，多台机器上的定时器可能会同时启动，造成重复数据或者程序异常等问题，下面我提供几种解决方案：

一、固定执行定时任务的机器

方法：在多台机器中选择一台执行定时任务，每次执行的时候回判断当前机器和指定的机器是否一致或者启动时就指定好执行机器

优缺点：这种方法是可以有效避免多次执行的情况，，但是最明显的缺点就是单点故障问题，如果你指定的机器出现了宕机，，任务就不会执行了，业务逻辑就会奔溃。

二、在数据库建立多张表，从定时任务表中获取定时方法

方法：由于MySQL存在表锁和行锁（MyISAM引擎只支持表锁，而InnoDB支持行锁和表锁两种），每次执行定时任务的时候从数据库表中读取记录，只有读取到的记录标识当前任务状态为未执行时，当前机器才会去触发任务，并且更新数据库状态(先更新，再执行)，由于存在表锁和行锁，因此同一时刻只能有一个事务操作，可以保证只执行一次

优缺点：这种方法是一种比较合适的方式，但是需要有多张表，并且已经做了定时器逻辑上会有较大的改动

使用基于数据库的这种实现方式很简单，但是对于分布式锁应该具备的条件来说，它有一些问题需要解决及优化：

1、因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能，所以，数据库需要双机部署、数据同步、主备切换；

2、不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据，所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；

3、没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁，所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；

4、不具备阻塞锁特性，获取不到锁直接返回失败，所以需要优化获取逻辑，循环多次去获取。

5、在实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑。

三、借助Redis的过期机制和分布式锁

方法：为你的定时器在Redis中定义一个键值对，可以用项目名称和服务器ip，执行任务前先从Redis中读取键，若没有值代表任务未被执行，同样的该台机器先更新redis，再触发定时任务。由于Redis存在过期机制，因此可以设置过期时间保证下次判断正常

优缺点：该方法个人比较推荐，简单，对业务逻辑的改变也会少很多，只需要在原来的定时器上加上简单判断即可

四、Quartz的集群应用方式

方法：如果你的项目使用的是Spring自带有Task定时任务机制，quartz框架本身就是支持集群环境，可以搭建集群环境下的定时器，也能解决上述问题 不过需要配置11张数据库表

优缺点：该解决方案最大的问题是需要配置11张左右的数据库表，工作量非常大

五 、Zookeeper分布式锁实现

https://zhuanlan.zhihu.com/p/363323742
https://blog.csdn.net/crazymakercircle/article/details/85956246
————————————————

原文链接：

https://blog.csdn.net/qq_33709582/article/details/108262995
https://blog.csdn.net/kongmin_123/article/details/82081953?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-5.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-5.control

https://blog.csdn.net/xlgen157387/article/details/79036337
https://zhuanlan.zhihu.com/p/357364273

参考1