1. Elastic-Job源码使用lombok实现极简代码。
这点在我当前负责的多个工程项目代码中都有使用，以后可以进一步借鉴使用。话说“极简代码”，我还是第一次见到这种叫法。
2.注册中心的最终配置以哪个客户端的配置为准？
Elastic-Job-Lite采用无中心化设计，若每个客户端的配置不一致，不做控制的话，最后一个启动的客户端配置将会成为注册中心的最终配置。
Elastic-Job-Lite提出了overwrite概念，可通过JobConfiguration或Spring命名空间配置。overwrite=true即允许客户端配置覆盖注册中心，反之则不允许。如果注册中心无相关作业的配置，则无论overwrite是否配置，客户端配置都将写入注册中心。
现身说法：我实际工作中的情况是这样的，相同的工程代码，即使部署多地，用的是同一处的配置，都是使用的分布式配置管理平台disconf来进行管理的，这种方式从源头上就解决了客户端配置不一致的问题。
3. Elastic-Job有何使用限制?
（1）作业启动成功后修改作业名称视为新作业，原作业废弃。
（2）同一台作业服务器可以运行多个相同的作业实例，但每个作业实例必须使用不同的JobInstanceId，因为作业运行时是按照IP和JobInstanceId注册和管理的。
JobInstanceId可在作业配置中设置。
其实在我看来，把作业实例的id改掉了还能算是相同的作业实例吗？
（3）一旦有服务器波动，或者修改分片项，将会触发重新分片；触发重新分片将会导致运行中的流式处理的作业在执行完本次作业后不再继续执行，等待分片结束后再恢复正常。
4.如何保证不会在多个作业服务器运行同一个分片
开启monitorExecution（监控作业运行时状态）才能实现分布式作业幂等性（即不会在多个作业服务器运行同一个分片）的功能，但monitorExecution对短时间内执行的作业（如每5秒一触发）性能影响较大，建议关闭并自行实现幂等性。
每次作业执行时间和间隔时间均非常短的情况，建议不监控作业运行时状态以提升效率。因为是瞬时状态，所以无必要监控。请用户自行增加数据堆积监控。并且不能保证数据重复选取，应在作业中实现幂等性。
每次作业执行时间和间隔时间均较长的情况，建议监控作业运行时状态，可保证数据不会重复选取。
5. 注册中心与作业部署机无从属关系
elastic-job-lite为jar包，由开发或运维人员负责启动。启动时自动向注册中心注册作业信息并进行分布式协调，因此并不需要手工在注册中心填写作业信息。 但注册中心与作业部署机无从属关系，注册中心并不能控制将单点的作业分发至其他作业机，也无法将远程服务器未启动的作业启动
6. 作业暂停和作业失效的区别
作业暂停和失效都会停止当前节点作业的运行。但作业暂停和恢复不会触发重分片，而作业失效和生效将触发重分片。
7. 作业与注册中心无法通信会如何？
为了保证作业的在分布式场景下的一致性，一旦作业与注册中心无法通信，运行中的作业会立刻停止执行，但作业的进程不会退出，这样做的目的是为了防止作业重分片时，将与注册中心失去联系的节点执行的分片分配给另外节点，导致同一分片在两个节点中同时执行。 当作业节点恢复与注册中心联系时，将重新参与分片并恢复执行新的分配到的分片。
8. elastic-job的分片策略
一般情况Elastic-Job是通过平均分配算法的分片策略数据的，但也可以选择哈希及轮转等策略，或者自己定义作业分片策略。
