Elastic Job 同城主备、同城双活，高可用必备～

╰半夏微凉° 2022-09-09 09:20 234阅读 0赞

**点击关注公众号，Java干货****及时送达**![b09e0c288ad3c863b2d4d96d5451ccf0.png][]

*作者：薛定谔的风口猪  
来源：https://jaskey.github.io/blog/2020/05/25/elastic-job-timmer-active-standby/*

在使用Elastic Job Lite做定时任务的时候，我发现很多开发的团队都是直接部署单点，这对于一些离线的非核心业务（如对账、监控等）或许无关紧要，但对于一些高可用补偿、核心数据定时修改（如金融场景的利息更新等），单点部署则“非常危险”。实际上，Elastic Job Lite是支持高可用的。

网上关于Elastic Job的较高级的博文甚少，本文试图结合自身实践的一些经验，大致讲解其方案原理，并延伸至同城双机房的架构实践。

### 单点部署到高可用 ###

如本文开头所说，很多系统的部署是采取以下部署架构：

![5643c57db42a6ad6496e80215b452475.png][]

原因是开发者**担心定时任务在同一时刻被触发多次**，导致业务有问题。实际上这是对于框架最基本的原理不了解。在官方文档的功能列表里：

> http://elasticjob.io/docs/elastic-job-lite/00-overview/

就已说明其最基本的功能之一就是：

> 作业分片一致性，保证同一分片在分布式环境中仅一个执行实例

Elastic Job 基础教程推荐看这里：

> http://www.javastack.cn/tags/Elastic-Job/

Elastic Job会依赖zookeeper选举出对应的实例做sharding，从而保证只有一个实例在执行同一个分片（如果任务没有采取分片（即分片数是0），就意味着这个任务只有一个实例在执行）

所以如下图所示的部署架构是完全没问题的——一来，服务只会被一个实例调用，二来，如果某个服务挂了，其他实例也能接管继续提供服务从而实现高可用。

![5e7456e62bc0c65fbff3c0a30881e4dc.png][]

### 双机房高可用 ###

随着互联网业务的发展，慢慢地，对架构的高可用会有更高的要求。下一步可能就是需要同城两机房部署，那这时候为了保证定时服务在两个机房的高可用，我们架构上可能会变成这样的：

![a398534587ef59ae4dca206ce31aedeb.png][]

这样如果A机房的定时任务全部不可用了，B机房的确也能接手提供服务。而且由于集群是一个，Elastic Job能保证同一个分片在两个机房也只有一个实例运行。看似挺完美的。

注：本文不讨论zookeeper如何实现双机房的高可用，实际上从zookeeper的原理来看，仅仅两个机房组成一个大集群并不可以实现双机房高可用。另外，Zookeeper 系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。

### 优先级调度？ ###

以上的架构解决了定时任务在两个机房都可用的问题，但是实际的生产中，定时任务很可能是依赖存储的数据源的。而这个数据源，通常是有主备之分（这里不考虑单元化的架构的情况）：例如主在A机房，备在B机房做实时同步。

如果这个定时任务只有读操作，可能没问题，因为只要配置数据源连接同机房的数据源即可。但是如果是要写入的，就有一个问题——如果所有任务都在B机房被调度了，那么这些数据的写入都会跨机房地往A机房写入，这样延迟就大大提升了，如下图所示。

![7d97e0dc8d3c4f795840fc99bf6e43e3.png][]

如图所示，如果Elastic Job把任务都调度到了B机房，那么流量就一直跨机房写了，这样对于性能来说是不好的事情。

那么有没有办法达到如下效果了：

1.  保证两个机房都随时可用，也就是一个机房的服务如果全部不可用了，另外一个机房能提供对等的服务
2.  但一个任务可以优先指定A机房执行

### Elastic Job分片策略 ###

在回答这个问题之前，我们需要了解下Elastic Job的分片策略，根据官网的说明（http://elasticjob.io/docs/elastic-job-lite/02-guide/job-sharding-strategy/ ） ，Elastic Job是内置了一些分片策略可选的，其中有平均分配算法，作业名的哈希值奇偶数决定IP升降序算法和作业名的哈希值对服务器列表进行轮转；同时也是支持自定义的策略，实现实现`JobShardingStrategy`接口并实现`sharding`方法即可。

