需求说明

事实上在工作中总是会遇到各种异想天开不知所措的需求，就比如当prd文档简单的写下了要求你按相关度+热度综合排序这样的需求。嗯，这看着其实不过分。
事实上我更希望您能说明清楚排序规则，各种情况各种场景下的排序方式，而不是简短的这么一句话。不过大部分情况你永远都只能获得这一句话，那么，还是想想如何从这一句话中推断出需要的信息来进行需求分析吧。

需求分析

1.首先是相关度

那基本上要求搜索词和文本的相关程度上的得分。正常的全文搜索的情况下相似度大部分可以使用TF-IDF或者BM25进行计算，效果上都差不多，当然也可能有更复杂的奇妙的需求逼着你去自定义打分的逻辑，但那都是迭代到一定程度的后话了。关于如何自定义打分可以参考我的一篇博客ElasticSearch插件编写-Similarity插件

2.其次是热度

这里就涉及到热度的计算，万幸产品们提供了一个热度计算的公式，有点复杂，大概可以概括为下面这样

f1(点赞数, 阅读数, 评论数) + f2(当前时间-文档创建时间) + f3(随机数) f1,f2,f3为函数

首先是f1，这些属于可以实时性要求不强，可以通过离线同步来定时计算f1(点赞数, 阅读数, 评论数)的数值然后写入索引。

• 优点: 空间换时间，查询的时候节省了一部分计算的耗时
• 缺点: 实时性不强

其次是f2，这就有一些麻烦了，文档创建时间存储的是时间戳，需要用当前时间的时间戳相减来计算。这样的查询逻辑如何用es提供的语法来表达呢？普通的搜索器应该是无法支持我们的需求的，这个时候就需要引入脚本Script。我们可以编写一段如下的脚本

      "script_score": {
        "script": {
         "script": "f1=doc['f1']; createTime=doc['createTime'];return f1 + f2(nowTime, createtIME) + f3",
         "params": {
            "nowTime": "xxxxxxx"
         }
        }

• 优点: 可以完美计算出热度对应得分，解决复杂逻辑的需求
• 缺点: 计算量偏大，这个压测的结果可想而知，可能改成java原生插件好一些

但即使是这样，会发现好像还是和需求不太一样。相关度+热度，并不是简单的相加减，而是要综合排序。综合排序是很模糊的四个字，犹抱琵琶半遮面般的含蓄，我的理解是相关度为主并综合考虑热度的设计。那么怎么办呢？有两个方案
方案一
直接相加或相乘或乱七八糟的计算合并相关度和热度的得分
方案二
优先排序相关度，相同情况下排序热度

方案一是个优点缺点都很明显的方案，他可以更明显的表现出热度与相关度的激烈斗争，是两个因素之间互相对抗后形成的结局，但是需要对数字进行一些平滑，因为可能一不小心，两个分数计算出来不在一个量级，那么分数较低的因素将几乎被忽略不计。简单的说，控制好你想要的比例，比如希望相关度得分占60%，热度占40%的话，就要控制住两者的得分基本也维持在这一比例。
方案二是一个很直白简单的方案

  "sort" : [ {
    "_score" : {
      "order" : "desc"
    }
  }, {
    "hotNums" : {
      "order" : "desc"
    }
  } ]

就这么简单，直接排序，优点在于可解释，逻辑简单，计算快速，缺点在于其实热度对于排序的影响可能就没那么明显，相关度其实没那么容易一样的。但是还有一个问题，送佛送到西，产品给的公式是一个包括实时时间计算的公式，但是我上面代码是一个离线的死的不动的热度，虽然心里知道热度基本用不上，但是面子工程是要做的，那怎么办呢？
这里了解后才发现es灵活到sort也可以放脚本…真的是灵活，类似如下处理

  "sort" : [ {
    "_score" : {
      "order" : "desc"
    }
  }, {
     "script": {
         "script": "f1=doc['f1']; createTime=doc['createTime'];return f1 + f2(nowTime, createtIME) + f3",
         "params": {
            "nowTime": "xxxxxxx"
         }
  } ]

需求反思

其实prd文档中很难能真的把规则说的清清楚楚，谁也不可能一开始就把整个规则设计清楚，这时就需要一步步去摸索到底要怎么做出来，还是要自己思考