Camunda流程引擎并发性能优化

文章目录

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 时，可能需要重新合并修改的代码，增加了维护成本。

代码实现示例：

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

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

1. 数据库查询修改：

• 修改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 获取更多任务，而其他实例闲置，造成资源利用不均。