java面试微服务篇_seta面试题-CSDN博客

Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式。临时实例心跳不正常会被剔除，非临时实例则不会被剔除。
Nacos支持服务列表变更的消息推送模式，服务列表更新更及时。
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式。

Nacos与Eureka的区别（配置中心）

Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

负载均衡

负载均衡流程

Ribbon负载均衡策略

RoundRobinRule：简单轮询服务列表来选择服务器
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
RandomRule：随机选择一个可用的服务器
BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
RetryRule：重试机制的选择逻辑
AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例 ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询

自定义负载均衡策略

方法一：创建类实现IRule接口，可以指定负载均衡策略（全局）。

方法二：在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）

熔断、降级

服务雪崩

一个服务失败，导致整条链路的服务都失败的情形。

服务降级

服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃。

代码实现：

通过feign进行远程调用，并规定服务降级逻辑。

服务降级逻辑

如果降级太多，则会触发熔断机制。

服务熔断

Hystrix 熔断机制，用于监控微服务调用情况，默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker 如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。

服务监控

为什么需要监控

问题定位
性能分析
服务关系
服务告警

服务监控的组件

Springboot-admin
prometheus+Grafana
zipkin 链路追踪工具
skywalking 链路追踪工具

skywalking

一个分布式系统的应用程序性能监控工具（ Application Performance Managment ），提供了完善的链路追踪能力， apache的顶级项目（前华为产品经理吴晟主导开源）。

1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。

2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复。

业务相关

限流

为什么要限流

并发量大（突发流量）
防止用户恶意刷接口

下面解释一下几个专有名词QPS、TPS

QPS

Queries Per Second，每秒查询数。每秒能够响应的查询次数。

QPS 是一台服务器每秒能够相应的查询次数，即1秒内完成的请求数量，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准

QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。每秒的响应请求数，也即是最大吞吐能力。

TPS

Transactions Per Second 的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。

TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。

例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“T”，产生三个“Q”。

QPS 与 TPS 区别

QPS基本类似于TPS，但是不同的是，对于一个Web页面的一次访问，形成一个TPS（就做一件事儿，打开Web网页）；但一次Web页面请求，可能产生多次对服务器的请求（html、css、js、images、files等），服务器对这些请求，就可计入QPS之中。每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么TPS等于QPS，否则，若这个接口内部还会再去请求其它接口（下载图片、文件等服务器接口），那么 TPS不等于QPS，通常是 QPS会大于TPS，因为此时一个事务通常包含多次查询请求。

限流的实现方式

Tomcat：可以设置最大连接数
Nginx，漏桶算法
网关，令牌桶算法
自定义拦截器

Nginx限流（漏桶算法）

控制速率（突发流量）

语法：limit_req_zone key zone rate

key:定义限流对象，binary_remote_addr就是一种key，基于客户端ip限流
Zone：定义共享存储区来存储访问信息，10m可以存储16wip地址访问信息
Rate：最大访问速率，rate=10r/s 表示每秒最多请求10个请求
burst=20：相当于桶的大小
Nodelay：快速处理

控制并发连接数

limit_conn perip 20：对应的key是 $binary_remote_addr，表示限制单个IP同时最多能持有20个连接。
limit_conn perserver 100：对应的key是 $server_name，表示虚拟主机(server) 同时能处理并发连接的总数。

网关限流（令牌桶算法）

yml配置文件中，微服务路由设置添加局部过滤器RequestRateLimiter

key-resolver ：定义限流对象（ ip 、路径、参数），需代码实现，使用spel表达式获取
replenishRate ：令牌桶每秒填充平均速率。
burstCapacity ：令牌桶总容量。

分布式事务

CAP定理

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标： Consistency（一致性） Availability（可用性） Partition tolerance （分区容错性） Eric Brewer 说，分布式系统无法同时满足这三个指标。这个结论就叫做 CAP 定理。

CAP定理- Consistency

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

CAP定理- Availability

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

CAP定理-Partition tolerance

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。

结论：

分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的
如果保证访问的高可用性（A）,可以持续对外提供服务，但不能保证数据的强一致性-->AP
如果保证访问的数据强一致性（C）,就要放弃高可用性 --> CP

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

Seata框架

Seata架构

Seata事务管理中有三个重要的角色：

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

seata的XA模式

该模式满足CAP定理中的CP，保证了强一致性，但是性能不强。

RM一阶段的工作：

注册分支事务到TC
执行分支业务sql但不提交
报告执行状态到TC

TC二阶段的工作：

TC检测各分支事务执行状态
如果都成功，通知所有RM提交事务
如果有失败，通知所有RM回滚事务

RM二阶段的工作：

接收TC指令，提交或回滚事务

seata的AT模式

