solrCloud有多个shard,一个shard有一个或者多个replica,那么再solrj发起添加documnet(这里称作update请求)或者是查询(这里叫做query请求)的时候,是如何向最终的各个solr的不同的shard的replica发送的请求呢?我看了看solrj中的CloudSolrServer的处理请求的源码以及solr服务端的部分源码,终于弄懂了,几个笔记如下,方便大家和我,这篇博客只是写CompositeIdDocRouter的collection,对于ImplicitRouter的集合在另一篇博客中。
先说一下solrj的实现原理和过程,solrj是使用一个叫做solrServer的类发起请求的,无论是update还是query,都是一个请求,他们只包含一些请求的参数,都需要一个server来具体的域solr服务器交互,solrServer就是起到这样的一个功能。solrServer是一个接口,他有多个实现,比如我们在单机版的solr中使用的HttpSolrServer,就是直接使用http协议发起的请求。在solrj提供的实现中还有一个是LBHttpSolrServer,他也是使用http协议发起的请求,只不过他的内部是有多个url,也就是服务器是有多个的,多个url中他是随机抽取一个进行请求的,如果随机抽取的url可以访问成功,那就操作成功,否则会将当前访问的url设置为僵尸的,然后继续访问下一个url,我们看一下LBhttpSolrServer的request方法:
@Override
public NamedList<Object> request(final SolrRequest request)//处理请求,请求可以是update的或者是query的。
throws SolrServerException, IOException {
Exception ex = null;
ServerWrapper[] serverList = aliveServerList;//当前可以访问的所有的url
int maxTries = serverList.length;
Map<String,ServerWrapper> justFailed = null;
for (int attempts=0; attempts<maxTries; attempts++) {//尝试所有的可能的url。
int count = counter.incrementAndGet();//当前的LBHttpSolrServer发起http请求的总次数
ServerWrapper wrapper = serverList[count % serverList.length];//根据次数计算随机值,获得一个随机的HttpSolrServer,ServerWrapper就是封装的HttpSolrServer,
wrapper.lastUsed = System.currentTimeMillis();
try {
return wrapper.solrServer.request(request);//调用获得server发起请求,如果成功,则返回
} catch (SolrException e) {//http请求成功,但是参数不对,则抛出这个异常
// Server is alive but the request was malformed or invalid
throw e;
} catch (SolrServerException e) {
if (e.getRootCause() instanceof IOException) {//http请求失败,比如是网络出现问题,或者当前的url代表的server已经死亡
ex = e;
moveAliveToDead(wrapper);//将这个url设置为死亡状态
if (justFailed == null) justFailed = new HashMap<String,ServerWrapper>();
justFailed.put(wrapper.getKey(), wrapper);
} else {
throw e;
}
} catch (Exception e) {
throw new SolrServerException(e);
}
}
// try other standard servers that we didn't try just now 如果上面的所有的url都不能访问成功,则继续访问那些之前别标记为死亡的url,看看他们能否访问成功。
for (ServerWrapper wrapper : zombieServers.values()) {
if (wrapper.standard==false || justFailed!=null && justFailed.containsKey(wrapper.getKey())) continue;
try {
NamedList<Object> rsp = wrapper.solrServer.request(request);
// remove from zombie list *before* adding to alive to avoid a race that could lose a server
zombieServers.remove(wrapper.getKey());//如果访问成功,则从死亡的server中移除
addToAlive(wrapper);//添加到存活的url中
return rsp;
} catch (SolrException e) {
// Server is alive but the request was malformed or invalid
throw e;
} catch (SolrServerException e) {
if (e.getRootCause() instanceof IOException) {
ex = e;
// still dead
} else {
throw e;
}
} catch (Exception e) {
throw new SolrServerException(e);
}
}
//如果所有的url都访问了,还是失败,则报错。
if (ex == null) {
throw new SolrServerException("No live SolrServers available to handle this request");
} else {
throw new SolrServerException("No live SolrServers available to handle this request", ex);
}
}
经过上面之后,可以对LBHttpSolrServer 做一个初步的了解了,他就是对所有的url做轮训的,可以这么理解。
接下来便是CloudSolrServer了,他在处理请求的时候,对于update的,会在客户端根据document的id进行hash,然后将其添加到对应的shard中,如果一个shard有超过一个replica,会强行选择leader,这一块涉及到的代码非常多,我这里就不再贴代码了。对于query的请求,则是将当前collection的所有的shard的所有的replica的url都获取到,然后使用一个LBHttpSolrServer进行查询任意一个replica,也就是查询的时候,solr是在服务端进行的组装来自于不同的shard的document,在某一个replica中会向其他的shard发起请求,然后再返回组装好的response,对于客户端是透明的。
代码如下:
@Override
public NamedList<Object> request(SolrRequest request)
throws SolrServerException, IOException {
connect();
ClusterState clusterState = zkStateReader.getClusterState();//读取zk中的集群状态节点
boolean sendToLeaders = false;
List<String> replicas = null;
if (request instanceof IsUpdateRequest) {//如果这次的请求是update的,则进入if
if (request instanceof UpdateRequest) {
NamedList response = directUpdate((AbstractUpdateRequest) request,//直接调用directUpdate,
clusterState);
if (response != null) {
return response;
}
}
sendToLeaders = true;
replicas = new ArrayList<String>();
}
SolrParams reqParams = request.getParams();
if (reqParams == null) {
reqParams = new ModifiableSolrParams();
}
List<String> theUrlList = new ArrayList<String>();
if (request.getPath().equals("/admin/collections")
|| request.getPath().equals("/admin/cores")) {
Set<String> liveNodes = clusterState.getLiveNodes();
for (String liveNode : liveNodes) {
theUrlList.add(zkStateReader.getBaseUrlForNodeName(liveNode));
}
} else {//下面的是处理的query的
String collection = reqParams.get("collection", defaultCollection);//如果没有对此CloudSolrServer指定collection,也没有在参数中设置collection的参数,则报错
if (collection == null) {
throw new SolrServerException(
"No collection param specified on request and no default collection has been set.");
}
//根据上面的collection字符串来获得集合的名字,我这里假设此CloudSolrServer只有一个collection
Set<String> collectionsList = getCollectionList(clusterState, collection);
if (collectionsList.size() == 0) {
throw new SolrException(ErrorCode.BAD_REQUEST,
"Could not find collection: " + collection);
}
// TODO: not a big deal because of the caching, but we could avoid looking
// at every shard
// when getting leaders if we tweaked some things
// Retrieve slices from the cloud state and, for each collection
// specified,
// add it to the Map of slices.
Map<String,Slice> slices = new HashMap<String,Slice>();
for (String collectionName : collectionsList) {//假设只有一个collection,实际情况也是只有一个
Collection<Slice> colSlices = clusterState.getActiveSlices(collectionName);//获得此集合的所有的存活的shard,每个slice就是shard的意思
if (colSlices == null) {
throw new SolrServerException("Could not find collection:"
+ collectionName);
}
ClientUtils.addSlices(slices, collectionName, colSlices, true);//将colSlice添加到上面的slices中
}
Set<String> liveNodes = clusterState.getLiveNodes();
List<String> leaderUrlList = null;
List<String> urlList = null;
List<String> replicasList = null;
// build a map of unique nodes
// TODO: allow filtering by group, role, etc
Map<String,ZkNodeProps> nodes = new HashMap<String,ZkNodeProps>();
List<String> urlList2 = new ArrayList<String>();
for (Slice slice : slices.values()) {//循环所有的shard,
for (ZkNodeProps nodeProps : slice.getReplicasMap().values()) {//对一个shard,获得所有的replica的url
ZkCoreNodeProps coreNodeProps = new ZkCoreNodeProps(nodeProps);
String node = coreNodeProps.getNodeName();
if (!liveNodes.contains(coreNodeProps.getNodeName())
|| !coreNodeProps.getState().equals(ZkStateReader.ACTIVE)) continue;
if (nodes.put(node, nodeProps) == null) {
if (!sendToLeaders || (sendToLeaders && coreNodeProps.isLeader())) {//在查询的时候sendToLeaders是false,进入if
String url;
if (reqParams.get("collection") == null) {
url = ZkCoreNodeProps.getCoreUrl(
nodeProps.getStr(ZkStateReader.BASE_URL_PROP),
defaultCollection);
} else {
url = coreNodeProps.getCoreUrl();//获得此replica的url
}
urlList2.add(url);//
} else if (sendToLeaders) {
String url;
if (reqParams.get("collection") == null) {
url = ZkCoreNodeProps.getCoreUrl(
nodeProps.getStr(ZkStateReader.BASE_URL_PROP),
defaultCollection);
} else {
url = coreNodeProps.getCoreUrl();
}
replicas.add(url);
}
}
}
}
if (sendToLeaders) {
leaderUrlList = urlList2;
replicasList = replicas;
} else {
urlList = urlList2;//设置为所有的shard的所有的replica的url
}
if (sendToLeaders) {
theUrlList = new ArrayList<String>(leaderUrlList.size());
theUrlList.addAll(leaderUrlList);
} else {
theUrlList = new ArrayList<String>(urlList.size());
theUrlList.addAll(urlList);
}
Collections.shuffle(theUrlList, rand);
if (sendToLeaders) {
ArrayList<String> theReplicas = new ArrayList<String>(replicasList.size());
theReplicas.addAll(replicasList);
Collections.shuffle(theReplicas, rand);
theUrlList.addAll(theReplicas);
}
}
LBHttpSolrServer.Req req = new LBHttpSolrServer.Req(request, theUrlList);//最后发起的请求就是轮训所有的shard的所有的replica的url,并不是每一个shard一个,所以可以总结是在服务端进行的封装。
LBHttpSolrServer.Rsp rsp = lbServer.request(req);
return rsp.getResponse();
}
经过上面已经看到对于query的请求的操作了,即将请求随机的发到一个replica中,在replica中进行分发到各个shard中,这个想象也是这样,因为CompositeIdRouter是计算的id的hash值,无法根据hash值直接判断某个shard中是否存在某个doc,所以在查询的时候必须向所有的shard发请求。
下面看下update的操作方法,即directUpdate方法 ,在这个方法中有个很关键的方法是:Map<String, LBHttpSolrServer.Req> routes = updateRequest.getRoutes(router, col, urlMap, routableParams, this.idField);解释一下,updateRequest表示本次的更新操作,里面含有要添加的doc和删除的id、query,router表示当前的集合的router,col表示当前的集合的描述对象,urlMap表示当前集合的多个shard对应的对个的replica,这个方法用来对所有要更新的document找到对应的slice,也就是shard,我们进入到 updateRequest.getRoutes方法(只截取了一部分)
Set<Entry<SolrInputDocument,Map<String,Object>>> entries = documents.entrySet();//当前的request里要添加的documents
for (Entry<SolrInputDocument,Map<String,Object>> entry : entries) {//循环所有的doc
SolrInputDocument doc = entry.getKey();
Object id = doc.getFieldValue(idField);//得到idField的值
if (id == null) {
return null;
}
Slice slice = router.getTargetSlice(id.toString(), doc, null, col);//router根据id值计算hash值,然后根据hash值得到一个slice,这个部分的实现看CompositeIdRouter的博客
if (slice == null) {
return null;
}
List<String> urls = urlMap.get(slice.getName());//根据得到的slice的名字得到这个slice的多个replica的url,第一个表示leader
String leaderUrl = urls.get(0);//某个slice的leader
LBHttpSolrServer.Req request = (LBHttpSolrServer.Req) routes.get(leaderUrl);//将添加操作转发到leader上。
。。。。。。//没有截取
}
上面的部分解释了update的请求,会将一个doc根据其id域计算hash值并找到对应的slice(这部分的实现在CompositeIdRouter中实现),然后将请求转发到这个slice的leader上。
看到这里,就看懂了在router是CompositeIDRouter的情况下CloudSOlrServer的客户端(solrj中)实现原理了。