1. 从一个真实困惑说起：为什么我的定时任务总在单机上打转
刚接触分布式定时任务那会儿，我遇到过一个很典型的问题：明明部署了三台机器，任务配置也写的是分片模式，可每次跑起来，日志里只有一台机器在干活，另外两台像没事人一样干看着。当时第一反应是集群没组起来，查了注册中心，三个实例都在；又怀疑是任务配置写错了，翻来覆去看了好几遍，shardingTotalCount也设成了 3。折腾了大半天，最后才定位到问题出在作业分片策略上——默认的分片策略在某些场景下会把所有分片都塞给同一个实例。
这件事让我意识到，Elastic-Job-Lite 这套框架里，分片策略虽然只是配置项里的一个字符串，但它直接决定了任务能不能真正并行起来。很多人用 Elastic-Job-Lite 的时候，注意力都放在"怎么把任务跑起来"上，对分片策略往往是一笔带过，等到任务量上来了、机器扩了，才发现性能根本没提升。这篇内容就围绕 Elastic-Job-Lite 的作业分片策略展开，把源码层面的实现逻辑、几种内置策略的差异、以及实际选型时的判断依据讲清楚。适合已经用过 Elastic-Job-Lite、但对分片机制还停留在"配置一下就行"阶段的开发者，也适合正在做分布式任务调度选型、想搞清楚分片底层逻辑的技术负责人。
需要先说明的是，Elastic-Job-Lite 的分片策略本质上是一个接口契约，框架只负责在合适的时机调用它，具体怎么分、按什么规则分，完全由实现类决定。理解这一点，后面看源码就不会迷路。
2. 分片策略在整体调度链路中的位置
2.1 分片到底解决的是什么问题
在单机时代，一个定时任务就是一个线程在跑，任务处理的数据量大了，要么加机器做集群，要么把任务拆成多个子任务手动分配。Elastic-Job-Lite 的分片机制，本质上是把"一个任务"在逻辑上切成 N 份，每份叫一个分片项（sharding item），然后把这些分片项分配给集群里的各个作业实例去执行。
举个具体的例子：假设有一个任务需要处理 100 万条订单数据，集群里有 3 台机器，shardingTotalCount设为 3。理想情况下，每台机器分到 1 个分片项，各自处理大约 33 万条数据，总耗时降到单机的三分之一左右。但实际能不能达到这个效果，取决于分片策略怎么把 3 个分片项分给 3 个实例。
这里有个容易被忽略的点：分片项的数量和实例数量不一定相等。如果shardingTotalCount设为 10，集群只有 3 个实例，那么有的实例会分到 4 个分片项，有的分到 3 个。分片策略要处理的就是这种"分片项如何映射到实例"的问题。
2.2 分片发生的时机：不是启动时一次性算完
很多人以为分片是在任务启动时算一次就固定了，实际上 Elastic-Job-Lite 的分片是动态的。触发重新分片的时机主要有这么几个：
- 集群中有新的作业实例上线
- 有作业实例下线（正常关闭或宕机）
- 分片总数
shardingTotalCount配置发生变化 - 主节点发生选举切换
每次触发重新分片，框架都会重新走一遍分片流程：先由主节点（leader）收集当前所有存活的作业实例列表，然后调用配置的分片策略，计算出"哪个分片项归哪个实例"，最后把结果写入注册中心。各个实例再从注册中心读取属于自己的分片项，开始执行。
这个设计带来的一个直接后果是：分片策略的实现必须是幂等且可重复执行的。因为同一个集群状态可能被多次分片，策略不能依赖上一次的分片结果，每次都要能独立算出一套完整的分片方案。
2.3 分片策略接口的核心方法
Elastic-Job-Lite 中分片策略的顶层接口是JobShardingStrategy，核心方法签名大致是这样的：
List<ShardingItem> sharding( List<JobInstance> jobInstances, String jobName, int shardingTotalCount );三个入参的含义分别是：
jobInstances：当前存活的作业实例列表，已经按某种规则排好序jobName：作业名称，某些策略可能会用到shardingTotalCount：分片总数
返回值是一个ShardingItem列表，每个元素包含"分片项索引"和"分配到的实例"。框架拿到这个列表后，会按实例分组，把属于同一个实例的分片项打包下发。
理解了这个接口，再看具体策略的实现就非常清晰了——无非就是"怎么把shardingTotalCount个分片项，合理地分配给jobInstances里的实例"。
3. 三种内置分片策略的源码级拆解
Elastic-Job-Lite 内置了三种分片策略，分别对应不同的分配逻辑。下面逐个拆解它们的实现思路和适用场景。
3.1 AverageAllocationJobShardingStrategy：平均分配
这是默认的分片策略，也是用得最多的一种。它的核心思想是"尽量平均分，余数依次摊"。
源码逻辑大致是这样的：先算出每个实例至少能分到几个分片项，用shardingTotalCount / jobInstances.size()取整；然后算余数shardingTotalCount % jobInstances.size()；接着按实例顺序，前余数个实例各多分一个分片项。
举个例子，shardingTotalCount = 10，实例数 = 3：
- 基础值 = 10 / 3 = 3
- 余数 = 10 % 3 = 1
- 结果：第 1 个实例分 4 个，第 2 个分 3 个，第 3 个分 3 个
分片项的分配是连续的，也就是说第 1 个实例拿到的是分片项 0、1、2、3，第 2 个拿到 4、5、6，第 3 个拿到 7、8、9。这种连续分配有个好处：如果分片项和数据范围有对应关系（比如按 ID 取模），连续分片能让每个实例处理的数据在逻辑上更集中，减少跨实例的数据竞争。
但这个策略有个明显的短板：它假设所有实例的处理能力是一样的。如果集群里机器配置参差不齐，或者某个实例上还跑着其他吃资源的任务，平均分配就会导致"弱的实例拖后腿"。另外，当实例数远大于分片数时，会有大量实例分不到任何分片项，白白占着资源。
3.2 OdevitySortByNameJobShardingStrategy：按名称奇偶排序
这个策略的名字有点长，但逻辑不复杂。它先根据作业名称的哈希值判断奇偶，然后决定实例列表是按正序还是倒序排列，最后再调用平均分配的逻辑。
为什么要搞这么一出？核心目的是让同一个作业在不同集群环境下，分片结果尽量稳定。假设有两个集群跑同一个作业，如果实例列表的排序规则不一致，可能导致分片结果差异很大。通过作业名称的哈希来决定排序方向，可以让分片结果在一定程度上可预测。
不过说实话，这个策略在实际项目里用得不多。它解决的是一个比较边缘的问题，而且"按名称哈希决定排序"这个规则本身也谈不上多优雅。除非你有明确的跨集群一致性需求，否则没必要特意选它。
3.3 RotateServerByNameJobShardingStrategy：按名称轮转
这个策略的思路是：根据作业名称的哈希值，对实例列表做一次轮转（rotate），然后再走平均分配。
轮转的意思是，把实例列表看成一个环，从某个位置开始重新排列。比如实例列表是[A, B, C]，轮转 1 位后变成[B, C, A]。这样做的效果是：不同的作业，即使实例列表相同，分片结果也会错开。
这个策略的价值在于避免热点集中。假设集群里有多个作业，如果都用平均分配，那么排在前面的实例总是分到更多的分片项（因为余数优先给前面的）。时间一长，前面的实例负载明显偏高。用轮转策略，不同作业的"优先实例"不一样，负载就能摊开。
三种策略的对比可以整理成下面这张表：
| 策略名称 | 核心逻辑 | 适用场景 | 主要缺点 |
|---|---|---|---|
| AverageAllocation | 平均分，余数依次摊 | 实例配置一致、作业数量少 | 实例能力不均时负载失衡 |
| OdevitySortByName | 按名称奇偶决定排序方向后平均分 | 需要跨集群分片一致性 | 规则较隐晦，收益有限 |
| RotateServerByName | 按名称轮转实例列表后平均分 | 多作业共存、避免热点集中 | 单作业场景下与平均分配无异 |
4. 自定义分片策略：什么时候需要，怎么写
4.1 内置策略搞不定的几种情况
内置的三种策略覆盖了大部分常规场景，但有几类需求它们确实处理不了：
第一类是实例能力差异化。比如集群里有的机器是 8 核 16G，有的是 4 核 8G，平均分配显然不合理，应该让强机器多分几个分片项。内置策略完全不考虑实例的硬件信息，因为它根本拿不到这些数据。
第二类是分片项与数据有强绑定关系。比如分片项 0 专门处理北京的数据，分片项 1 处理上海的数据，这种场景下你希望特定分片项落到特定实例上，而不是让框架随便分。
第三类是需要考虑实例的实时负载。比如某个实例当前 CPU 已经跑满了，就不应该再给它分新的分片项。这需要策略实现能读取外部监控数据。
遇到这些情况，就得自己实现JobShardingStrategy接口。
4.2 一个可落地的自定义策略示例
假设我们要实现一个"按实例权重分配"的策略，权重信息存在配置里。核心思路是：先算出总权重，然后按权重比例分配分片项，余数给权重最高的实例。
public class WeightedJobShardingStrategy implements JobShardingStrategy { @Override public List<ShardingItem> sharding(List<JobInstance> jobInstances, String jobName, int shardingTotalCount) { List<ShardingItem> result = new ArrayList<>(); // 获取每个实例的权重，这里简化为从实例ID哈希映射 Map<String, Integer> weights = new HashMap<>(); int totalWeight = 0; for (JobInstance instance : jobInstances) { int weight = getWeight(instance); weights.put(instance.getInstanceId(), weight); totalWeight += weight; } int assigned = 0; int itemIndex = 0; for (int i = 0; i < jobInstances.size(); i++) { JobInstance instance = jobInstances.get(i); int weight = weights.get(instance.getInstanceId()); // 按权重比例计算该实例应得的分片数 int count; if (i == jobInstances.size() - 1) { count = shardingTotalCount - assigned; // 最后一个实例兜底 } else { count = (int) Math.floor( (double) shardingTotalCount * weight / totalWeight); } for (int j = 0; j < count; j++) { result.add(new ShardingItem(itemIndex++, instance.getInstanceId())); } assigned += count; } return result; } private int getWeight(JobInstance instance) { // 实际项目中可以从配置中心或实例元数据读取 return 1; } }这段代码有几个关键点值得说明：
- 最后一个实例兜底：浮点运算会有精度问题，按比例算出来的分片数加起来可能不等于总数，所以最后一个实例直接拿剩余的全部，保证分片项不丢。
- 分片项索引连续分配：和内置策略保持一致，便于后续按分片项做数据处理。
- 权重来源：示例里简化成了固定值，实际使用时可以从实例启动时注册的元数据里读，或者从配置中心动态拉取。
4.3 注册自定义策略的两种方式
写好了策略类，还得让框架知道用它。Elastic-Job-Lite 提供了两种注册方式：
方式一：SPI 扩展。在META-INF/services目录下创建JobShardingStrategy文件，内容写实现类的全限定名。这种方式的好处是配置里直接写策略名就行，不需要改代码。
方式二：API 显式设置。在构建JobCoreConfiguration或LiteJobConfiguration的时候，通过jobShardingStrategyClass指定实现类的全限定名。这种方式更直接，适合策略类不多、不想折腾 SPI 的场景。
LiteJobConfiguration.newBuilder( JobCoreConfiguration.newBuilder("myJob", "0/10 * * * * ?", 10) .build()) .jobShardingStrategyClass("com.example.WeightedJobShardingStrategy") .build();注意：自定义策略类必须有一个无参构造函数，框架是通过反射实例化的。如果策略初始化需要读取配置，建议在
sharding方法内部懒加载，而不是放在构造函数里。
5. 分片策略选型与调优的实战经验
5.1 分片总数怎么定，不是拍脑袋
shardingTotalCount这个值设多少，直接决定了分片的粒度。设得太小，并行度不够；设得太大，分片管理本身的开销就上来了。
我的经验是：分片总数最好是实例数的整数倍，且留有一定的扩展余量。比如当前有 3 台机器，预计半年内可能扩到 6 台，那分片总数可以设成 6 或 12。这样扩容的时候，分片能均匀重新分配，不会出现"加了机器但分片分不匀"的尴尬。
另外，分片总数和任务的执行频率也有关系。高频任务（比如每秒执行一次）如果分片数太多，每次分片切换的开销可能比任务本身还大。低频任务（比如每天一次）则可以设得细一些，充分利用并行度。
5.2 分片不均匀的排查思路
如果发现任务跑起来负载明显不均，可以按这个顺序排查：
第一步，确认分片结果。Elastic-Job-Lite 会把分片结果写到注册中心的节点上，直接去看/jobName/sharding路径下的内容，能看到每个分片项对应的实例。如果分片结果本身就是均匀的，那问题不在策略上，而在任务执行逻辑里。
第二步，检查实例列表的顺序。分片策略拿到的jobInstances是排过序的，排序规则会影响分配结果。如果实例 ID 的生成规则导致排序后总是同一批实例排在前面，余数就会一直落在它们头上。
第三步，看是不是任务本身的问题。有时候分片是均匀的，但某个分片项对应的数据量特别大，导致处理它的实例看起来"很忙"。这种情况要调整的是数据分片逻辑，而不是分片策略。
5.3 一个容易踩的坑：分片项与线程池的关系
Elastic-Job-Lite 默认会给每个分片项分配一个独立的线程去执行。如果分片总数设得很大，而实例的线程池配置又比较小，就会出现分片项排队等待线程的情况。表面上看分片是均匀的，实际上很多分片项在排队，并行度根本没上去。
这个坑的隐蔽之处在于：日志里能看到所有分片项都"开始执行"了，但实际的处理时间被拉得很长。排查的时候要关注线程池的活跃线程数和队列长度，而不是只看分片结果。
提示：
shardingTotalCount的值建议不要超过单实例线程池最大线程数的 2 到 3 倍，否则排队现象会很明显。
6. 分片策略与失效转移、错过执行的配合
6.1 失效转移时分片策略还起作用吗
作业实例宕机后，它负责的分片项需要转移给其他存活实例。这个转移过程不走分片策略，而是由框架的失效转移机制直接处理——把宕机实例的分片项标记为"待转移"，然后由主节点分配给当前存活的实例。
这意味着：如果你依赖自定义分片策略来做负载均衡，失效转移场景下这个均衡会被打破。转移过来的分片项是"额外"加给存活实例的，可能导致某些实例负载骤增。要缓解这个问题，可以在任务执行逻辑里做动态的限流或降级，而不是完全依赖分片策略。
6.2 错过执行的分片补偿
当实例下线再上线，或者分片重新分配后，某些分片项可能会"错过"本该执行的时间点。Elastic-Job-Lite 提供了monitorExecution和failover等配置来控制补偿行为。
这里要注意的是：分片策略决定了"谁来做"，但不决定"做不做"。补偿逻辑是独立于分片策略的。如果发现任务有漏执行，先检查补偿相关的配置，而不是去改分片策略。
7. 写在最后的一点个人体会
分片策略这个东西，刚上手的时候觉得就是个配置项，用久了才发现它是分布式任务调度里最需要"因地制宜"的部分。内置的三种策略能覆盖七八成的场景，但剩下那两三成，往往才是真正考验设计能力的地方。
我自己在项目里用得最多的还是默认的平均分配，配合合理的shardingTotalCount设置，大部分场景都能跑得不错。真正需要自定义策略的时候，通常是遇到了实例能力差异或者数据亲和性的硬需求。这时候与其硬套内置策略，不如老老实实写一个，代码量其实不大，但效果立竿见影。
还有一点想提醒：分片策略的调整一定要配合监控。光看分片结果均不均匀是不够的，还要看每个实例的实际处理耗时、线程池状态、以及任务的整体完成时间。分片是手段，不是目的，最终要的是任务跑得快、跑得稳。
