shard是将索引拆分, 比如一共要索引1000w文档, 如果都存在一个服务器上, 那么可能在不考虑高QPS的情况下, 单一请求的响应时间都已经是不能接受的了, 因此可以将1000w文档存在5个服务器上...值得一提的是, 每一个shard的对应的是一份完整的lucene索引, 是可以自己直接写lucene代码读取的....ID和score(或其他排序条件), 然后3个ShardNode会并发查询自己分片的子索引, 得到自己的子索引内得分前20的文档返回给ClientNode....当前设计的缺陷
分阶段获取过程中的索引一致性问题: 目前的分布式查询分了两个阶段, 阶段1发起第一次请求从各分片获取TopN ids, 阶段2合并所有分片ids后再发起第二次请求去各分片获取要返回的字段...类似的情况还有可能在获取ids阶段召回了文档1, 但是在获取字段阶段, 文档1已经被删除了. 类似的问题其实是需要在两次请求的时候维护每个分片索引的一致性的, 目前solr没有做.