public Map<JobInstance, List<Integer>> sharding(List<JobInstance> jobInstances, String jobName, int shardingTotalCount)

假设我们可以实现这一的自定义策略：让做分片的时候知道哪些实例是A机房的，哪些是B机房的，然后我们知道A机房是优先的，在做分片策略的时候先把B机房的实例踢走，再复用原来的策略做分配。这不就解决我们的就近接入问题（接近数据源）了吗？

[以下是利用装饰器模式自定义的一个装饰器类（抽象类，由子类判断哪些实例属于standby的实例），读者可以结合自身业务场景配合使用。][standby]

public abstract class JobShardingStrategyActiveStandbyDecorator implements JobShardingStrategy {
    
        //内置的分配策略采用原来的默认策略：平均
        private JobShardingStrategy inner = new AverageAllocationJobShardingStrategy();
    
    
        /**
         * 判断一个实例是否是备用的实例，在每次触发sharding方法之前会遍历所有实例调用此方法。
         * 如果主备实例同时存在于列表中，那么备实例将会被剔除后才进行sharding
         * @param jobInstance
         * @return
         */
        protected abstract boolean isStandby(JobInstance jobInstance, String jobName);
    
        @Override
        public Map<JobInstance, List<Integer>> sharding(List<JobInstance> jobInstances, String jobName, int shardingTotalCount) {
    
            List<JobInstance> jobInstancesCandidates = new ArrayList<>(jobInstances);
            List<JobInstance> removeInstance = new ArrayList<>();
    
            boolean removeSelf = false;
            for (JobInstance jobInstance : jobInstances) {
                boolean isStandbyInstance = false;
                try {
                    isStandbyInstance = isStandby(jobInstance, jobName);
                } catch (Exception e) {
                    log.warn("isStandBy throws error, consider as not standby",e);
                }
    
                if (isStandbyInstance) {
                    if (IpUtils.getIp().equals(jobInstance.getIp())) {
                        removeSelf = true;
                    }
                    jobInstancesCandidates.remove(jobInstance);
                    removeInstance.add(jobInstance);
                }
            }
    
            if (jobInstancesCandidates.isEmpty()) {//移除后发现没有实例了，就不移除了，用原来的列表（后备）的顶上
                jobInstancesCandidates = jobInstances;
                log.info("[{}] ATTENTION!! Only backup job instances exist, but do sharding with them anyway {}", jobName, JSON.toJSONString(jobInstancesCandidates));
            }
    
            if (!jobInstancesCandidates.equals(jobInstances)) {
                log.info("[{}] remove backup before really do sharding, removeSelf :{} , remove instances: {}", jobName, removeSelf, JSON.toJSONString(removeInstance));
                log.info("[{}] after remove backups :{}", jobName, JSON.toJSONString(jobInstancesCandidates));
            } else {//全部都是master或者全部都是slave
                log.info("[{}] job instances just remain the same {}", jobName, JSON.toJSONString(jobInstancesCandidates));
            }
    
            //保险一点，排序一下，保证每个实例拿到的列表肯定是一样的
            jobInstancesCandidates.sort((o1, o2) -> o1.getJobInstanceId().compareTo(o2.getJobInstanceId()));
    
            return inner.sharding(jobInstancesCandidates, jobName, shardingTotalCount);
    
        }

### [利用自定义策略实现同城双机房下的优先级调度][standby] ###

[以下是一个很简单的就近接入的例子：指定在ip白名单的，就是优先执行的，不在的都认为是备用的。我们看如何实现。][standby]

#### 一、继承此装饰器策略，指定哪些实例是standby实例 ####

public class ActiveStandbyESJobStrategy extends JobShardingStrategyActiveStandbyDecorator{
    