该模式满足CAP定理中的AP，性能强，但是无法保证强一致性。

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

阶段一RM的工作：

注册分支事务
记录undo-log（数据快照）
执行业务sql并提交
报告事务状态

阶段二提交时RM的工作：

删除undo-log即可

阶段二回滚时RM的工作：

根据undo-log恢复数据到更新前

seta的TCC模式

该模式满足CAP定理中的AP，性能强，但是无法保证强一致性。

Try：资源的检测和预留。
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

MQ模式实现分布式事务

在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好，但是一致性很差。

分布式服务接口幂等

幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。

需要幂等场景：

用户重复点击(网络波动)
MQ消息重复
应用使用失败或超时重试机制

接口幂等

基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析

请求方式	说明
GET	查询操作，天然幂等
POST	新增操作，请求一次与请求多次造成的结果不同，不是幂等的
PUT	更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，则不是幂等的
DELETE	删除操作，根据唯一值删除，是幂等的

token+redis解决接口幂等问题

应用场景：创建商品、提交订单、转账、支付等操作。

在查看商品的页面生成token

在提交订单的页面进行token验证

分布式锁解决接口幂等问题

需要注意的是要让请求快速失败（抢不到锁的线程），控制锁的粒度。根据具体的业务逻辑来控制锁的粒度，

以下是一些常见的策略来控制分布式锁的粒度：

1.方法级别锁：

这是锁的最小粒度，通常用于确保同一个用户（或会话）对某个特定方法的多次调用不会产生副作用。
例如，对于用户支付操作，可以使用用户ID和支付订单号作为锁的key。

2.业务逻辑级别锁：

当一个操作涉及到多个方法或者资源时，可以使用业务逻辑级别的锁。
例如，一个操作需要更新数据库并调用外部服务，可以使用操作的业务标识作为锁的key。

3.资源级别锁：

当需要锁定某个特定资源时使用，如库存、座位等。
例如，在处理减库存操作时，可以使用商品ID作为锁的key。

4.服务级别锁：

在服务级别上应用锁，通常用于确保整个服务的某个部分不会被并发执行。
例如，一个服务可能有多个接口，但某些操作需要确保整个服务在执行过程中不被其他请求干扰。

控制锁粒度时，需要考虑以下几点：

并发性：更细粒度的锁可以提供更高的并发性，但可能会增加系统的复杂性。
性能：细粒度锁可能导致频繁的锁获取和释放，这可能会影响性能。
死锁风险：过多的锁可能会导致死锁的风险增加。
业务场景：根据具体的业务场景和需求来决定锁的粒度。

在实际应用中，通常需要在并发控制和性能之间找到平衡点。过粗的锁粒度可能会导致性能瓶颈，而过细的锁粒度可能会增加系统的复杂性。

public void saveOrder(Item item) throws InterruptedException {
   //获取锁（重入锁），执行锁的名称
  RLock lock = redissonClient.getLock("heimalock");
    //尝试获取锁，参数分别是：获取锁的最大等待时间（期间会重试），锁自动释放时
//间时间单位
  boolean isLock = lock.tryLock(10, TimeUnit.SECONDS);
    try {
        //判断是否获取成功
    if (!isLock) {
          log.info("下单操作获取锁失败,order:{}",item);
           throw new RuntimeException("新增或修改失败");
        }
        //下单操作
            } finally {
       //释放锁
   lock.unlock();
    }
}

分布式任务调度

xxl-job

具体的xxl-job使用教学请看下面这篇博客

XXL-JOB的使用(详细教程)-CSDN博客

解决的问题

解决集群任务的重复执行问题
cron表达式定义灵活
定时任务失败了，重试和统计
任务量大，分片执行

路由策略

路由策略就是指的以某种规则将任务交给执行器（微服务）去执行。

下面是常见的路由策略：

