Flowable异步方式处理历史数据。Flowable6版本之后，最大的亮点之一：支持异步方式处理历史数据，重要的事情说三遍，历史数据、历史数据。也可以将这个特性称之为 Flowable async history。

    下面我们开始讲解如何开启历史异步处理数据的功能以及激活默认的历史数据处理器（default Async History Executor）。默认情况下，异步处理历史数据的功能是被禁用的。换言之，历史数据是和运行数据在同一个事务中写入到对应的表中。可以用下面的图解释一下：

    当异步处理历史数据的功能被开启时，历史数据（history  data）不会被立马写入到历史表。相应地，一个定时器稍后会做这件事情。这个定时作业和运行数据在同一个事务中写入到对应的表中。这个定时作业数据很明显非常的重要，如果定时作业数据没有被添加到数据库，那么后续的定时器是不会执行这个作业的。关于这一点一定要注意。

    那我们思考一个问题，定时作业与运行数据的插入是在同一个事务中进行的吗？答案是肯定的，定是作业数据与运行数据在同一个事务中。试想一下，如果运行的数据在添加到数据库的过程中，出现异常回滚了，该如何处理呢？如果不在一个事务中，就会出现脏数据了，比如运行的数据因为异常回滚了，定时作业数据确插入到数据库了，后续的定时器处理定时作业数据将其转化为历史表的数据添加到相应的表中，这就完全不对了嘛，比如完成任务报错，事务回滚，结果过了一段时间竟然发现历史任务就代办任务就不对了。因此定时作业与运行数据的插入是在同一个事务中进行的。

    默认情况下，异步历史定时器使用线程池去轮序数据库历史异步作业并处理它。这个异步历史定时器只不过是一个常规的定时处理器实例，用于处理异步作业，定时作业等等，这个定时器只会用来专门处理历史异步作业，仅此而已。

    这些异步作业包含所有的历史数据（Json方式存储），异步处理器定时处理这些异步作业并解析他们，将其插入到不同的历史表。它简单地以与同步历史案例相同的方式应用这些数据。唯一的区别是数据处理会晚一点，并不是实时的。这也意味着这个功能会带来稍微的性能提升，因为插入一些异步作业总比往多个历史表插入数据更快（但是不多，除非有很多自动的步骤）。

下面这张图会说明这种处理方式

    这个比较好理解，运行数据与异步作业同一个事务中添加到数据库表。后台一个异步定时器定时获取这些异步作业并处理，然后将作业的数据转换为一行行的记录插入到历史表。当然，如果觉得轮训数据库中的作业数据做法欠妥当，也可以使用消息队列的方式，比如actimq或者rabittmq都是可以的。这个后续文章再详细说吧。

    上图中，可能有些人觉得定时器与主项目在一起，并且是个定时器，会不会影响项目的性能呢？这个性能肯定会受损一些，但是没有关系，我们看一下下面的图。这意味着启动一个“light”进程引擎，它只会启动异步历史执行器，但将这些执行器提取出来是一个独立的组件。

    通过将默认的Async历史作业处理程序切换到可以以多种方式使用历史数据的实现，可以对上述设置进行一些定制。为此目的，在流程引擎配置上使用customHistoryJobHandlers属性。

    后续文章会一个个的讲解这些新特性。