1. 从零开始Activiti7数据库表结构全景图如果你刚接触Activiti7打开数据库看到几十张以“ACT_”开头的表是不是有点懵别慌我第一次看到的时候也差不多。这些表乍一看挺复杂但只要你理解了它们的设计逻辑就会发现它们其实像一套精心设计的“档案管理系统”各自负责流程生命周期的不同阶段。今天我就结合自己踩过的坑和实际项目经验带你把这些表彻底搞明白让你以后调优、排查问题都能心里有数。简单来说Activiti7的数据库表可以分成四大“家族”通用数据表ACT_GE、流程存储表ACT_RE、运行时数据表ACT_RU和历史数据表ACT_HI。这个命名规则很有规律后缀的两个字母就是英文单词的缩写比如GE是GeneralRU是Runtime。记住这个规律看到表名你就能大概猜出它是干嘛的。这些表共同支撑起整个流程引擎的运转从流程设计、部署、运行到最终归档每一步都有对应的表在记录数据。理解它们之间的关系是你用好Activiti7、进行深度定制和性能优化的基础。很多新手容易犯的一个错误是一上来就埋头研究某一张表的字段结果越看越糊涂。我的建议是先建立整体观。你可以把流程引擎想象成一个工厂通用数据表是仓库存放着各种原材料比如流程定义文件流程存储表是产品设计图纸库记录了每个产品的标准规格运行时数据表是车间的生产线看板实时显示每个产品流程实例到了哪道工序、谁在负责历史数据表则是最终的产品出厂档案记录了每个产品的完整生产日志。有了这个宏观印象我们再深入每个“车间”去看细节就会清晰很多。2. 基石与仓库通用数据表ACT_GE详解与应用通用数据表也就是ACT_GE开头的表是整个Activiti7数据体系的基石。它们不直接关联具体的流程实例而是像公共仓库一样存放着各种流程都可能用到的“原材料”和“工具属性”。这个家族只有两张表但都非常重要。2.1 资源表ACT_GE_BYTEARRAY流程元素的“二进制仓库”这张表可能是Activiti里最“万能”的一张表了。它的核心字段是BYTES_一个longblob类型的字段理论上能存下4GB的二进制数据。Activiti会把很多需要持久化的对象序列化成字节数组后扔进这里。我实测下来主要存三类东西流程定义文件本身你部署的.bpmn或.bpmn20.xml文件其原始XML内容会被存进来。流程生成的图片如果你在部署时生成了流程图的PNG图片图片的二进制数据也会放在这里。序列化的流程变量当你在流程中设置了一个复杂的Java对象作为变量比如一个自定义的订单实体并且这个变量的类型是serializable时这个对象序列化后的字节流就会被存入ACT_GE_BYTEARRAY然后在ACT_RU_VARIABLE表中通过BYTEARRAY_ID_字段关联过来。这里有个实际应用中的关键点DEPLOYMENT_ID_字段。它关联到部署表ACT_RE_DEPLOYMENT。一次部署Deployment可以包含多个资源文件比如一个BPMN主文件加上几个子流程文件这些文件都会作为独立的记录存在ACT_GE_BYTEARRAY里但它们的DEPLOYMENT_ID_是相同的。这让你能轻松管理一次发布所包含的所有资源。另外GENERATED_字段也值得留意它标识这个资源是用户上传的值为0还是引擎自动生成的比如流程图图片值为1。在做资源清理或迁移时这个字段能帮你快速分类。2.2 属性表ACT_GE_PROPERTY引擎的“配置中心”这张表非常简单只有NAME_,VALUE_,REV_三个字段但它扮演着引擎内部“配置中心”的角色。它用键值对key-value的方式存储了一些全局性的、版本化的属性。比如schema.version记录着当前数据库结构的版本引擎启动时会检查这个版本号来决定是否需要自动升级表结构。next.dbid这个属性在集群部署时至关重要它为各个引擎节点生成唯一ID提供支持防止ID冲突。REV_版本号字段在这里的作用是乐观锁。当多个线程或节点同时尝试更新同一个属性时比如争抢next.dbid版本号机制可以避免数据覆盖。在实际运维中千万不要手动去随意修改这张表的数据特别是像next.dbid这样的核心属性改错了可能导致流程实例ID重复引发灾难性问题。我见过有团队为了“清理数据”直接清空了这张表结果导致引擎无法启动。这张表的数据应该完全交由Activiti引擎自己管理。3. 蓝图库流程存储表ACT_RE的设计与部署策略流程存储表ACT_RERepository是流程定义的“蓝图库”或“设计图纸库”。当你的流程文件BPMN部署到引擎后其核心定义信息就从二进制文件解析出来结构化地存储在这里。3.1 部署数据表ACT_RE_DEPLOYMENT记录每一次“发布”每次你通过RepositoryService执行部署操作无论是一次部署一个文件还是多个文件都会在ACT_RE_DEPLOYMENT表中生成一条记录。DEPLOYMENT_TIME_字段记录了部署时间这对于审计和排查“某个流程是什么时候上线的”非常有用。NAME_字段是部署时指定的名称可以为空。在实际项目中我强烈建议在部署时赋予一个有意义的名称比如“采购流程V2.1-20231027”这样在后台管理界面上查看时会一目了然。一个常见的误区是认为删除部署deleteDeployment只会删除这张表的记录。实际上默认情况下删除部署会级联删除这次部署所产生的所有相关数据包括ACT_RE_PROCDEF流程定义、ACT_GE_BYTEARRAY部署的资源文件中的相关记录。但是如果这个部署的流程定义已经启动了流程实例删除操作默认会失败除非你传入cascade参数为true这会导致连历史的流程实例记录也一并删除非常危险。所以生产环境对部署的删除操作一定要慎之又慎通常我们更倾向于将旧的流程定义挂起suspend而不是删除。3.2 流程定义表ACT_RE_PROCDEF流程的“身份证”这是流程存储部分最核心的表。部署时引擎会解析BPMN文件中的process元素将其关键信息提取出来生成一条流程定义记录。这里有几个字段和你的BPMN文件设计直接相关理解它们能帮你更好地设计流程KEY_对应BPMN文件中process元素的id属性。这是流程定义的业务键非常重要。你启动流程时ProcessDefinitionKey指的就是它。它应该保持稳定即使流程版本升级同一个业务的流程Key通常也不变。NAME_对应process元素的name属性。这个是给人看的描述性名称。CATEGORY_对应流程XML文件的targetNamespace。你可以用它来对流程进行分类管理。DGRM_RESOURCE_NAME_这个字段存储的是流程图的资源名称通常是.png文件路径它关联到ACT_GE_BYTEARRAY表中的某条记录。这就是为什么你能在API或UI中获取到流程图的原因。SUSPENSION_STATE_标识流程定义的状态。1表示激活可以启动新实例2表示挂起无法启动新实例但已运行的实例一般不受影响。你可以通过API动态挂起或激活某个流程定义这在需要紧急下线某个有问题的流程版本时非常有用。这里有一个关键概念同一个KEY_的流程每次部署都会生成一条新的ACT_RE_PROCDEF记录并分配一个新的唯一IDID_字段和一个递增的VERSION_。当你用KEY_去启动流程时引擎默认会使用版本号最高的那个定义。这种设计完美支持了流程的版本化管理。4. 运行中的心跳运行时数据表ACT_RU核心解析运行时表是流程引擎的“工作内存”或“心跳区”所有正在运行的流程实例、任务、变量等信息都活在这里。一旦流程实例结束对应的运行时数据就会被清除归档到历史表。所以这张表的数据量直接反映了系统当前的负载。4.1 流程实例与执行流表ACT_RU_EXECUTION这张表可能是最让人困惑的之一因为它同时代表了“流程实例”和“执行流”。你可以这样理解一个流程实例Process Instance是一棵执行树的主干而执行流Execution是这棵树上的枝干。对于最简单的、没有并行网关的线性流程这棵树只有主干所以ACT_RU_EXECUTION里只有一条记录它既是流程实例也是唯一的执行流。这条记录的PARENT_ID_和PROC_INST_ID_都为空或者PROC_INST_ID_等于自己的ID。当流程遇到并行网关Parallel Gateway时就会“分叉”产生子执行流。这时你会看到多条ACT_RU_EXECUTION记录。其中代表流程实例的那条记录是根分叉出来的子执行流会通过PARENT_ID_指向它们的父执行流并通过PROC_INST_ID_指向同一个流程实例ID。ACT_ID_字段非常有用它记录了当前执行流停留的节点ID就是BPMN文件里各个元素的id属性。当流程卡住或者你需要手动干预时查询这个字段就能立刻知道流程“卡”在了哪个环节。4.2 任务表ACT_RU_TASK与变量表ACT_RU_VARIABLE任务表是用户交互的核心。流程到达一个UserTask节点就会在这里创建一条任务记录。ASSIGNEE_字段存放任务处理人OWNER_字段存放任务拥有人比如任务委托人场景。这里有个设计这两个字段都是简单的字符串类型没有外键约束。这意味着你可以直接存用户ID、用户名甚至是角色或部门编码非常灵活。TASK_DEF_KEY_对应BPMN中任务的id是定位任务类型的关键。变量表是流程的“记忆单元”。它设计得非常巧妙用多个字段来存储不同类型的值LONG_,DOUBLE_,TEXT_,BYTEARRAY_ID_等TYPE_字段指明了类型。这种“多列存储”的设计是为了查询效率。比如你想查询所有“金额大于1000”的流程引擎可以直接在DOUBLE_字段上建立索引进行数值比较而不用反序列化BYTEARRAY_里的大对象。在实际使用中我建议尽量使用基本类型String, Long, Double作为流程变量避免使用需要序列化的复杂对象。因为序列化/反序列化有性能开销而且一旦你的实体类结构发生变化反序列化很可能失败导致流程无法继续。如果非要存复杂对象务必保证类的序列化版本IDserialVersionUID稳定。4.3 其他运行时表身份关联、作业与事件ACT_RU_IDENTITYLINK表记录了任务与用户/用户组之间的关系比如候选组、候选人。它比单纯的任务处理人字段更强大支持组任务、会签等复杂场景。ACT_RU_JOB及其相关表TIMER_JOB,SUSPENDED_JOB,DEADLETTER_JOB是Activiti的异步执行器核心。像定时器事件Timer Event、异步任务Async Task都会在这里生成作业记录由后台的作业执行器异步处理。如果作业执行失败多次可能会被移到DEADLETTER_JOB死信队列表中这需要你监控并处理否则定时器或异步逻辑就失效了。ACT_RU_EVENT_SUBSCR表用于事件订阅比如消息事件Message Event。当流程执行到一个捕获消息事件节点时会在这里注册一条订阅记录等待对应的消息被触发。5. 历史的记忆历史数据表ACT_HI的价值与优化历史表是流程的“档案馆”它记录了流程的一生。默认情况下Activiti会保存历史数据以供查询和分析但你可以根据需求配置不同的历史级别如none,activity,audit,full以在存储成本和信息详细程度之间取得平衡。5.1 流程实例历史ACT_HI_PROCINST与活动历史ACT_HI_ACTINSTACT_HI_PROCINST表是历史流程实例的概要。START_ACT_ID_和END_ACT_ID_字段清晰地告诉你这个流程是从哪个节点开始在哪个节点结束的。DELETE_REASON_字段记录了流程被删除的原因如果是被删除的话比如“审批被拒绝”或“手动终止”。ACT_HI_ACTINST表则是最详尽的流程足迹。流程走过的每一个节点活动包括开始事件、用户任务、自动服务任务、网关、结束事件等都会在这里留下一条记录并且严格按执行顺序排列。如果你想绘制一个流程实例的完整时间线或者分析每个节点的平均耗时通过START_TIME_和END_TIME_计算这张表是唯一的数据来源。它的数据量可能会非常大特别是对于运行频繁、节点多的流程。5.2 历史明细ACT_HI_DETAIL、任务与附件评论ACT_HI_DETAIL表只有在历史级别设置为full时才会记录数据它会保存每一个流程变量的每一次变更历史。这对于审计追踪要求极高的场景如金融、政务是必要的但也会产生海量数据需要谨慎评估。ACT_HI_TASKINST和ACT_HI_ATTACHMENT、ACT_HI_COMMENT表则提供了任务执行历史和用户交互的补充信息。附件和评论表虽然以ACT_HI开头但它们是可以通过TaskServiceAPI在流程运行时主动添加的并不完全是被动记录的历史。关于历史数据的性能优化我踩过不少坑。对于数据量增长很快的系统必须对历史表建立合理的索引。通常PROC_INST_ID_流程实例ID和END_TIME_结束时间是最常用的查询条件应该优先考虑。另外一定要制定历史数据的归档或清理策略。Activiti提供了内置的历史数据清理功能可以基于流程定义或时间阈值来清理。在生产环境我通常会写一个定时任务定期将超过一定时间比如一年的历史数据迁移到专门的数仓或冷存储中只在线保留最近的热数据这样能保证日常查询性能。