Lucene4.3进阶开发之日照光华（十四）
转载请务必注明，原创地址，谢谢配合!
http://qindongliang1922.iteye.com/blog/2008672
接着上篇，散仙介绍的Lucene的几种评分方式，大部分的时候都能满足我们的大多数业务场景，但有些场合下可能我们使用另外一种评分策略，会更加灵活一点，上次介绍的评分主要是围绕着DefaultSimilarity这个类来介绍的，其实这个类控制评分的方式更加倾向于底层控制，而散仙下文要介绍的CustomScoreQuery这个类，则更加倾向于应用层面的控制。
为什么，有时候我们需要借助这个类来完成评分呢？
可能有时候我们会遇到如下类似的需求：
在一份论坛的索引里面有帖子的标题和帖子发布的日期（为了简化程序，假设按年来记录的），这个时候有如下需求，要求我们检索标题时，不仅要检索出与关键词最相关的帖子，而且还得是年份距现在相距不远的帖子，进行提拔加权，综上所述，这里面有2个关键因素，第一内容相关，
第二，近期时间的日期拥有的更高的加权。可以看出那么这个文档的评分是要结合这两个因素来完成最后的总的评分。
到这里可能有些人就会有疑问，为什么不对检索完的内容，按时间排序降序排序呢，这里可能会出现一个问题，如果是硬性的按时间降序排序，可能会破坏评分机制，因为默认的排序是按照评分降序排的，如果按照时间排序可能就会破坏原有的顺序，所以这个时候就需要我们统一下方式，要么用评分的方式来解决问题，那么用排序的问题来解决，显然统一评分的方式会更加适合这个场景。
测试的数据如下：
3 伟大的祖国 0.499999972 伟大的人啊 0.24999999
