最近因为工作的关系, 花了不少时间读SolrCloud分布式搜索的相关代码, 自己也做了很多solr源码的相关笔记, 本来想趁这次十一假期总结整理一下, 写一篇solr源码分析的文章, 但是后来发现因为solr本身的复杂性, 如果事无巨细的写源码分析, 很可能就陷在细节出不来了, 这样的结果就是读我这个源码分析还不如直接去读solr源码, 因此后来转换了思路, 本文主要想讲两个主题:
-
目前solr(8.6.0)源码的分布式搜索实现方式, 这部分主要是基于对solr的源码分析.
-
尝试对solr的分布式方式做自己的分析, 为什么这么设计? 目前的设计有什么漏洞? 这部分主要是基于阅读solr wiki和jira里面作者记录的设计和实现思路, 相关资料附在了文章最后.
Warm up: 什么是SolrCloud
SolrCloud是solr对分布式搜索的实现, 分布式搜索主要涉及到两个概念, shard和replica.
从作用上, replica主要是做负载均衡/容灾, 本质就是把一个服务器复制N份, 然后将请求均匀分发到N个服务器上.
shard是将索引拆分, 比如一共要索引1000w文档, 如果都存在一个服务器上, 那么可能在不考虑高QPS的情况下, 单一请求的响应时间都已经是不能接受的了, 因此可以将1000w文档存在5个服务器上, 每个服务器保存一份子索引, 也就是分片(shard), 比如服务器A保存文档集[0,200w), 服务器B保存[200w,400w) … 这样当查询的时候, 多个shard可以并发查询, 然后再将所有shard返回的结果做合并. 值得一提的是, 每一个shard的对应的是一份完整的lucene索引, 是可以自己直接写lucene代码读取的.
在SolrCloud中, shard和replica是配合使用的, 比如一个collection可以分3个shard, 然后每个shard可以分2个replica, 每个replica对应的就是一份lucene索引. 因此实际上就有3*2=6个luc