Camunda流程引擎并发性能优化

news2024/9/22 1:46:48

文章目录

Camunda流程引擎
一、JobExecutor
- 1、工作流程
- 2、主要作用
二、性能问题
- 1、实际场景：
- 2、性能问题描述
- 3、总结
三、优化方案
- 方案一：修改 Camunda JobExecutor 源码以实现租户 ID 隔离
- 方案二：使用 max-jobs-per-acquisition 参数控制上锁数量

Camunda流程引擎

Camunda流程引擎的详细解读可以查看这篇文章：
https://blog.csdn.net/weixin_44876263/article/details/142332063?sharetype=blogdetail&sharerId=142332063&sharerefer=PC&sharesource=weixin_44876263&spm=1011.2480.3001.8118

一、JobExecutor

1、工作流程

启动：当 Camunda 引擎启动时，JobExecutor 也随之启动，开始准备调度作业。
查询作业：JobExecutor 定期调用 JobService，查询数据库中待执行的作业。这个查询会考虑作业的状态，比如是否被锁定，以避免并发执行。
上锁：在查询到待执行作业后，JobExecutor 会为这些作业上锁，以确保其他实例无法同时处理同一个作业。这是通过更新数据库中的状态来实现的。
执行作业：锁定后，JobExecutor 会尝试执行这些作业。执行过程中，它会处理任何异常情况，比如超时或执行失败。
任务执行后的处理：
- 成功完成：如果作业成功执行，它将被标记为完成，随后从数据库中删除。
- 失败处理：如果作业执行失败，根据配置，可以选择重试或记录错误。重试可能会有次数限制和延迟策略。
- 后续执行：对于需要后续处理的作业，JobExecutor 会在失败时重新调度它们，确保它们能在未来的某个时刻再次被尝试执行。

2、主要作用

在 Camunda BPM 中，JobExecutor 是负责处理异步作业和定时作业的核心组件。它自动管理作业的调度和执行，确保系统能够高效地处理长时间运行的任务和事件。以下是 JobExecutor 的主要作用和功能：

作业调度：
定期查询数据库，查找待执行的作业，包括异步作业和定时作业。
作业执行：
在找到可执行的作业后，JobExecutor 会执行这些作业，确保系统能够按预期处理任务。
并发处理：
支持并发执行多个作业，能够根据配置的线程池大小同时处理多个任务，提高系统的吞吐量。
失败处理：
自动处理执行失败的作业，允许重试逻辑，以确保任务最终能够成功完成。
灵活配置：
可以根据业务需求配置作业的执行频率、并发数量等参数，以优化性能。

二、性能问题

1、实际场景：

在正式的多服务器环境中，当并发产生 1000 个任务实例时，这些任务会被存储为待执行的任务在数据库中。当 JobExecutor 调用 JobService 查询数据库中的待执行任务时，可能会出现以下性能问题：

2、性能问题描述

1、任务并发产生：

在高并发情况下，同时产生 1000 个任务实例，所有任务会迅速积累为待执行状态，增加数据库中的任务总数。

2、查询和上锁机制：

当 JobExecutor 启动并查询待执行的任务时，可能存在某一台服务器一次性获取所有可用任务的情况，导致该服务器迅速上锁大量任务。

3、负载不均衡：

一旦某台服务器获取了大量任务，其他服务器则可能无法获取任务。这种资源分配不均衡会导致部分服务器过载，而其他服务器处于闲置状态，无法充分利用集群资源。

4、性能瓶颈：

随着某台服务器处理所有获取的任务，可能导致该服务器的 CPU、内存等资源消耗过高，从而引发性能瓶颈。此外，数据库也可能因频繁的高负载查询而变得响应缓慢，影响整体系统性能。

3、总结

在考虑多服务器环境下的任务处理时，可能面临以下性能问题：

1. 任务竞争

问题：多个 JobExecutor 实例可能同时争抢相同的作业，导致锁竞争和资源冲突。
影响：竞争会增加数据库负担，降低任务处理效率，导致响应时间延长。

2. 负载不均衡

问题：在使用 max-jobs-per-acquisition 时，某些 JobExecutor 可能会获得更多任务，而其他实例则可能处于闲置状态。
影响：这种不均衡会导致资源利用率降低，可能出现某些服务器过载，而其他服务器闲置的情况。

3. 数据库压力

问题：频繁的数据库查询和作业获取请求可能导致数据库负载增加。
影响：高负载可能导致数据库性能下降，进而影响整体系统的稳定性和响应速度。

4. 任务执行延迟

问题：由于上锁数量或任务竞争的限制，任务的执行可能受到延迟。
影响：延迟会影响用户体验和业务流程的及时性，尤其是在实时性要求较高的场景中。

5. 扩展性问题

问题：随着任务数量的增加，现有的调度和执行机制可能无法有效扩展。
影响：系统可能无法承受更高的负载，导致性能瓶颈和资源浪费。

三、优化方案

提高多服务器环境下的任务处理效率，确保任务的隔离性与资源利用的平衡

方案一：修改 Camunda JobExecutor 源码以实现租户 ID 隔离

目标：

为每台服务器指定一个租户 ID，使得每台服务器仅能查询和处理其对应租户的任务，从而提高任务的隔离性和资源利用效率。
实现步骤：
1. 租户 ID 支持：
  - 在 JobExecutor 中引入租户 ID 的概念，使其能够识别和区分不同租户的作业。
2. 查询作业时的过滤：
  - 在作业查询逻辑中，增加对租户 ID 的过滤，确保每台服务器仅获取与其租户 ID 相关的作业。
3. 数据库查询修改：
  - 根据需要调整相关数据库查询，以支持租户 ID 的使用。
优点：
1. 高隔离性：每个服务器只处理特定租户的任务，显著降低了任务之间的竞争。
2. 管理灵活性：可以独立管理各个租户的负载，便于监控和维护。
缺点：
1. 维护复杂性：需要维护自定义源码，增加了系统的复杂性。
2. 升级难度：在升级 Camunda 时，可能需要重新合并修改的代码，增加了维护成本。

代码实现示例：

租户 ID 支持，创建实例时引入租户概念：
查询作业时的过滤：

修改org.camunda.bpm.engine.impl.persistence.entity.JobManager中的findNextJobsToExecute方法

数据库查询修改：

修改org.camunda.bpm.engine.impl.persistence.entity.JobEntity中的selectNextJobsToExecute查询待执行任务方法

方案二：使用 max-jobs-per-acquisition 参数控制上锁数量

目标：
通过设置 max-jobs-per-acquisition 参数，控制每次获取作业时的上锁数量，以避免单台服务器获取过多任务。
实现步骤：
1. 配置参数：
  - 在 Camunda 的配置文件中设置 max-jobs-per-acquisition，例如：
```
camunda:
  bpm:
    job-execution:
      max-jobs-per-acquisition: 10  # 每次从数据库中查询时，最多锁定并执行 10 个作业
```
2. 任务调度：
  - 确保系统根据这个参数进行作业调度，以控制并发作业的处理。
优点：
1. 简单易行：
  - 不需要修改源码，便于快速调整系统配置。
2. 灵活性：
  - 能够根据需求迅速调整上锁数量，以优化性能。
缺点：
1. 竞争可能性：
  - 多个 JobExecutor 实例可能同时查询相同的作业，导致资源竞争加剧，特别是在高负载情况下。
2. 负载不均：
  - 由于任务调度是随机的，可能导致某些 JobExecutor 获取更多任务，而其他实例闲置，造成资源利用不均。