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