面对Oracle等传统数据库的高成本与扩展性瓶颈，结合国产化替代需求，将Flowable工作流引擎迁移至TiDB分布式数据库，正成为众多企业的优先选择。
一、迁移背景与价值
随着企业业务快速发展，基于Oracle等传统数据库的Flowable工作流引擎逐渐暴露出诸多问题。以平安科技为例，其核心系统日调用量超1.4亿，日业务吞吐量超过3000万，单表数据量已达260亿行，传统数据库在高并发、大数据量场景下性能瓶颈日益凸显。
迁移至TiDB能为企业带来多方面的价值：
- 显著降低成本：平安科技实践表明，从Oracle迁移到TiDB后，整体存储占用减少近40%，整体成本降低10%-11%。
- 提升系统性能：TiDB的分布式架构可轻松应对高并发访问，联机交易延迟<60ms，系统可用性达99.99%。
- 简化分库分表：TiDB原生支持分布式架构，避免了传统MySQL分库分表的复杂性。
- 国产化合规：满足金融、政务等行业国产化替代要求。
二、迁移前期规划
2.1 环境与资源准备
迁移全过程需要系统化的规划，大型项目通常需要4-6个月，小型项目约1-2个月。
资源规划清单：
- 硬件资源：提前申请采购足够的主机资源，TiDB集群建议至少3个节点起步
- 人力配置：DBA、开发人员、测试人员和技术专家需明确分工
- 工具选型：准备sqluldr2、Lightning等数据导入工具，或自研TMS工具
2.2 Flowable数据特征分析
Flowable工作流引擎包含多张核心表，需重点关注：
- 流程定义表（ACT_RE_PROCDEF，ACT_GE_BYTEARRAY）
- 运行时数据表（ACT_RU_EXECUTION，ACT_RU_TASK）
- 历史数据表（ACT_HI_PROCINST，ACT_HI_ACTINST）
- 身份管理表（ACT_ID_USER，ACT_ID_GROUP）
迁移过程中要特别注意ACT_GE_BYTEARRAY表中的二进制流程定义数据，这是流程正常运行的关键。
三、迁移实施关键技术
3.1 表结构与数据类型转换
Oracle与TiDB在数据类型和语法上存在差异，需进行针对性转换：
常见数据类型转换规则：
| Oracle类型 | TiDB类型 | 注意事项 |
|---|---|---|
| NUMBER | BIGINT或DECIMAL | 未指定精度时需明确转换规则 |
| DATE | TIMESTAMP | 使用CURRENT_TIMESTAMP替代SYSDATE |
| VARCHAR2 | VARCHAR | 基本兼容 |
| CLOB | TEXT | 需注意大小写敏感差异 |
语法差异处理：
- 空字符串处理：Oracle中
''被视为NULL，而TiDB严格区分，需业务逻辑配合改写 - 外键约束：TiDB v8.5.0 GA已支持外键，可正常使用
- 默认值函数：将
SYSDATE替换为CURRENT_TIMESTAMP
3.2 数据迁移策略
根据数据量大小采用不同的迁移方法：
小表迁移：直接使用Dumpling导出，Lightning导入的方式，简单高效。
大表迁移（超过10GB）：采用拆批并发导出策略，平安科技对8张超大表使用此方法，显著提升导入效率。
静态数据迁移流程：
- 建立静态COW库，避免写入冲突
- 使用CPS或PMS同步方法
- 分批处理，将大表拆小解决网络传输延迟
- 数据校验，确保数据一致性
整个迁移过程约需两周，加上数据校验共需一个月。
3.3 增量数据同步
为保证业务平滑迁移，需实现增量数据同步：
- 使用OGG或TiCDC同步机制，确保数据准确性
- 监控同步延迟，确保数据实时性
- 准备数据比对工具，定期验证源库与目标库的一致性
四、Flowable特定配置与优化
4.1 流程定义缓存优化
迁移后可能遇到流程定义缓存问题，错误信息如下：
text
org.flowable.common.engine.api.FlowableException: deployment 'xxxxx' didn't put process definition 'xxxxx' in the cache
解决方案：
- 检查ACT_GE_BYTEARRAY表是否完整迁移，特别是二进制字段
- 清理多余的开发测试数据：
sql
DELETE FROM ACT_RE_DEPLOYMENT;
DELETE FROM ACT_RE_PROCDEF;
DELETE FROM ACT_GE_BYTEARRAY;
- 重新部署流程定义，确保缓存正常加载
4.2 事务与并发控制
Flowable依赖数据库事务保证流程一致性，TiDB的分布式事务模型与Oracle存在差异：
- 调整大事务设置：TiDB默认限制单条KV entry不超过6MB，可通过
txn-entry-size-limit参数调整 - 对于复杂业务流程，将大事务拆分为小事务
- 必要时调整
txn-total-size-limit参数（最大10GB）
4.3 历史数据清理策略
Flowable历史表随业务运行快速增长，需制定合理的数据清理策略：
- 使用TiDB的分区表功能按时间分区
- 基于
DELETE FROM t WHERE id BETWEEN ? AND ? LIMIT 5000循环删除 - 通过检查Affected Rows是否为0作为终止条件
- 开启Region Merge功能优化删除后的查询性能
五、全真模拟验证与性能测试
5.1 流量回放技术
平安科技使用openresty进行生产流量镜像，具体步骤：
- 通过openresty进行异步处理、限流和放大倍数控制
- 使用挡板服务实现灵活应用
- 逐步增加负载，从0.1倍开始，逐步提升至全流量
- 比对真实与复制请求返回，验证功能一致性
5.2 性能优化实战
根据平安科技经验，复杂业务去O的SQL改写率高达80%，简单业务约30%。
TiDB性能优化方案：
- 执行计划管理：使用SPM绑定现有SQL的执行计划
- 索引优化：优化索引选择性，避免全表扫描
- 参数调优：调整GC与compaction filter配置，缓解MVCC性能瓶颈
- 分布式执行：利用TiDB的Coprocessor功能提升复杂查询性能
六、业务切换与回退方案
6.1 平滑切换流程
- 前期准备：通过触发器限制写操作权限，仅保留数据同步用户
- 数据同步：等待数据一致后，关闭Oracle写入
- 业务切换：全量切换至TiDB，应用连接指向TiDB集群
- 验证监控：密切监控业务指标和数据库性能
6.2 完善回退机制
若出现异常，可快速切换回Oracle：
- 关闭数据同步
- 撤除触发器限制
- 连接切回Oracle
- 启动应用恢复业务
平安科技经验表明，回退操作相对简单，属于PV操作，但需注意如果业务逻辑本身存在问题，即使切换回Oracle，问题仍然会存在。
七、迁移后运维保障
7.1 监控与告警
- 配置完善的监控体系，关注TiKV的CPU使用率、Region分布等关键指标
- 设置慢查询告警，及时优化性能瓶颈
- 监控TiCDC同步状态，确保数据一致性
7.2 高可用架构设计
推荐采用同城三机房单集群+远程容灾集群部署：
- 同城三个数据中心，通过Raft协议实现三副本强一致性复制
- 远程通过TiCDC建立容灾节点
- 形成完整的"同城三副本 + 异地一副本"高可用容灾体系
八、总结与建议
Flowable迁移到TiDB是一项系统工程，需全面考虑技术架构、数据一致性和业务连续性。根据平安科技等企业的实战经验，总结以下建议：
- 充分测试：在全真模拟环境充分验证功能与性能
- 逐步迁移：采用分阶段迁移策略，先非核心业务后核心业务
- 完善预案：准备详细的回退方案，确保业务安全
- 团队培训：提前培养团队对TiDB的理解和运维能力
通过科学的规划和严谨的执行，Flowable到TiDB的迁移将显著提升系统性能和支持能力，同时降低总体成本，为企业的数字化转型提供坚实基础。