FIRST（第一个）：固定选择第一个机器；
LAST（最后一个）：固定选择最后一个机器；
ROUND（轮询）
RANDOM（随机）：随机选择在线的机器；
CONSISTENT_HASH（一致性HASH）：每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。
LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举；
LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举；
FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度；
BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度；
SHARDING_BROADCAST(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；

解决任务执行失败

将路由规则设置为故障转移并且设置失败重试：

查看日志分析：

邮件告警：

大数据量任务需同时执行

执行器集群部署时，任务路由策略选择分片广播情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务。

执行器需要定义的任务代码

分片参数

index：当前分片序号(从0开始)，执行器集群列表中当前执行器的序号；
total：总分片数，执行器集群的总机器数量；

@XxlJob("shadingSample")
public void shardingJobHandler() throws Exception {
    // 分片参数
    int shardIndex = XxlJobHelper.getShardIndex();
    int shardTotal = XxlJobHelper.getShardTotal();
    XxlJobHelper.log("分片参数：当前分片序号 = {}, 总分片数 = {}", shardIndex, shardTotal);
    // 业务逻辑
    List<Integer> list = getList();
    for (Integer integer : list) {
        if(integer % shardTotal == shardIndex){
           System.out.println("第"+shardIndex+"分片执行，执行数据为："+integer);
        }
    }
}

常见面试题

面试官：Spring Cloud 5大组件有哪些？

候选人：

早期我们一般认为的Spring Cloud五大组件是

Eureka : 注册中心

Ribbon : 负载均衡

Feign : 远程调用

Hystrix : 服务熔断

Zuul/Gateway : 网关

随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件

注册中心/配置中心 Nacos

负载均衡 Ribbon

服务调用 Feign

服务保护 sentinel

服务网关 Gateway

面试官：服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？

候选人：

我理解的是主要三块大功能，分别是服务注册、服务发现、服务状态监控

我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件

服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等

服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用

服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

面试官：我看你之前也用过nacos、你能说下nacos与eureka的区别？

候选人：

我们当时xx项目就是采用的nacos作为注册中心，选择nacos还要一个重要原因就是它支持配置中心，不过nacos作为注册中心，也比eureka要方便好用一些，主要相同不同点在于几点：

共同点

Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测

Nacos与Eureka的区别

①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

②临时实例心跳不正常会被剔除，非临时实例则不会被剔除

③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

面试官：你们项目负载均衡如何实现的 ?

候选人：

是这样~~

在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单

当发起远程调用时，ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询

面试官：Ribbon负载均衡策略有哪些 ?

候选人：

我想想啊，有很多种，我记得几个：

RoundRobinRule：简单轮询服务列表来选择服务器

WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小

RandomRule：随机选择一个可用的服务器

ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)

面试官：如果想自定义负载均衡策略如何实现 ?

候选人：

提供了两种方式：

1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用

2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用

面试官：什么是服务雪崩，怎么解决这个问题？

候选人：

服务雪崩是指一个服务失败，导致整条链路的服务都失败的情形，一般我们在项目解决的话就是两种方案，第一个是服务降级，第二个是服务熔断，如果流量太大的话，可以考虑限流

服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑

服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

面试官：你们的微服务是怎么监控的？

候选人：

我们项目中采用的skywalking进行监控的

1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。

2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

面试官：你们项目中有没有做过限流 ? 怎么做的 ?

候选人：

我当时做的xx项目，采用就是微服务的架构，因为xx因为，应该会有突发流量，最大QPS可以达到2000，但是服务支撑不住，我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。

【版本1】

我们当时采用的nginx限流操作，nginx使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量，我们控制的速率是按照ip进行限流，限制的流量是每秒20

【版本2】

我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法，可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量

面试官：限流常见的算法有哪些呢？

候选人：

比较常见的限流算法有漏桶算法和令牌桶算法

漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果

令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用

它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法

面试官：什么是CAP理论？

候选人：

CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性

一致性(Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。

可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

面试官：为什么分布式系统中无法同时保证一致性和可用性？

候选人：

嗯，是这样的~~

首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。

如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。

如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。

面试官：什么是BASE理论？

候选人：

嗯，这个也是CAP分布式系统设计理论

BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：

1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。

2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

面试官：你们采用哪种分布式事务解决方案？

候选人：

我们当时是xx项目，主要使用到的seata的at模式解决的分布式事务

seata的AT模型分为两个阶段：

1、阶段一RM的工作：① 注册分支事务 ② 记录undo-log（数据快照）③ 执行业务sql并提交 ④报告事务状态

2、阶段二提交时RM的工作：删除undo-log即可

3、阶段二回滚时RM的工作：根据undo-log恢复数据到更新前

at模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性

面试官：分布式服务的接口幂等性如何设计？

候选人：

嗯，我们当时有一个xx项目的下单操作，采用的token+redis实现的，流程是这样的

第一次请求，也就是用户打开了商品详情页面，我们会发起一个请求，在后台生成一个唯一token存入redis，key就是用户的id，value就是这个token，同时把这个token返回前端

第二次请求，当用户点击了下单操作会后，会携带之前的token，后台先到redis进行验证，如果存在token，可以执行业务，同时删除token；如果不存在，则直接返回，不处理业务，就保证了同一个token只处理一次业务，就保证了幂等性

面试官：xxl-job路由策略有哪些？

候选人：

xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播…

面试官：xxl-job任务执行失败怎么解决？

候选人：

有这么几个操作

第一：路由策略选择故障转移，优先使用健康的实例来执行任务

第二，如果还有失败的，我们在创建任务时，可以设置重试次数

第三，如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决

面试官：如果有大数据量的任务同时都需要执行，怎么解决？

候选人：

我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播

在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了