        @Override
        protected boolean isStandby(JobInstance jobInstance, String jobName) {
            String activeIps = "10.10.10.1,10.10.10.2";//只有这两个ip的实例才是优先执行的，其他都是备用的
            String ss[] = activeIps.split(",");
            return !Arrays.asList(ss).contains(jobInstance.getIp());//不在active名单的就是后备
        }
    
    }

点击关注公众号，Java干货及时送达![fdab086fa116d9ceb4b0c3d35d031fe6.png][]

很简单吧！这样实现之后，就能达到以下类似的效果

![5ea4eeef46a15731dd6a479838a57122.png][]

#### 二、 在任务启动前，指定使用这个策略 ####

以下以Java的方式示意，

JobCoreConfiguration simpleCoreConfig = JobCoreConfiguration.newBuilder(jobClass.getName(), cron, shardingTotalCount).shardingItemParameters(shardingItemParameters).build();
    SimpleJobConfiguration simpleJobConfiguration = new SimpleJobConfiguration(simpleCoreConfig, jobClass.getCanonicalName());
    return LiteJobConfiguration.newBuilder(simpleJobConfiguration)
            .jobShardingStrategyClass("com.xxx.yyy.job.ActiveStandbyESJobStrategy")//使用主备的分配策略，分主备实例（输入你的实现类类名）
            .build();

这样就大功告成了。

### 同城双活模式 ###

以上这样改造后，针对定时任务就已经解决了两个问题：

1、定时任务能实现在两个机房下的高可用

2、任务能优先调度到指定机房

这种模式下，对于定时任务来说，B机房其实只是个备机房——因为A机房永远都是优先调度的。

对于B机房是否有一些实际问题其实我们可能是不知道的（常见的例如数据库权限没申请），由于没有流量的验证，这时候真的出现容灾问题，B机房是否能安全接受其实并不是100%稳妥的。

我们能否再进一步做到同城双活呢？也就是，B机房也会承担一部分的流量？例如10%？

回到自定义策略的sharding接口：

public Map<JobInstance, List<Integer>> sharding(List<JobInstance> jobInstances, String jobName, int shardingTotalCount)

在做分配的时候，是能拿到一个任务实例的全景图（所有实例列表），当前的任务名，和分片数。

基于此其实是可以做一些事情把流量引流到B机房实例的，例如：

1.  指定任务的主机房让其是B机房优先调度（例如挑选部分只读任务，占10%的任务数）
2.  对于分片的分配，把末尾（如1/10）的分片优先分配给B机房。

以上两种方案都能实现让A、B两个机房都有流量（有任务在被调度），从而实现所谓的双活。

以下针对上面抛出来的方案一，给出一个双活的示意代码和架构。

假设我们定时任务有两个任务，TASK\_A\_FIRST，TASK\_B\_FIRST，其中TASK\_B\_FIRST是一个只读的任务，那么我们可以让他配置读B机房的备库让他优先运行在B机房，而TASK\_A\_FIRST是一个更为频繁的任务，而且带有写操作，我们则优先运行在A机房，从而实现双机房均有流量。

注：这里任意一个机房不可用了，任务均能在另外一个机房调度，这里增强的只是对于不同任务做针对性的优先调度实现双活

public class ActiveStandbyESJobStrategy extends JobShardingStrategyActiveStandbyDecorator{
    
