drools研究后记
在实际工作中,有关于达标推断的业务逻辑
就是谁谁谁 消费满了多少钱。就返多少钱的优惠券
声明:不是drools不好,仅仅是在我遇到的场景下,不合适,不够好
在使用drools的时候发现有例如以下问题:
1、效率低。这是最严重的问题。实际业务环境,用户数量要几十万。还有非常多业务相关的数据。他们要组合推断。实际情况是,插入working memory的fact数量超过万级,程序就開始hang住,gc日志打开后发现,系统不停的gc,用内存查看工具。发现drools生成了大量的内部对象。甚至有内存泄露的趋势。
这里推測。应该是drools为了实现通用性,会把全部的自己定义的实体。转化为它内部的节点。然后还有相关的一大堆附属。可是做得不够好,所以导致了上面的现象
这简直就是没法用了,时间有限,花大把时间把他源代码搞清楚,再看看有没有留出钩子,或者重写源代码,有这时间,还不如我自己实现达标推断了逻辑了呢,这样效率又能得到保证,运维成本还不高。毕竟关系到用户的钱,不能给算错了,遇到问题须要立即定位问题,万一遇到了一个drools的内部问题,说不定要多耽误事呢
实际自己实现的达标推断过程,在万级以内(就是在drools能承受的范围内)。我自己优化后的算法。要比drools实现快10倍
2、不方便。详细体如今数据insert的过程,为了可以满足drl文件里所描写叙述的数据结构以及他们的关系。必须提前构造相关的数据结构。非常费力。
并且这部分逻辑,写不好的话,也会写成一坨。尽管drl鼓吹的更易读,可是带来的副作用就是,外面的工作量非常大
另外就是数据装载,一般都是从数据库读取数据,这里也没有一些api对这里做支持。它的api很多其它是面向内存对象的,并没有考虑到这点
3、社区支持。
这个是我要吐槽的
说是社区活跃文档多啥啥啥的,太tm扯淡了。有个在线聊天的答疑的,进去喊话,从来没人吱声
文档写的那叫一个烂。就是堆砌,根本没考虑到读者的学习路径