现状
当 solr 集群采用了 merger 的合并方式后，会把各台 solr 的结果合并到最终结果并输出，如下图所示：
这种是非常常规的做法，我想各路大神也早明白大概的情况了，那我也不多说了
集群的基本情况就是，因为收录了大量的新闻信息，某些新闻可能某一个小时间段内插入了大量数据，而某些时间段却木有，比如：“车祸“这一个关键字，在早上的9点1分1秒添加了 10W + 条数据，但其他时间段却一条都没有，但因为入索引时采用了轮询的方式，可以认为相同所有关键字在每台 solr 的数据量近似一样。简单一句话，每一个台solr 对应关键字的文档数差不多，但关键字在每一台 solr 对应关键字的时间段分布很不均匀。这很重要的目前的集群数据分布情况。
问题的提出
业务要求需要通过某关键字搜索出来的数据，并通过翻页拿出最新的 1W 的数据用于分析，比如：搜索“车祸”有 50W+条结果，每页 20条记录，然后通过翻页 page=1 , page=2 , page=3 这样子一直翻到 500 页拿到 1W 条数据（500 * 20 = 1W ）
但这样子的问题又来了，通知这样子的翻页，性能比较低下，这样子遍历１W条记录需要 45秒左右的时间，因为这样子的分析是用户触发，意思是需要让用户在页面前等待 45 秒的时间，同时这样子造成了 merger 较大的 cpu 使用率。因为 merger 要进行合并排序，越往后翻页，merger 合并的数据量倍数增长。
１. 比如越往后翻页，性能表现越差，因为在 merger 排序，如果我翻到 start=100 ,rows=10 的话，表面上 merger 只返回了10条记录，但事实上单台 solr 却返回了 100 + 10 = 110 条记录到 merger ，导致越往后翻性能越差
２. 同样的道理，因为翻页越往后，从每台 solr 拿到的 rows 就越大(因为无论什么时候 start=0) ,
那读取的 docs 就更多了，导致了每台 solr 的搜索时间更长了。
综上所述，要解决这些问题我做了以下的调整
由上面的分析可以知道，其实翻页越往后，mereger 筛选掉的结果就越多，这些都是无用功。
所以我做了２个地方调整，如下所示
１，调整从 merger 传递到各 solr 的分页调整（如下图所示），注意红色框的东西，因为merger 合并时把前 n 页的数据都会拿出来并进行合并，所以我这里调整了一下，比如， solr 的数量是 6 ，前端需要 start=100,rows=10 则从merger 发布到各solr 的分页则变成 rows / 6 = 10 / 6 = 1.6 ，取为 2 ，则传给每一台 solr 的分页参数是 start= (100 / 10 ) * 2 , rows = 2 , 则从 merger 传到各 solr 的 rows 是 2 , start 是 20 . 那 merger 从每一台 solr 拿到的结果其实只有 2 个，merger 拿到的总数据是 2 X 6 = 12 个了，merger 只需要把这些结果合并起来不用参与任何的排序。
２，另外，修改 solr 的 merger 那部分的源码，在QueryComponent 类中，修改 mergeIds 的方法，使用里面的 ShardFieldSortedHitQueue 类变成普通的 LinkedList 类，只需要把各 Shards 简单添加起来了。如图：
OK，已经完成了。就算前端需要 start 值很大，但事实上，这样修改后 每台 solr 传给 rows 的只有几个，大大减少了 merger 在合并过程中的损失。同时业务的遍历仅仅拿到这个时间段的数据则可，至于有没有排序好，对于他们来说意义不大，因为他们要把这些数据进行整理。
文字虽然比较啰嗦，希望我能表达我能表达的东西出来就可以了。只要按着思路去做，代码方面不是什么问题。
优化后的性能对比
两种方式，在修改前后的效果对比，可以看到，新方式比之前的快了２到３倍，这都是得益于这种方式的效率。
欢迎转载，请注明 http://kernaling-wong.iteye.com/blog/2022742 by kernaling.wong