Optaplanner交流区: 2020

上一篇介绍了OptaPlanner 7.32.0.Final版本中的SolverManager接口可以实现异步求解功能。本篇将继续介绍SolverManager的另一大特性 - 批量求解。

适用场景

在日常的规划系统中，求解一个问题，绝大多数情况下，容许运行的时间较有限，特别是在实时性较高的场景中，可让引擎运算时间不多。因此，这种情况下，会在启动了规划运算后，稍等片刻，即需要从求解程序中获取结果。但有些情况下，当我们遇到问题规模较大时，引擎无法在较短时间内找到相对最优解；甚至某些情况下，没有足够长的运行时间，可行解都可能无法找到。至于原因，可以参考我前面关于OptaPlanner入门文章中关于NPC, NP-Hard问题规模的说明。

因此，在一些规模大、时间要求不高的场景下，我们可以让引擎在空余时间自动运算。例如通过定时作业的方式，在非工作时间（例如晚间、节假日等）启动引擎对大多个规模的问题进行规划运算；第二天上班的时候，就可获得运算结果。在发布SolverManager之前，我们也完全可以针对不同的场景，设计相应的定时作业程序，让引擎运算自动运行。当然，这种方法与异步规划的问题一样，需要一定的系统设计经验才能把架构设计完美。而7.32.0.Final版本提供的SolverManager接口，则提供一种更简便的方法来实现些需求。

SolverManager批量规划特性

详细一下SolverManager接口，你应该会发现，与Solver对象的solve方法不同，使用SolverManager的sovle方法对一个问题进行求解时，除了把问题对象作为参数传入solve方法外，还需要传入一个problemID作为参数。其实对于这个参数很好理解，因为SolverManager可以同时对多个问题进行解，必须存在一种方法来识别不同的问题，规划完成后，调用方也需要通过指定的识别号，来获取相应的方案。SolverManager同时对多个问题进行求解时，对问题个数有何要求？它的求解行为是怎么样的呢？

SolverManager批量求解的行为

可同时求解多少个问题？

其实SolverManager不仅可以实现批量求解问题，而且可以实现同时对多问题并行求解。通过设置SolverManager的parallelSolverCount属性，可以设置引擎在批量运算时，可以并行求解的问题数。即当SolverManger启动求解运算时，会将parallelSolverCount设定的数量的问题载入运算空间并行求解。通常parallelSolverCount值可以根据CPU、内存等计算机资源的情况，及问题的复杂度而推算。若无法判断此数量，也可以将parallelSolverCount设置为AUTO，引擎会根据具体情况，自动确定并行运算问题的数量，通常情况下，并行数是CPU核心数量的一半。

值得注意的是，此处的多个问题并行运算，与之前的求解过程多线程运算（Multithreaded incremental solving）是两个概念。多线程并行运算，指的是引擎在求解一个问题时，会将不同的可能解的子集分成多个线程同时计算（主要是计算约束分数和执行启发式算法）。而SolverManager的批量求解过程中，parallelSolverCount属性设定的，是引擎在面对多个问题时，同时求解的问题个数。大家可以设想，如果把Multithreaded incremental solving也启动起来，令引擎在对一个问题求解时可使用多个CPU核心，同时对多个问题并行求解。这种情况涉及的问题就没那么简单。因此，除非你对问题的复杂程度，CPU的核心和运算能力非常清晰，否则上述两个功能，还是设置为自动更好，引擎会根据计算资源运算时的工况，动态地自动确定并行求解的问题个数，及每个问题求解过程中应启动的线程个数。经历过单CPU多线程编程的朋友应该知道，多线程可以提高资源利用率，但有时候线程数量控制得不好，性能上却是起反效果的，最简单的是CPU的线程切换会消耗一定资源的。

批量求解的作用

在一些不太需要实时规划，规划求解不需要太频繁，运算需时较长的情况，批量求解就可以发挥较好作用。例如需要做一些季度或年度的大型供应链计划，因规划实休数量较大，问题空间可能非常巨大，需要花费相当长的时间才能得行相对最优解，甚至只能是可行解。可通过批量求解的方式，让引擎在空余时间（例如晚上、非工作日）进行运算，从而提高服务器资源的利用率。

基本用法

以下例子是OptaPlanner用户指南的例子，大家先作参考，目前还没有时间去研究SolverManager在示例程序中的代码，暂时也不知道官方示例中是否已经有SolverManager相关代码；若没有，稍后的时候我自己试用一下这些功能，再写一篇东西出来分享给大家。

public class TimeTableService {

    private SolverManager<TimeTable, Long> solverManager;

    // Returns immediately, call it for every dataset
    public void solveBatch(Long timeTableId) {
        solverManager.solve(timeTableId,
                // Called once, when solving starts
                this.findById,
                // Called once, when solving ends
                this.save);
    }

    public TimeTable findById(Long timeTableId) {...}

    public void save(TimeTable timeTable) {...}

}

原创不易，如果觉得文章对你有帮助，欢迎点赞、评论。文章有疏漏之处，欢迎批评指正。

本系列文章在公众号不定时连载，请关注公众号（让APS成为可能）及时接收,二维码：

http://weixin.qq.com/r/WjtFXSvE2HanrW8_925I (二维码自动识别)