        @Override
        protected boolean isStandby(JobInstance jobInstance, String jobName) {
             String activeIps = "10.10.10.1,10.10.10.2";//默认只有这两个ip的实例才是优先执行的，其他都是备用的
            if ("TASK_B_FIRST".equals(jobName)){//选择这个任务优先调度到B机房
               activeIps = "10.11.10.1,10.11.10.2";
            }
    
            String ss[] = activeIps.split(",");
            return !Arrays.asList(ss).contains(jobInstance.getIp());//不在active名单的就是后备
        }
    
    }

![01c0fb51771f0ae363a2f33d9210fa9c.png][]

![7d2f9d822367e8ade8c907e69d32b833.gif][]

![ca2a4325288398a51861c0e617e1d316.png][]

[![b50d7795ba6e6c4f0db07e4d8f2e1850.png][]][b50d7795ba6e6c4f0db07e4d8f2e1850.png 1]

[![65c4efb50d42530880359a1aa1dcc6bf.png][]][65c4efb50d42530880359a1aa1dcc6bf.png 1]

[![e8998ae98a402f70f385ec2d9b08f075.png][]][e8998ae98a402f70f385ec2d9b08f075.png 1]

[![c8c5cecef87267e9f31f95f8700f9e45.png][]][c8c5cecef87267e9f31f95f8700f9e45.png 1]

[![d378f90924c558bfbfa915295686c6d2.png][]][d378f90924c558bfbfa915295686c6d2.png 1]

**关注Java技术栈看更多干货**

![2d66fcc75d5e0f09d08cbc61e4371d77.png][]

![6482719f4c56ccbd16f5fcfb40e1b10e.gif][]

获取 Spring Boot 实战笔记！

[b09e0c288ad3c863b2d4d96d5451ccf0.png]: /images/20220829/666188b35f3e4994a33530438ffb84c7.png
[5643c57db42a6ad6496e80215b452475.png]: /images/20220829/1d24c477c0264f81980875f286755a4e.png
[5e7456e62bc0c65fbff3c0a30881e4dc.png]: /images/20220829/f6a9219a89d948c98d29229abf408eec.png
[a398534587ef59ae4dca206ce31aedeb.png]: /images/20220829/bffc6231288e4706aeb4b555ff416e92.png
[7d97e0dc8d3c4f795840fc99bf6e43e3.png]: /images/20220829/420ba50e36cf4eb282119224c806aaf9.png
[standby]: http://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&chksm=eb50dc74dc2755627a4245cc1335275b3d29bafaa0d8afb6bfc8584cfe0a2ec81370dc5dde2e&idx=2&mid=2247539010&scene=21&sn=a6bd9401aa639b8f3bc5afe37208f262#wechat_redirect
[fdab086fa116d9ceb4b0c3d35d031fe6.png]: /images/20220829/c604539a6feb4858b35901218422806d.png
[5ea4eeef46a15731dd6a479838a57122.png]: /images/20220829/dc096091e4504b2293ee54a1c7ee8f3c.png
[01c0fb51771f0ae363a2f33d9210fa9c.png]: /images/20220829/fb0cb37f6a394d48aae2c06ef32e405d.png
[7d2f9d822367e8ade8c907e69d32b833.gif]: /images/20220829/88011eb3adb64312af692061bafd58fb.png
[ca2a4325288398a51861c0e617e1d316.png]: /images/20220829/6d7b6613196d4fc68d85a18707b24a16.png
[b50d7795ba6e6c4f0db07e4d8f2e1850.png]: /images/20220829/c57e23c5c9774425a01d880644fcc4f4.png
[b50d7795ba6e6c4f0db07e4d8f2e1850.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&idx=1&mid=2247539795&scene=21&sn=1efca511169265e8146e90db220159d5#wechat_redirect
[65c4efb50d42530880359a1aa1dcc6bf.png]: /images/20220829/08e5292b221f474683975c82b19cebf2.png
[65c4efb50d42530880359a1aa1dcc6bf.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&idx=2&mid=2247539679&scene=21&sn=c197d84d39f21de9f12987e1781d1dfc#wechat_redirect
[e8998ae98a402f70f385ec2d9b08f075.png]: /images/20220829/7a42c1b93c6b46f5848d89360a1824d0.png
[e8998ae98a402f70f385ec2d9b08f075.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&idx=2&mid=2247540613&scene=21&sn=acbe3189c3e5d11419b8f383f36b145f#wechat_redirect
[c8c5cecef87267e9f31f95f8700f9e45.png]: /images/20220829/c853336a4c6d44e9b1ae1d9f463ee0c8.png
[c8c5cecef87267e9f31f95f8700f9e45.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&idx=1&mid=2247537730&scene=21&sn=3869e164e482b838671fa8896cb33cdb#wechat_redirect
[d378f90924c558bfbfa915295686c6d2.png]: /images/20220829/d5f658fe157b4a658775082f4c8a071d.png
[d378f90924c558bfbfa915295686c6d2.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&idx=1&mid=2247539051&scene=21&sn=e59d2d5f0fba696a6b40d7b943e8a707#wechat_redirect
[2d66fcc75d5e0f09d08cbc61e4371d77.png]: /images/20220829/231a7fe80b4a4fd98342e95d560508d7.png
[6482719f4c56ccbd16f5fcfb40e1b10e.gif]: /images/20220829/22c6492eb71445439fa45d93512d5329.png