drools

SparkStreaming-流处理-规则动态更新-解决方案 image2017-10-27_11-10-53.png (1067×738) elasticsearch-head Elasticsearch-sql client spark streaming reload_百度搜索 基于spark streaming的网管系统告警过滤算法的设计与实现 - 其它论文 - 道客巴巴 scala - Spark Streaming into HBase with filtering logic - Stack Overflow Building Lambda Architecture with Spark Streaming – Cloudera Engineering Blog Druid 实时数据分析存储系统 驱动海量大数据实时多维分析，优酷为什么会选择Druid？ - 大数据技术参考_大数据技术文献_大数据趋势分析 Druid（准）实时分析统计数据库——列存储+高效压缩 - bonelee - 博客园 presto、druid、sparkSQL、kylin的对比分析，如性能、架构等，有什么异同？ - 知乎 Druid对比Elasticsearch - lpthread - 博客园 streaming 规则更新_百度搜索 第三部分：日志和实时流处理

以下是一些简单的思考 一般开发模式 参考图 说明 我们提供多种api 实例，通过强大的规则以及路由能力提供api 以及数据的处理 基于rule 模式的 参考图 说明 将业务处理使用rule 解耦，同时提供了多实例的副本，其中rule 可以加入审计以及可视化展示，注意此图没有使用特性开关 对于复杂的处理我们还是需要依赖强大的路由能力解决（当然可以解决我们大部分的复杂业务问题） 基于rule+ Feature Flags 参考图 说明 api 的版本都是一致的，对于复杂业务处理基于rule，同时包含了审计以及dashboard，同样还是利用了强大的路由能力。 好处:版本一致，可以全局灵活的调整业务api以及功能的处理，对于复杂业务基于rule处理增强了业务的处理 说明 一些实践，特性开关不同语言的实现还是比较多的，java 的ff4j是一个不错的选择，java 的easy-rules 是一个简单、灵活的规则 引擎(drools 也是不错的) 来源： oschina 链接： https://my.oschina.net/u/4384923/blog/3275768

在企业的规划、优化场景中，均需要开发规划类的项目，实现从各种可能方案中找出相对最优方案。如排班、生产计划（包括高层次的供应链优化，到细粒度的车间甚至机台作业指令）、车辆调度等。因为这类场景需要解决的问题，均可以归约为数学中的NP-C或NP-Hard问题。而解决此类问题，均需要通用的求解器才能实现。这类求解器也称规划引擎，通过它才能从天文数字的可能方案中，找出一个可行且相对优化的方案。 规划引擎的本质，是运用规划中的各种优化算法（目前用得比较多的是启发式算法），对一个NPC或NP-Hard 问题寻找最优解的过程。面对不同的问题、场景，会衍生出各种各样的运筹优化变种。但事实上这些问题都可以视作数学规划问题，可使用运筹学中的对应方法来处理。例如生产计划的排程，车辆路线规划与实时调度，工单的划分和开料问题等，都可以通过数学规划并优化。而求解器则提供了各种优化算法的软件，用于求解这类问题，也被称为规划引擎。 使用约束求解器实现求解，其中关键的步骤是问题进行建模。建模过程其实是把业务场景中的参数、变量、规则和优化目标等要素，转化成可被规划引擎识别，并运算的优化模型。在常见的商用求解器中，这些问题均需要被建模成数学模型，用数学语言来表达从业务流程中提练出来的业务规则与要求。求解器对数学模型求解，寻找并输出模型的最优解。客户端的程序再将最优解（即最优方案）转化成业务方案再，并传递给其它企业使用系统

在企业的规划、优化场景中，均需要开发规划类的项目，实现从从种可能方案中找出相对最优方案。如排班、生产计划（包括高层次的供应链优化，到细粒度的车间甚至机台作业指令）、车辆调度等。因为这类场景需要解决的问题，均可以归约为数学中的NP-C或NP-Hard问题。而解决此类问题，均需要通用的求解器才能实现。这类求解器也称规划引擎，通过它才能从天文数字的可能方案中，找出一个可行且相对优化的方案。 规划引擎的本质，是运用规划中的各种优化算法（目前用得比较多的是启发式算法），对一个NPC或NP-Hard 问题寻找最优解的过程。面对不同的问题、场景，会衍生出各种各样的运筹优化变种。但事实上这些问题都可以视作数学规划问题，可使用运筹学中的对应方法来处理。例如生产计划的排程，车辆路线规划与实时调度，工单的划分和开料问题等，都可以通过数学规划并优化。而求解器则提供了各种优化算法的软件，用于求解这类问题，也被称为规划引擎。 使用约束求解器实现求解，其中关键的步骤是问题进行建模。建模过程其实是把业务场景中的参数、变量、规则和优化目标等要素，转化成可被规划引擎识别，并运算的优化模型。在常见的商用求解器中，这些问题均需要被建模成数学模型，用数学语言来表达从业务流程中提练出来的业务规则与要求。求解器对数学模型求解，寻找并输出模型的最优解。客户端的程序再将最优解（即最优方案）转化成业务方案再，并传递给其它企业使用系统

转自https://www.cnblogs.com/atomicbomb/p/7251814.html kieSession.fireAllRules(1); ：只执行其中一条可执行规则 Drools是一款基于Java的开源规则引擎 　　实现了将业务决策从应用程序中分离出来。 　　优点： 　　　　1、简化系统架构，优化应用 　　　　2、提高系统的可维护性和维护成本 　　　　3、方便系统的整合 　　　　4、减少编写“硬代码”业务规则的成本和风险 Drools的基本工作工程 　　我们需要传递进去数据，用于规则的检查，调用外部接口，同时还可能获取规则执行完毕之后得到的结果 Fact对象： 　　指传递给drools脚本的对象，是一个普通的javabean，原来javaBean对象的引用，可以对该对象进行读写操作，并调用该对象的方法 　　当一个java bean插入到working Memory（内存存储）中，规则使用的是原有对象的引用，规则通过对fact对象的读写， 　　实现对应用数据的读写，对其中的属性，需要提供get和set方法，规则中可以动态的前往working memory中插入删除新的fact对象 Drools的基础语法： 　　包路径，引用，规则体 (其中包路径和规则体是必须的) Drl文件内容： 　　例子： 　　　　hello.drl文件如下： package rules

3 月，跳不动了？>>> 在常用的ERP系统、OA系统的开发中，工作流引擎是一个必不可少的工具。之前在选择工作流引擎时曾经在activiti和jbpm之间有过比较，当时做出的决定是使用jbpm，但实际开发过程中发现这个选择是不合适的。目前我们改为选择Activiti作为工作流模块的引擎，理由如下： 1、Activiti拥有更简洁健壮的接口 JBPM自从版本五后，便重启炉灶，完全抛弃了JBMP4的代码基础，重新基于drools进行了实现。JBPM5，JBPM6似乎缺少一个合格的系统架构师，其接口设计匪夷所思，基本上是按照drools的接口再提供了一套JBPM接口，同名的接口，实现类不断重复出现，代码体系十分混乱。 一个典型的例子，同样是查询待办事项，在JBPM中接口如下： List<TaskSummary> getTasksAssignedAsExcludedOwner(String userId, String language); List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, String language); @Deprecated List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, List<String>