几点基础概念回顾
（1）排序定制化不同于实现业务排序。
实现业务排序可以是查阶段，通过boost、各种func 组合、离线score等单独或者组合实现排序目标，
或者索引构建阶段的 field boost、document boost
或者索引构建阶段的postion、freq、length等的处理
或者干预vsm、
或者实现自己的function，
或者自定义queryparser引入自定义的query和相关weight、score等。
或者自定义querycomponent，然后彻底从query链路调整查询和排序
或者以上的组合
（2）排序定制化
这里特指solr已经默认自带的排序机制，默认vsm、默认sortbyField、默认的function集合包括他们的组合、
默认的booleanquery、phrasequery、luceneparser、dismax parser等 都不能满足排序需求的。
然后需要开口子，引入自己的排序。
（3）排序是动态的过程
绝对不是一次设置，永久有效的。随着数据集的变化、业务场景的变化、市场的变化等因素，排序只是阶段
性满足业务需求。这意味着排序是不间断的过程，没有最好，只有更好。
（4）排序是 one doc one score just
这里是说获取到了doc，就获取了这个doc的得分，doc的得分只关联这个doc自身的内容。间接的意思，每个doc的得分是自身闭包的，与其他doc的得分情况无关。
基于solr实现排序定制的几种有效、低成本实现
（1） 简单、直接的 extends ValueSourceParser
在solrconfig.xml 中配置自己的valueSourceParser，查询结点通过name 对应的关键词调用相关排序。 作用域是在查询中设置，需要的时候就启用 eg 配置
查询 query.add("sort", "sortRank(id@itemType) asc");
（2）vsm bm25 的参数调整 extends SimilarityFactory{
配置在schema.xml中，作用域是整个solrcore。
（3）SearchComponent 的重写 extends SearchComponent
这里面可以实现 默认排序+topN的二次排序；或者直接定义自己的排序 这里面的实现是深度的干预查询链路，甚至cache。 这里的干预设计到shard请求，需要仔细验证 这里的干预有的需要parser的干预联合，用来解析参数 关于o2o个性化排序，建议走这个模式
（4）关于o2o个性化排序
schema的配置：距离算法、距离精度 排序策略：过滤优先 or 结果优先 or 速度优先 ，然后会有不同角度的平衡 涉及具体业务细节和排序公式，这里省略 1w字
