solr mysql原理_solr replication原理探究
無論是垂直搜索，還是通用搜索引擎，對外提供搜索服務其壓力都比較大，經常有垂直電商在做活動的時候服務器宕機。對面訪問壓力比較大的情況，一般的應對方法就是【集群】+【負載均衡】。Solr提供了兩種解決方案來對應訪問壓力。其一是Replication，其一是SolrCloud。
Replication采用了master/slave模式，用讀寫分離的思想來提高對外服務能力。但本質上還是單兵作戰。Master/slave模式在數據庫領域應用廣泛，像MySQL，Redis等主流的數據庫都實現這一功能。Replication的另一個功能就是數據備份。
SolrCloud采用Zookeeper作為配置中心，對索引數據進行分片(shard)，實現了真正的分布式搜索。像Hadoop,HBase,Storm等分布式系統都是建立在Zookeeper基礎之上的。
個人認為二者沒有誰優誰劣，應用場景不同而已。
本文主要探究Replication的實現原理。
1.Replication的配置
Replication在solrconfig.xml中默認是關閉的，要打開很簡單。對于Replication，首先需要確定Solr服務的角色。Solr服務的角色有三種[master],[slave],[repeater]。這三種角色的配置如下：
Master配置：
Slave配置：
Repeater配置：
Repeater就是一個solr服務器既是master，又是slave。為什么需要Repeater角色呢？我們試想，如果一個master服務器同時帶上10個slave甚至100個slave，會出現什么情況？Master很容易就被累死了。就算不累死，網絡帶寬也會很容易被占用干凈。假如我們需要4臺的集群，但是每個master又只能帶2臺slave，通過repeater就很容易實現。
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");
}
定時任務的時間間隔是
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端的運行過程就是執行這三種命令的過程。
總結
以上是生活随笔為你收集整理的solr mysql原理_solr replication原理探究的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： bem什么意思_BEM命名法
- 下一篇： Maven中Spring-Data-Re