無(wú)論是垂直搜索，還是通用搜索引擎，對(duì)外提供搜索服務(wù)其壓力都比較大，經(jīng)常有垂直電商在做活動(dòng)的時(shí)候服務(wù)器宕機(jī)。對(duì)面訪問(wèn)壓力比較大的情況，一般的應(yīng)對(duì)方法就是【集群】+【負(fù)載均衡】。Solr提供了兩種解決方案來(lái)對(duì)應(yīng)訪問(wèn)壓力。其一是Replication，其一是SolrCloud。

Replication采用了master/slave模式，用讀寫(xiě)分離的思想來(lái)提高對(duì)外服務(wù)能力。但本質(zhì)上還是單兵作戰(zhàn)。Master/slave模式在數(shù)據(jù)庫(kù)領(lǐng)域應(yīng)用廣泛，像MySQL，Redis等主流的數(shù)據(jù)庫(kù)都實(shí)現(xiàn)這一功能。Replication的另一個(gè)功能就是數(shù)據(jù)備份。

SolrCloud采用Zookeeper作為配置中心，對(duì)索引數(shù)據(jù)進(jìn)行分片(shard)，實(shí)現(xiàn)了真正的分布式搜索。像Hadoop,HBase,Storm等分布式系統(tǒng)都是建立在Zookeeper基礎(chǔ)之上的。

個(gè)人認(rèn)為二者沒(méi)有誰(shuí)優(yōu)誰(shuí)劣，應(yīng)用場(chǎng)景不同而已。

本文主要探究Replication的實(shí)現(xiàn)原理。

1.Replication的配置

Replication在solrconfig.xml中默認(rèn)是關(guān)閉的，要打開(kāi)很簡(jiǎn)單。對(duì)于Replication，首先需要確定Solr服務(wù)的角色。Solr服務(wù)的角色有三種[master],[slave],[repeater]。這三種角色的配置如下：

Master配置：

Slave配置：

Repeater配置：

Repeater就是一個(gè)solr服務(wù)器既是master，又是slave。為什么需要Repeater角色呢？我們?cè)囅?#xff0c;如果一個(gè)master服務(wù)器同時(shí)帶上10個(gè)slave甚至100個(gè)slave，會(huì)出現(xiàn)什么情況？Master很容易就被累死了。就算不累死，網(wǎng)絡(luò)帶寬也會(huì)很容易被占用干凈。假如我們需要4臺(tái)的集群，但是每個(gè)master又只能帶2臺(tái)slave，通過(guò)repeater就很容易實(shí)現(xiàn)。

2.?replication的工作原理

通過(guò)配置我們知道replication的功能是通過(guò)ReplicationHandler來(lái)實(shí)現(xiàn)的。通過(guò)以ReplicationHandler為切入口，應(yīng)該能很容易地追溯到replication的運(yùn)行過(guò)程。

2.1?slave端的運(yùn)行過(guò)程

Solr在啟動(dòng)的過(guò)程中會(huì)通過(guò)ReplicationHandler.inform()方法，按照slave的配置啟動(dòng)一個(gè)定時(shí)任務(wù)，定時(shí)向master端發(fā)起同步請(qǐng)求。任務(wù)的代碼如下：

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");

}

定時(shí)任務(wù)的時(shí)間間隔是

slave端對(duì)master而言是透明的。換句話說(shuō)，master與slave之間的通信是無(wú)狀態(tài)的http連接。Slave端通過(guò)發(fā)送不同的command從Server端取得數(shù)據(jù),即在數(shù)據(jù)同步的過(guò)程中，slave端是占主導(dǎo)作用的。這也是為什么最好先從slave端入手。

一次replicate操作關(guān)鍵步驟如下：

當(dāng)然還會(huì)有細(xì)節(jié)的處理，比如系統(tǒng)緩存同步、數(shù)據(jù)校驗(yàn)，日志記錄等等……處理全過(guò)程都是以SnapPuller.fetchLatestIndex()方法為主線進(jìn)行的，如果跟蹤源碼，則重點(diǎn)關(guān)注該方法。

2.2?master端的運(yùn)行過(guò)程

由于master端是被動(dòng)的(即master接收slave端傳遞過(guò)來(lái)的命令，然后依照命令執(zhí)行)，所以master端的工作過(guò)程相對(duì)比較簡(jiǎn)單。值得注意的是，通過(guò)master端可以更好的理解solr索引更新的過(guò)程。

1.CMD_INDEX_VERSION命令

通過(guò)該命令可以得到索引的latestVersion和latestGeneration。其中l(wèi)astestVersion其實(shí)就是索引的更新時(shí)間點(diǎn)，而latestGeneration就是存儲(chǔ)在SegmentInfos中的generation信息。通過(guò)這兩個(gè)信息的對(duì)比，就可以判斷出slave端的索引是否需要更新。

2.CMD_GET_FILE_LIST命令

通過(guò)該命令可以得到需要同步的索引文件信息。

3.CMD_GET_FILE命令

通過(guò)該命令可以下載文件。該命令執(zhí)行次數(shù)由文件大小和CMD_GET_FILE_LIST得到的文件數(shù)量決定。下載文件每次最多下載1M，如果文件大于1M，則分多次下載。數(shù)據(jù)正確性的校驗(yàn)由Adler32算法來(lái)完成。關(guān)于Adler32算法，這里不細(xì)說(shuō)。關(guān)于詳細(xì)代碼，可以參看DirectoryFileStream.write()方法。

綜上，一次replication操作在master端的運(yùn)行過(guò)程就是執(zhí)行這三種命令的過(guò)程。

總結(jié)

以上是生活随笔為你收集整理的solr mysql原理_solr replication原理探究的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。