ElasticJob篇--高频面试题

ElasticJob

1 ElasticJob的失效转移-故障转移-机制是怎样的？

答案：当任务执行失败或者节点宕机时，ElasticJob具备故障转移和重试的能力，能够自动进行故障恢复，确保任务的稳定运行。
底层原理是怎么样的？
底层实现原理就是：Elasticjob的故障恢复机制是通过分布式协调服务-zookeeper和任务节点监听来实现
具体来看就是 每个任务节点再启动的时候都会在zookeeper上创建对应的临时节点，并在该节点上注册一个监听器，当任务节点发生
故障或宕机时，临时节点会被删除，并触发监听器的回调
而其他正常运行的任务节点会收到故障节点的通知，根据根据故障节点的信息，ElasticJob会重新分配故障节点上的任务片段给其他可用的节点，实现任务的故障转移。
而我们可以在配置文件中显示的去开启失效转移–即配置中有个failover属性
failover: 定义是否开启失效转移功能，默认为false，表示不开启失效转移。
maxFailoverCount: 定义最大失效转移次数，默认为0，表示不限制失效转移次数。

2 ElasticJob的分片机制是如何实现的？

首先我们在使用上可以灵活配置作业的分片数， 比如要处理的数据量比较多时可以多加些分片，而在数据量少的时候可以降低分片数量
通过配置shardingParams（分片项）参数和shardingCount分片数量
ElasticJob将一个任务分成多个独立的子任务，每个子任务负责处理一部分数据或者执行一段逻辑。任务分片可以通过配置来指定，也可以根据数据分片算法自动计算，分片数决定了任务被拆分成多少个独立的子任务。
ElasticJob的分片机制是通过将任务数据划分为多个片（shard），并由多个线程并行处理来实现的。每个分片只会被一个线程处理，避免了多个线程处理相同数据的问题。
具体的实现原理如下：
任务分片：
ElasticJob首先根据配置的分片数目将任务数据进行分片。可以使用预定义的分片策略（如平均分配、轮询分配、一致性哈希分配等），也可以自定义分片策略。每个分片包含一部分任务数据。
分片分配：
ElasticJob使用分布式协调服务（如ZooKeeper）来进行分片的动态分配和管理。当任务启动时，各个任务节点会通过分布式协调服务竞争获取可用的分片。每个任务节点会负责处理分配给它的分片。
并行处理：
每个任务节点在获取到分片后，会创建对应数量的线程来并行处理分片中的任务数据。每个线程只会处理属于自己分片的任务数据，避免了重复处理的问题。这样可以提高任务的执行效率和并发能力。

3 ElasticJob任务错过机制(misfire)

misfire的正确用法是用于处理间隔时间长的作业，或者业务有局限的作业。举个例子：
1天跑一次的报表作业，作业的业务逻辑中写死本次作业只抓取昨天的数据。那么一旦上次作业跑动超过一天，那么第二天本该运行的作业就失去了运行的机会，第二天的数据也会缺失。因此需要misfire。
如果业务写的足够好，比如，无论哪天跑都能把未处理的数据分好组生成报表，misfire的存在意义就仅仅是触发时间缩短而已了
而misfire的默认配置为 忽略错过的触发时间，直接执行下一次调度
具体的配置有
ElasticJob提供了多种任务错过处理策略，如MISFIRE_IGNORE_MISFIRES、MISFIRE_FIRE_AND_PROCEED和MISFIRE_DO_NOTHING。
MISFIRE_IGNORE_MISFIRES是默认的处理策略，表示忽略错过的触发时间，直接执行下一次调度。
MISFIRE_FIRE_AND_PROCEED表示错过的触发时间立即执行，然后按照原定的调度频率继续执行。
MISFIRE_DO_NOTHING表示错过的触发时间不执行，等待下一次调度。
开发者可以根据实际需求选择合适的任务错过处理策略。

4 ElasticJob如何确保在同一个Job实例中多个线程不会处理相同的数据

