http://m.blog.csdn.net/blog/qing419925094/34444897 算法
Replication的实现原理。缓存
1. Replication的配置服务器
Replication在solrconfig.xml中默认是关闭的,要打开很简单。对于Replication,首先须要肯定Solr服务的角色。Solr服务的角色有三种[master],[slave],[repeater]。这三种角色的配置以下:网络
Master配置:ide
wKioL1ORrUSjuF5WAAHACrfhpPg906.jpgfetch
Slave配置:.net
wKiom1ORrYjBm0H2AAHm6b1jVEM579.jpg 日志
Repeater配置:orm
wKioL1ORrWvCaLsxAAHS6MjYxf0489.jpg xml
Repeater就是一个solr服务器既是master,又是slave。为何须要Repeater角色呢?咱们试想,若是一个master服务器同时带上10个slave甚至100个slave,会出现什么状况?Master很容易就被累死了。就算不累死,网络带宽也会很容易被占用干净。假如咱们须要4台的集群,可是每一个master又只能带2台slave,经过repeater就很容易实现。
wKioL1ORrXuz9HybAADx_Qm5pYw487.jpg
2. replication的工做原理
经过配置咱们知道replication的功能是经过ReplicationHandler来实现的。经过以ReplicationHandler为切入口,应该能很容易地追溯到replication的运行过程。
2.1 slave端的运行过程
Solr在启动的过程当中会经过ReplicationHandler.inform()方法,按照slave的配置启动一个定时任务,定时向master端发起同步请求。任务的代码以下:
private void startExecutorService() {
Runnable task = new Runnable() {
@Override
public void run() {
if (pollDisabled.get()) {
LOG.info("Poll disabled");
return;
}
try {
executorStartTime = System.currentTimeMillis();
replicationHandler.doFetch(null, false);
} catch (Exception e) {
LOG.error("Exception in fetching index", e);
}
}
};
executorService = Executors.newSingleThreadScheduledExecutor(
new DefaultSolrThreadFactory("snapPuller"));
long initialDelay = pollInterval - (System.currentTimeMillis() % pollInterval);
executorService.scheduleAtFixedRate(task, initialDelay, pollInterval, TimeUnit.MILLISECONDS);
LOG.info("Poll Scheduled at an interval of " + pollInterval + "ms");
}
定时任务的时间间隔是
wKiom1ORrePTa48kAABxYCuklTw119.jpg
slave端对master而言是透明的。换句话说,master与slave之间的通讯是无状态的http链接。Slave端经过发送不一样的command从Server端取得数据,即在数据同步的过程当中,slave端是占主导做用的。这也是为何最好先从slave端入手。
一次replicate操做关键步骤以下:
固然还会有细节的处理,好比系统缓存同步、数据校验,日志记录等等……处理全过程都是以SnapPuller.fetchLatestIndex()方法为主线进行的,若是跟踪源码,则重点关注该方法。
2.2 master端的运行过程
因为master端是被动的(即master接收slave端传递过来的命令,而后依照命令执行),因此master端的工做过程相对比较简单。值得注意的是,经过master端能够更好的理解solr索引更新的过程。
1.CMD_INDEX_VERSION 命令
经过该命令能够获得索引的latestVersion和latestGeneration。其中lastestVersion其实就是索引的更新时间点,而latestGeneration就是存储在SegmentInfos中的generation信息。经过这两个信息的对比,就能够判断出slave端的索引是否须要更新。
2. CMD_GET_FILE_LIST命令
经过该命令能够获得须要同步的索引文件信息。
3. CMD_GET_FILE 命令
经过该命令能够下载文件。该命令执行次数由文件大小和CMD_GET_FILE_LIST获得的文件数量决定。下载文件每次最多下载1M,若是文件大于1M,则分屡次下载。数据正确性的校验由Adler32 算法来完成。关于Adler32算法,这里不细说。关于详细代码,能够参看DirectoryFileStream.write()方法。
综上,一次replication操做在master端的运行过程就是执行这三种命令的过程。