如需了解更多关于OptaPlanner的应用，请发电邮致：kentbill@gmail.com
或到讨论组发表你的意见：https://groups.google.com/forum/#!forum/optaplanner-cn
若有需要可添加本人微信（13631823503）或QQ(12977379)实时沟通，但因本人日常工作繁忙，通过微信,QQ等工具可能无法深入沟通，较复杂的问题，建议以邮件或讨论组方式提出。(讨论组属于google邮件列表，国内网络可能较难访问，需自行解决)

因为工作和其它原因，很长一段时间没有出新的、关于OptaPlanner的文章了，但工余时间并没有停止对该引擎的学习。与此同时Geoffrey大神带领的KIE项目团队并没有闲下来，尽管在工业可用性、易用性和使用门槛方面，OptaPlanner相对传统的求解器已经做得相当出色；特别是在规划过程交互、和各种操作接口方面，更是目前最为容易使用的规划求解器。

以第7版一系列子版本中，OptaPlanner很多子版只作了细微的更新，如优化规划性能，改善Business Center集成水平等。而在作为OptaPlanner直接使用者的我们而言，第7版的所有子版本中，目前本人认为最大最有意义的更新有2个。一个是7.9.0版本提供内了置的多线程规划，从而实现了规划过程中的多CPU同时对同一问题进行运算，大大地发挥了多CPU（核）服务器的并行运算能力。而今天本文需要详解的新增接口SolverManager则是在系统集成方面的另一次重大创新。SolverManager接口在7.32.0版本中发布。

规划服务的常见场景与异步服务

OptaPlanner的核心是一个运筹优化求解器，可以对各领域的规划问题（NPC, NP-Hard问题）进行规划求解，寻找出问题的近似最优解。OptaPlanner规划组件提供了相当完善的求解运算功能。但在实际的规划系统设计中，除了设计相应的规划模型，还需要考虑规划程序部署问题，便于与现有系统集成。这类部署问题并非OptaPlanner求解器自身的功能焦点。因此，对于我们软件开发、工程人员而言，还需要设计好相应的架构系统，才能实现规划程序与现有信息系统之间良好数据交互。

通常情况下规划运算需要使用大量的运算资源，也即CPU运算能力。我们会把基于OptaPlanner的规划程序部署成独立的规划服务，以接口方式与外界系统进行数据通讯。部署成独立的服务除了有利于降低系统模块间低耦合外，另一个重要原因是有利于运算资源的扩展。当问题规划增大时，程序所需的CPU运算能力也会大副提升；独立存在的规划服务更有利于硬件资源的更新。当然，需要在Client端进行即时规划的场景（例如手机导航软件）除外。

因为规划服务大多数情况下，需要一定的运算周期才能得到可行、且相对最优方案。若根据上述的场景需求，在常见的项目中，可以把规划程序做成一个轻量级的Jar包，再过Web和应用服务器，以Web服务的方式对外提供服务。例如使用Spring Boot进行封装，对外提供Web API服务。通过使Spring Boot的Controller与规划程序包在进程上相互独立，从而实现规划服务的异步性。当然也可以通过在Spring Boot程序中通过多线程方式实现异常调用的特性。不同的实现方法视实际需要而定。

SolverManager特性解决异步问题

对于上述场景，OptaPlanner是否可提供Out-Of-The-Box的解决方案呢？在7.32.0.Final版本之前，求解器规划问题时的接口方法是Solver.solve(),这个方法是同步的，需要规划完成后才能返回。若需要实现异步功能，就需要自己想办法实现了，例如上面提到的将服务进程与规划进程相互独立，或使用不同的线程来响应服务和启动规划，实现起来对软件架构设计需要有一定的经验才能做得相对完善。很幸运，在7.32.0.Final版本中，终于从OptaPlanner内置功能上实现了此特性，这个就是SolverManager。SolverManager是7.32.0.Final版本提供的新接口，通过此接口我们可以在调用规划核心程序进行问题求解时，调用线程即时返回，从而实现调用线程与规划线程异步执行。具体访求是：通过SolverManager.solve()方法可以启动一个异步规划方法，调用方可以即时返回，通过轮询的方式调用SolverManager的其它方法来查询规划状态（SolverManger.getSolverStatus）并获取结果（SoverJob.getFinalBestSolution）。SolverManager的基本用法如下：

CloudBalance problem1 = ...;
UUID problemId = UUID.randomUUID();
// Returns immediately
SolverJob<CloudBalance, UUID> solverJob = solverManager.solve(problemId, problem1);
...
CloudBalance solution1;
try {
    // Returns only after solving terminates
    solution1 = solverJob.getFinalBestSolution();
} catch (InterruptedException | ExecutionException e) {
    throw ...;
}

可以看出，使用SolverManager 对一个问题进行求解时，与Solver对象的solve方法有以下区别：

异步执行，当solve方法被调用后，方法会马上返回，而不待引擎运行结果。调用者需要通过轮询或回调方法(bestSolutionChanged事件)获取运行结果。
每个问题对应一个ID，因为SolverManager会启动线程池同一时间对多个问题进行求解，因此每个问题需要有一个唯一的标识做识别，在下一篇文章中的SolverManger批量求解中将会详解。

因此，在7.32.0.Final版本中，SolverManager的出现，将会在进行求解服务的设计过程中，大大简化引擎与服务的设计复杂度。希望在未来的应用过让OptaPlanner在工业场景的可能性上更胜一筹。

关于SolverManager接口的详细介绍见以下使用说明：

https://docs.optaplanner.org/7.33.0.Final/optaplanner-docs/html_single/index.html