在ElasticJob中，确保在同一个Job实例中多个线程不会处理相同的数据是通过分片（Sharding）策略和分布式锁来实现的。
分片（Sharding）策略：
ElasticJob将任务的数据划分为多个片（Shard），每个片由一个线程处理。
分片策略可以根据业务需求进行配置，例如按照数据ID、时间范围等方式进行划分。
每个线程只处理自己负责的片，从而避免了多个线程处理相同的数据。
分布式锁：
ElasticJob使用分布式锁来保证同一时间只有一个线程能够获取到任务片并执行。
当一个线程获取到分布式锁后，其他线程无法获取到同样的锁，从而避免了多个线程同时处理相同的数据。
通过分片策略和分布式锁的组合，ElasticJob能够确保在同一个Job实例中多个线程不会处理相同的数据。每个线程只处理自己负责的片，并且在处理之前先获取到分布式锁，确保同一时间只有一个线程能够处理该片的数据。

5 什么是ElasticJob？它的主要特点是什么？

ElasticJob是一个分布式任务调度框架，用于处理大规模任务调度。它的主要特点包括灵活性、分布式能力和扩展性。
灵活性：
ElasticJob支持多种任务调度策略，如简单调度、Cron表达式调度等，可以根据不同的业务需求选择合适的调度方式。
支持任务错过机制（misfire），可以根据配置的策略处理错过的触发时间，保证任务的连续性和正确性。
提供了丰富的作业监听器和事件机制，开发者可以通过监听器来实现自定义的业务逻辑，增加灵活性。
分布式能力：
ElasticJob是一个分布式任务调度框架，可以在分布式环境下运行和管理任务。
支持任务分片（Sharding）策略，将任务数据划分为多个片，每个片由一个线程处理，从而实现任务的并行执行。
通过分布式协调服务（如ZooKeeper）来实现任务的分布式协调和管理，确保任务的一致性和可靠性。
扩展性：
ElasticJob提供了丰富的扩展点和插件机制，可以方便地进行功能扩展和定制化开发。
支持自定义作业类型，开发者可以根据自己的需求实现自定义的作业类型，扩展框架的功能。
提供了作业监听器和事件机制，开发者可以通过监听器来实现自定义的业务逻辑，增加框架的灵活性和可扩展性。
总之，ElasticJob具有灵活性、分布式能力和扩展性。它提供了多种任务调度策略、支持任务错过处理、具备分布式能力和分片策略，同时还提供了丰富的扩展点和插件机制，使开发者能够根据不同的需求进行定制化开发和功能扩展。这些特点使得ElasticJob成为一个强大而灵活的分布式任务调度框架。

6 ElasticJob多种任务调度策略对比

ElasticJob提供了多种任务调度策略，每种策略都有不同的特点和适用场景。下面是几种常见的任务调度策略及其区别：
SimpleJobScheduler（简单调度器）：
简单调度器是最基本的调度策略，按照固定的时间间隔执行任务。
适用于需要按照一定频率重复执行的简单任务。
CronJobScheduler（Cron表达式调度器）：
Cron表达式调度器根据Cron表达式来指定任务的执行时间。
可以实现更灵活的调度策略，如每天固定时间执行、每周某天执行等。
适用于需要按照特定时间规则执行的任务。
DataflowJobScheduler（数据流调度器）：
数据流调度器适用于处理数据流的任务，它会根据分片策略将任务数据划分为多个片，并由多个线程并行处理。
每个分片只会被一个线程处理，避免了多个线程处理相同数据的问题。–zookeeper分布式锁
适用于需要并行处理大量数据的任务。
ScriptJobScheduler（脚本调度器）：
脚本调度器可以通过配置脚本来执行任务，支持Shell脚本和JavaScript脚本。
可以灵活地执行各种自定义的脚本任务。
这些任务调度策略在ElasticJob中提供了不同的调度方式，可以根据具体的业务需求选择合适的策略。简单调度器和Cron表达式调度器适用于按照固定时间间隔或特定时间规则执行任务；数据流调度器适用于并行处理大量数据的任务；脚本调度器适用于执行自定义的脚本任务。根据实际情况选择合适的任务调度策略，可以更好地满足业务需求。

7 ElasticJob的高可用性是如何保证的？

