设计Optaplanner下实时规划服务的失败经历

  • 时间:
  • 浏览:0

   我门的项目嘴笨 挺符合实时作业的要求的,嘴笨 我门也没有 要求达到分钟级,或秒级的响应;后来机会要能每隔离10分钟,通过实时规划的模式刷新一次计划,还是更能帮助生产调度人员更准确掌握生产情况的。事实上,我门对新的计划刷新条件,并就有按固定的时间间隔来进行,后来以触发事件的法律方式对进行变更规划的。

  另外另还还有一个 要求是实时性,机会按传的规划步骤,对于实时性有要求,或响应下行时延 较高的场景,之类:车间作业的实时调度系统,机会每隔离10分钟就前要刷新一次计划,此时实时规则的作用就反映出来了。如下动图:

  后来你这个 对规划具的时间性要求较高,或在时间序列上,对规划的结果具有一定的延续性要求的情况下,你这个 规划法律方式是满足不了要求的。之类你这个 实时调度的场景;要求每个新的solution与上另还还有一个 solution前要具有延续性,不机会每次给出的solution存在过大的差异,若产生过大的差异,有有哪些规划出来的方案对于执行机构来说,是不机会按计划执行的。之类车辆调度系统(见下图),每隔另还还有一个 时间段,就前要刷新一下车辆情况和环境情况,不机会每次刷新出来的调度方案跟前一次存在千差万别。每一次产生的方案,它前要尽最大程度上与上一次保持相近

这又是一篇花费不少精力的东西,尽管最终没实现实时规划服务。

  关于Real-Time Planning的具体开发步骤没有 律方式在这里详述,在本系列的往后文章中,老农机会有一篇专门的文章介绍。它的基本步骤如下图。

创作不易,欢迎转载,请标明出处。

  后来,我花了半年时间,对每另还还有一个 步骤进行调试分析,对每另还还有一个 solution的clone进行核对,我嘴笨 没有 律方式从我的tcp连接中找到任何头绪。于是我唯有求能够Geoffrey大神。通过邮件讨论组我给他留了个贴子。调慢Geoffrey大神就回复了(你这个 得给个赞,比利时跟我门的时区相差不少吧?每次提的什么的什么的问题 ,他都能及时回复)。回复见下图,你这个 回复令了心被泼了一大桶冷水。它竟然嘴笨 机会是另还还有一个 bug! 当然就有机会是tcp连接产生了race condition. 可我都找了半年了,嘴笨 没有 律方式,才想到找Optaplanner团队。后来让我把你这个 什么的什么的问题 的重现步骤在Optaplanner项目的JIRA中提交了另还还有一个 issue,他不知道这不是我给Optaplanner作出的你这个 点贡献呢,期待正确处理结果呀。

调用引擎Solver对象提交变更 

  你这个 应用模式下,引擎存在另还还有一个 非实时情况,后来另还还有一个 调用 -> 获取规划结果的简单交互过程。

  后来Optaplanner还有你这个 神操作,没有 它的作用将进一步大增了,幻想一下我门看科幻或战争电影时,那里的指挥中心必然有另还还有一个 大屏幕,上边显示了实时的战况或各方资源的部署情况,机会有有哪些部署是前要通过规划来辅助实现一句话,Optaplanner是就有还前要作为后台超级计算机上不停运算规划的控制中枢系统呢?不过好像想多了。没没有 神,做一下实时作业调度还是还前要的。下面看一遍看我门的项目是怎样考虑应用Real-time planning的。

   Real-time planning, 顾名思义后来实时规划,它与传统的规划步骤区别在于,它并没有 另还还有一个 刚开始并退出规划的动作,面是一旦引擎启动,它将以守护tcp连接的形式一直存在运行情况,而没有 返回;当它满足规划刚开始条件时(之类找到符合条件的方案,或到达规划时限),会进入值守情况,不占用CPU资源。待激发事件对它发出重新启动的指令。后来,它的步骤是: [构建Problem对象] + [构建Solver对象] -> 启动引擎 -> 规划  -> 通过BestSolutionChange事件输出规则方案 -> 休眠 -> 接到重启指令 -> 规则(重重上述步骤),如下图:

  现在法律方式有另还还有一个 ,另还还有一个 是等Optaplanner团队在JIRA上对我提交的issue进行正确处理,看是就有真的在Optaplanner中存在没有 另还还有一个 Bug. 另有你这个 法律方式是我打算将我的tcp连接进一步僵化 ,将它与Springboot分离,跟Optaplanner的事件tcp连接一样,通过其它法律方式启动tcp连接来尝试Real-Time Planning.