ElasticJob通过使用分布式协调服务、主从模式、任务分片和并行处理等机制来保证高可用性。这些特性使得任务能够持续执行，并且在节点故障时能够自动切换和恢复。
ElasticJob通过以下方式来保证高可用性：
分布式协调服务：ElasticJob使用分布式协调服务（如ZooKeeper）来实现任务的分布式协调和管理。分布式协调服务可以提供高可用的集群环境，确保任务的一致性和可靠性。
主从模式：ElasticJob采用主从模式来保证任务的高可用性。在一个分布式环境中，多个作业节点会竞争执行任务，其中一个节点会被选举为主节点，负责任务的调度和管理，其他节点则作为从节点备份主节点的状态信息。当主节点发生故障时，从节点会接管主节点的工作，保证任务的持续执行。
任务分片：ElasticJob支持将任务数据划分为多个片，并由多个线程并行处理。每个分片只会被一个线程处理，避免了多个线程处理相同数据的问题。这种分片机制可以提高任务的并发性和可用性，即使某个节点发生故障，其他节点仍然可以继续处理剩余的分片。
任务错过处理：ElasticJob支持任务错过机制（misfire），可以根据配置的策略处理错过的触发时间。当任务因为某些原因未能按时触发时，可以根据配置的策略来处理错过的任务，保证任务的连续性和正确性。
通过以上机制，ElasticJob能够实现高可用性的任务调度。分布式协调服务提供了可靠的集群环境，主从模式保证了任务的持续执行，任务分片提高了任务的并发性和可用性，任务错过处理保证了任务的连续性。这些特性使得ElasticJob成为一个具有高可用性的分布式任务调度框架。

8 ElasticJob的扩展点有哪些？如何自定义扩展？

ElasticJob提供了多个扩展点，如任务执行器、作业监听器、分片策略等。可以通过实现相应的接口或继承相应的类来自定义扩展，并在配置中进行相应的设置。

9 ElasticJob的任务失败重试机制是如何实现的？

ElasticJob的任务失败重试机制可以通过配置jobProperties属性来设置。可以指定最大重试次数和重试间隔时间，当任务执行失败时，会自动进行重试。

10. ElasticJob与其他任务调度框架（如Quartz）相比有什么优势？

答案：相比于其他任务调度框架，ElasticJob具有更好的分布式能力和高可用性，能够处理大规模任务调度，并且提供了丰富的扩展点和插件机制，可以满足不同场景的需求。

我们维护的elasticjob修复了原先版本的一些bug，这些bug包括幂等，
以及作业失效转移面向的是所有作业节点关闭逻辑，不仅限于作业崩溃关闭，这块做了优化，只针对作业崩溃的节点
之后再原有的分片策略，平均分配，轮训分配，一致性哈希分配，随机分配的基础上又加了
根据作业名的哈希值对服务器列表进行轮转的分片策略
RotateServerByNameJobShardingStrategy，根据作业名的哈希值对作业节点列表进行轮转的分片策略。这里的轮转怎么定义呢？如果有 3 台作业节点，顺序为 [0, 1, 2]，如果作业名的哈希值根据作业分片总数取模为 1, 作业节点顺序变为 [1, 2, 0]。
分片的目的，是将作业的负载合理的分配到不同的作业节点上，要避免分片策略总是让固定的作业节点负载特别大，其它工作节点负载特别小。这个也是为什么官方对比 RotateServerByNameJobShardingStrategy、AverageAllocationJobShardingStrategy
AverageAllocationJobShardingStrategy的缺点是，一旦分片数小于作业作业节点数，作业将永远分配至IP地址靠前的作业节点，导致IP地址靠后的作业节点空闲。如：
OdevitySortByNameJobShardingStrategy则可以根据作业名称重新分配作业节点负载。
如果有3台作业节点，分成2片，作业名称的哈希值为奇数，则每台作业节点分到的分片是：1=[0], 2=[1], 3=[]
如果有3台作业节点，分成2片，作业名称的哈希值为偶数，则每台作业节点分到的分片是：3=[0], 2=[1], 1=[]

参考资料：
https://www.cnblogs.com/hzzjj/category/2081940.html
https://www.infoq.cn/article/2016/09/Mesos-Elastic-Job-Cloud
https://github.com/apache/shardingsphere-elasticjob