系统的构件底部形态如下图

 bestSolutionChanged事件正确处理tcp连接

  其嘴笨 这半年时间时,我不用说仅仅是检查我另一方的代码不是再次出先资源竞争什么的什么的问题 ,我还Debug进了Optaplanner的源代码里(7.8.0.Final版),并找到了异常的具体来源。发现确嘴笨 实是在我提交了ProblemFactChanged请求后,引擎也进行了正确处理,但机会引擎在正确处理了请求后,在新的Solution的clone中,并没有 被成功更新,就后来新的Planning Entity并没有 进入新的solution clone中,而意味着着 正确处理tcp连接无法识别新的Planning Entity, 就出错了。

  先看看正常情况下,我门对Optaplanner的应用场景。平时我门使用Optaplanner时,不外乎以下哪几个, 构建Problem对象 + 构建Solver对象-> 启动引擎 -> 执行规划 -> 刚开始规划 -> 获得方案-> 获取结果方案,如下图。

  古语有云,理想很丰满,现实很骨感。上述的设计对于Optaplanner的使用领域来说,是比较先进的(起码在国内还没听说过没有人后来用法)。对业务而言也是非常符合要求的。后来我对上述所有美妙的构想完成了设计,并实现了代码,并通过Springboot运行起来后来。tcp连接嘴笨 如我意图那样运行起来了!启动引擎 -> 刚开始规则 -> 找到更佳方案 -> 输出方案 -> 满足停止条件 -> 引擎进入守值情况. 好了,让我通过http发出另还还有一个 删除Planning Entity的请求。Springboot的Contoller成功接收,启动子tcp连接正确处理数据,向引擎对象发送doChange请求,引擎检测到请求,分出另还还有一个 tcp连接(你这个 tcp连接是引擎分出来正确处理我那个tcp连接请求的)正确处理成功,并更新Problem对象中的Planning Entity列表;引擎继续运行。Duang~~~~引擎主tcp连接竟然抛出另还还有一个 异常并停止了!提示那个被请求删除的Planning Entity未被加入Planning Entity的列表中!这下我蒙了。为有哪些就有报出你这个 Planning Entity未被换成列表的错误?回想起Optaplanner的开发说明书里,关于Planning过程中,每个新的solution就有另还还有一个 clone的情况,我坚信我的tcp连接是遇到Race condition了,一定是我的tcp连接考虑不周意味着着 资源竞争。Optaplanner号称经过血块单元测试,压力测试,有良好的稳定性,不机会就后来被我把错误试出来的。但切切实实地抛出了你这个 异常,而我却没有 任何法律方式。错误信息如下图,下图是我截取给Optaplanner团队的:

        嘴笨 本文他不知道不是另还还有一个 知识点分享,过程很美妙,但结果很失败。我门在利用Optaplanner的Real-Time planning(实时规则)功能,设计实时在线规划服务时,遇到另还还有一个 属于Optaplanner7.8.0.Final版本的Bug。在实现实时在线规划服务的过程中,我做过也不尝试。机会前要实时在线的服务,后来,前要设计多tcp连接并发为外界请求提供响应,前要实现消息队列来管理并发请求的时序等什么的什么的问题 。有有哪些Java方面的并发正确处理,我门暂时不详述,这方面的牛的人没有 来不多了,我后来新手,站在别人的肩膀上实现的代码而已。在本文我着重介绍一下,我在尝试使用Optaplanner的Real-Time Planning功能时遇到的什么的什么的问题 ,最终确认什么的什么的问题 出自Optaplanner引擎自身, 并通过JIRA向Optaplanner 团队提交issue过程。

场景要求

 

  Optaplanner引擎tcp连接被包装成另还还有一个 Springboottcp连接,并设置为daemon模式(守卫tcp连接),Springboot Application启动后,引擎执行tcp连接被另还还有一个 tcp连接启动。主tcp连接向外提供Restful webservice,当有Web请求到达时,就启动另还还有一个 tcp连接用于执行Optaplanner的ProblemFactChange对象中的doChange法律方式,对现有solution中的Planning Entity列表中的对象进行增完全操作;并触发VariableListeners. 引擎在正确处理有有哪些调用时,会产生新的bestSolution,并触发BestSolutionChangedEvent事件,在事件正确处理法律方式中,将最新的Solution中的Planning Entity列表输出即可获得增完全Planning Entity后的最新solution了。

  即当另还还有一个 新任务产生了,或另还还有一个 已计划好的任务被生产完成了,或另还还有一个 已计划好的任务无法按时执行生产作业而产生计划与实际情况存在差异时,或另还还有一个 机台再次出先计划以外的停机等诸没有 类对计划足以产生影响的事件,都机会作为触发重新规则的条件。后来,我将引擎tcp连接做成Springboottcp连接,部署到服务器端,并将tcp连接设计成多tcp连接并发的模式,主tcp连接负责侦听Springboot接收到的WebAPI请求,当接收到请求后,就从tcp连接池中启用另还还有一个 tcp连接对请求进行正确处理,有有哪些正确处理是更新规划的请求,并把传送过来的Planning Enitty, Problem Fact等信息按要求进行正确处理,并塞进 队列中。所有请求产生的重新规划信息,通过队列依次被送入引擎正确处理。当有新的solution产生时,将它输出指定位置,并通知客户端前往获取。

ProblemFactChange接口的实现

  这里提供一下最重要的另还还有一个 代码块,对应的场景是,当另还还有一个 新的任务(Task)前要被换成进引擎的Problem中参与规则时,应该怎样换成,换成完成后来,怎样获得规划的结果。这另还还有一个 代码块的功能分别是bestSolutionChanged事件正确处理tcp连接,调用引擎Solver对象提交变更请求,和实现ProblemFactChange接口的实现,用于实现变更正在规划的Planning Entity.