solr源碼分析

⑴ java web 怎麼用solr

我們下載的Solr包後，進入Solr所在的目錄，我們可以看到以下幾個目錄：build、client、dist、example、lib、site、src。下面分別對其進行介紹。
1) build：該目錄是在ant build過程中生成的，其中包含了未被打包成jar或是war的class文件以及一些文檔文件。
2) client：該目錄包含了特定語言的Solr客戶端API，使得使用其他語言的用戶能通過HTTP用XML與Solr進行通話。現在該目錄裡面雖然包含javascript、python、ruby三個子目錄，但是到目前為止只包含一部分的ruby的代碼，其他語言仍是空的。另外，Solr的Java客戶端稱為SolrJ，其代碼位於src/solrj目錄下面。在之後的文章中我會詳細介紹Solr客戶端的使用。
3) dist：該目錄包含build過程中產生的war和jar文件，以及相關的依賴文件。還記得上一篇文章中，我們在build 1.4版本的Solr源代碼後需要部署example嗎？其實就是將該目錄下面的apache-solr-1.4.war部署到Jetty上面去，並重命名為solr.war。
4) example：這個目錄實際上是Jetty的安裝目錄。其中包含了一些樣例數據和一些Solr的配置。
其中一些子目錄也比較重要，這里也對它們稍作介紹。
l example/etc：該目錄包含了Jetty的配置，在這里我們可以將Jetty的默認埠從8983改為80埠。
l 將其中的8983埠換成80埠。注意更改埠後啟動Jetty可能會提示你沒有許可權，你需要使用sudo java -jar start.jar來運行。
l example/multicore：該目錄包含了在Solr的multicore中設置的多個home目錄。在之後的文章中我會對其進行介紹。
l example/solr：該目錄是一個包含了默認配置信息的Solr的home目錄。
詳見下面的「solr home說明」
l example/webapps：Jetty的webapps目錄，該目錄通常用來放置Java的Web應用程序。在Solr中，前面提到的solr.war文件就部署在這里。
5) lib：該目錄包含了所有Solr的API所依賴的庫文件。其中包括Lucene，Apache commons utilities和用來處理XML的Stax庫。
6) site：該目錄僅僅包含了Solr的官網的網頁內容，以及一些教程的PDF文檔。
7) src：該目錄包含了Solr項目的整個源代碼。這里對其各個子目錄也做相應的介紹。
l src/java：該目錄存放的是Solr使用Java編寫的源代碼。
l src/scripts：該目錄存放的是配置Solr伺服器的Unix BashShell腳本，在後面介紹多伺服器配置中將會有重要的作用。
l src/solrj：前面提到過該目錄存放的是Solr的Java版本的客戶端代碼。
l src/test：該目錄存放的是測試程序的源代碼和測試文件。
l src/webapp：該目錄存放的是管理Solr的Web頁面，包括Servlet和JSP文件，其構成了前面提到的WAR文件。管理Solr的JSP頁面在web/admin目錄下面，如果你有興趣折騰Solr可以找到相應的JSP的頁面對其進行設置
1.4.2 Solr home說明
所謂的Solr home目錄實際上是一個運行的Solr實例所對應的配置和數據（Lucene索引）。在上一篇文章中我提到過在Solr的example/solr目錄就是一個Solr用做示例的默認配置home目錄。實際上example/multicore也是一個合法的Solr home目錄，只不過是用來做mult-core設置的。那麼我們來看看example/solr這個目錄裡面都有些什麼。
example/solr目錄下主要有以下一些目錄和文件：
1) bin：如果你需要對Solr進行更高級的配置，該目錄建議用來存放Solr的復制腳本。
2) conf ：該目錄下麵包含了各種配置文件，下面列出了兩個最為重要的配置文件。其餘的.txt和.xml文件被這兩個文件所引用，如用來對文本進行特殊的處理。
l conf/schema.xml：該文件是索引的schema，包含了域類型的定義以及相關聯的analyzer鏈。
l conf/solrconfig.xml：該文件是Solr的主配置文件。
l conf/xslt：該目錄包含了各種XSLT文件，能將Solr的查詢響應轉換成不同的格式，如：Atom/RSS等。
3) data：包含了Lucene的二進制索引文件。
4) lib：該目錄是可選的。用來放置附加的Java JAR文件，Solr在啟動時會自動載入該目錄下的JAR文件。這就使得用戶可以對Solr的發布版本（solr.war）進行擴展。如果你的擴展並不對Solr本身進行修改，那麼就可以將你的修改部署到JAR文件中放到這里。

Solr是如何找到運行所需要的home目錄的呢？
Solr首先檢查名為solr.solr.home的Java系統屬性，有幾種不同的方式來設置該Java系統屬性。一種不管你使用什麼樣的Java應用伺服器或Servlet引擎都通用的方法是在調用Java的命令行中進行設置。所以，你可以在啟動Jetty的時候顯式地指定Solr的home目錄java -Dsolr.solr.home=solr/ -jar start.jar。另一種通用的方法是使用JNDI，將home目錄綁定到java:comp/env/solr/home。並向src/webapp/web/WEB-INF/web.xml添加以下一段代碼：
1 <env-entry>
2 <env-entry-name>solr/home</env-entry-name>
3 <env-entry-value>solr/</env-entry-value>
4 <env-entry-type>java.lang.String</env-entry-type>
5 </env-entry>
實際上這段XML在web.xml文件中已經存在，你只需要把原來注釋掉的xml取消注釋，添加你所要指向的home目錄即可。因為修改了web.xml文件，所以你需要運行antdist-war來重新打包之後再部署WAR文件。

最後，如果Solr的home目錄既沒有通過Java系統屬性指定也沒有通過JNDI指定，那麼他將默認指向solr/。
在產品環境中，我們必須設置Solr的home目錄而不是讓其默認指向solr/。而且應該使用絕對路徑，而不是相對路徑，因為你有可能從不同的目錄下面啟動應用伺服器。

註：Jetty 是一個開源的servlet容器，它為基於Java的web內容，例如JSP和servlet提供運行環境。Jetty是使用Java語言編寫的，它的API以一組JAR包的形式發布。開發人員可以將Jetty容器實例化成一個對象，可以迅速為一些獨立運行（stand-alone）的Java應用提供網路和web連接。

我們先從使用者的角度出發，最先看到的當然是servlet,因為Solr本身是個獨立的網路應用程序，需要在Servlet容器中運行來提供服務，所以servlet是用戶接觸的最外層。我們看看org.apache.solr.servlet包。這個包很簡單，只有兩個類：SolrServlet和SolrUpdateServlet.我們很容易從類名中猜出這兩個類的用途。
SolrServlet類繼承HttpServlet類，只有四個方法：
· init()
· destroy()
· doGet()
· doPost()
SolrServlet類中除了普通的Java類對象（包括Servlet相關的）外，有四個Solr本身的類，還有一個Solr本身的異常。其中兩個類和一個異常屬於org.apache.solr.core包，兩個類屬於org.apache.solr.request包。屬於core包的有：
· Config:
· SolrCore:
屬於request包的有：
· SolrQueryResponse:
· QueryResponseWriter:
分析一下這個SolrServlet類。首先servlet會調用init()方法進行初始化：通過Context查找java:comp/env/solr/home來確定Solr的主目錄（home），接著調用Config.setInstanceDir(home)方法設置這個實例的目錄。然後通過SolrCore.getSolrCore()來獲得一個SolrCore實例。destroy()方法將會在Servlet對象銷毀時調用，僅僅調用core.close()關閉SolrCore實例。
當用戶請求進來時doPost()簡單地將任務交給doGet()完成，主要的任務由doGet()完成。分析一下doGet()方法：
1) 使用SolrCore和doGet()參數request生成一個SolrServletRequest對象(注意：這個SolrServletRequest類不是公開類，位於org.apache.solr.servlet包中，繼承了SolrQueryRequestBase類，僅僅接受SolrCore和HttpServletRequest對象作為參數)
2) 然後SolrCore執行execute()方法（參數為SolrServletRequest和SolrQueryResponse）
由此可見，真正的處理核心是SolrCore的execute方法

⑵ solr如何實現多語言搜索

ANT_HOME：E:\Work\apache-ant\1.9.1 (這里為你自己解壓縮的目錄) PATH：%ANT_HOME%\bin （這個設置是為了方便在dos環境下操作）
查看是否安裝成功，在命令行窗口中輸入命令ant，若出現結果:

說明ant安裝成功！因為ant默認運行build.xml文件，這個文件需要我們建立。現在就可以進行build Solr源碼了。在命令行窗口中進入到你的Solr源碼目錄，輸入ant會出現當前build.xml使用提示信息。

其它的先不用管它，我們只要針對我們使用的IDE進行build就行了，如果使用eclipse就在命令行輸入：ant eclipse.如果使用IntelliJ IDEA 就在命令行輸入：ant idea。這樣就能進行build了

⑶ solrj的CloudSolrClient源碼分析及為什麼查詢慢

solrj針對solrcloud提供了CloudSolrClient，用於對集群環境solr操作，從一個測試例子，一步步深入，看看CloudSolrClient是如何做查詢操作的

1、使用CloudSolrClient發起一個查詢請求

2、接著調用CloudSolrClient的request方法

3、CloudSolrClient的request方法中，首先回去獲取請求中的collection名字，如果沒有，獲取默認設置的collcetion，然後調用requestWithRetryOnStaleState方法

4、requestWithRetryOnStaleState方法中，先去連接zk獲取solrclound注冊在zk上的信息

5、獲取zk上的信息，經過處理後，封裝到request中，調用sendRequest方法

6、在sendRequest中，會獲取每個片的每個replicat的url與注冊在zk上的live url做一個交集，得到一個查詢url集合，然後創建一個LBHttpSolrClient，請求solrcloud

7、LBHttpSolrClient的request中會在for循環中挨個的輪詢上一個步驟中放入的urllist發起http查詢請求

在rsp合並結果，並返回

⑷ solr提供的源碼怎麼打成jar包

1、將解壓包中的solr-4.7.1/dist/solr-4.7.1.war復制到tomcat_dir/webapps/目錄，並命名為solr.war。 2、將solr-4.7.1/example/lib/ext/目錄下的jar文件復制到tomcat/lib目錄下，將solr-4.7.1/example/resources/下的log4j.properties文件復制到...

⑸ solr和elasticsearch對比，有啥差別嗎

從兩個方面對ElasticSearch和Solr進行對比，從關系型資料庫中的導入速度和模糊查詢的速度。

單機對比

1. Solr 發布了4.0-alpha，試了一下，發現需要自己修改schema，好處是它自帶一個data importer。在自己的計算機上測試了一下，導入的性能大概是：14分鍾導入 3092730 條記錄，約合 3682條/秒。

2. 3百萬條記錄的情況下，模糊查詢和排序基本都在1秒內返回

3. 剛才的測試，是每個field單獨存儲，現在修改了一下配置文件，增加了一個Field，所有的field都拷貝一份到text這個field裡面去，導入的性能大概是：19分鍾導入了3092730 條記錄，約合 2713條/秒

4. 3百萬條記錄的情況下，針對text的模糊查詢基本在1秒內返回，但是針對所有記錄的排序，大概要2~3秒

5. 使用 elasticsearch 0.19.8，預設配置，用單任務導入，導入性能是：20分鍾導入了3092730 條記錄，約合2577條/秒

6. 3百萬條記錄的情況下，查詢基本上在1秒內返回，但是模糊查詢比較慢，第一次要10秒，後來大概要1~3秒。加上排序大概需要5秒，整體排序基本100ms

查詢及排序的指令：

{

"query": {

"query_string": {

"query": "*999*"

}

},

"sort": [

{

"TIME_UP": {

"order": "asc"

}

}

]

}

7. Es0.19.8，用兩個任務導入，導入性能是：13分鍾導入了3092730 條記錄，約合3965條/秒

8. Solr全部建好索引後，佔用磁碟空間是1.2G，es佔用磁碟空間是4G

單機對比2

在一台Intel i7，32G內存的機器上，重新跑這兩個的對比。不過有個重大的區別在於，Solr是在這台性能很好的機器上跑，而es的導入進程則是在一台Intel 四核 2.5G，4G內存的機器上跑的，也許會有性能的差異。ES版本0.19.8，Solr版本4.0-ALPHA。

1. Solr的導入性能：3400萬條記錄，用時62分鍾，平均9140條/秒，佔用空間12.75G

2. 使用 *999* 這樣的模糊查詢，3秒以內返回，稍長一點的查詢條件 *00100014*，也是2~3秒返回

3. Es的導入性能（設置Xmx為10G）：3400萬條記錄，用時40分鍾，平均14167條/秒，佔用空間33.26G，客戶端採用4個並發。

4. 使用 *999* 這樣的模糊查詢，9秒返回，稍長一點的查詢條件 *00100014*，11.8秒返回

5. 如果不是針對所有欄位查詢，而是針對某個特定欄位，比如 SAM_CODE: *00100014*，那麼也是1秒以內返回。

6. 結論：es的查詢效率也可以很高，只是我們還不會用。

7. 結論2：es有個設置是把所有欄位放一塊的那個，預設是放一起，但是不知道為什麼沒起到應有的作用。

備註：

1. Solr第一次的那個內存使用的是預設設置，這次改為10G，結果導入性能反而變差了，400萬條記錄，用了8分鍾，平均8333條/秒，不知道為什麼。

2. 改回預設的內存配置，導入速度仍然慢。

3. 重啟Linux，用10G的內存配置，再導入，5030萬條記錄，用時92分，約9112條/秒，說明導入速度和內存配置沒有大差別

4. 在10G配置的情況下，檢索速度也差別不大。

5. 為了搞清楚lucene4.0和solr4.0的進步有多大，下載了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起來進行測試，導入性能為：3400萬條記錄，用時55分鍾，約10303條/秒，佔用空間13.85G。查詢性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的結果（5000萬結果當中，*999*第一次2.6s，*00100014*第一次2.5s）來說，慢了很多，與es的性能差不多，因此，也許lucene4.0真的對性能有大幅提升？

集群對比：

採用4台同樣配置（Intel i7，32G內存）的Centos 6.3組成的集群，進行對比。

1. 首先是es，很方便的就組成了一個Cluster，等上一個3400萬條的Index全部均衡負載之後進行測試，導入到另外一個Index當中。

2. 導入性能：8500萬條記錄，用時72分鍾，約為19676條/秒。在前5千萬條記錄導入時的速度在2萬/條以上，初始的速度在2.2萬/條。佔用空間78.6G（由於有冗餘，實際佔用空間為157.2G）

3. 查詢性能：

*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒

*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒

SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s

SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s

4. Solr4.0-ALPHA，SolrCloud的配置還算簡單，啟動一個ZooKeeper，然後其他三台機器訪問這個地址，就可以組成一個Cloud：

機器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &

其他機器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &

但是在執行 data import 的時候，頻繁出現 OutOfMemoryError: unable to create new native thread。查了很多資料，把Linux的ulimit當中的nproc改成10240，把Xss改成256K，都解決不了問題。暫時沒有辦法進行。

結論

1. 導入性能，es更強

2. 查詢性能，solr 4.0最好，es與solr 3.6持平，可以樂觀的認為，等es採用了lucene4之後，性能會有質的提升

3. Es採用SAM_CODE這樣的查詢性能很好，但是用_all性能就很差，而且差別非常大，因此，個人認為在目前的es情況下，仍然有性能提升的空間，只是現在還沒找到方法。

⑹ solr組件的角色有哪些

Solr它是一種開放源碼的、基於 Lucene Java 的搜索伺服器，易於加入到 Web 應用程序中。

二、Solr 提供了層面搜索(就是統計)、命中醒目顯示並且支持多種輸出格式（包括XML/XSLT 和JSON等格式）。它易於安裝和配置，而且附帶了一個基於 HTTP 的

管理界面。Solr已經在眾多大型的網站中使用，較為成熟和穩定。

三、Solr 包裝並擴展了 Lucene，所以Solr的基本上沿用了Lucene的相關術語。更重要的是，Solr 創建的索引與 Lucene 搜索引擎庫完全兼容。

四、通過對Solr 進行適當的配置，某些情況下可能需要進行編碼，Solr 可以閱讀和使用構建到其他 Lucene 應用程序中的索引。

五、此外，很多 Lucene 工具（如Nutch、 Luke）也可以使用Solr 創建的索引。可以使用 Solr 的表現優異的基本搜索功能，也可以對它進行擴展從而滿足企業的需要。
solr的優點
通過上面Solr的簡介，可知solr的優點包括以下幾個方面：

①高級的全文搜索功能；

②專為高通量的網路流量進行的優化；

③基於開放介面（XML和HTTP）的標准；

④綜合的HTML管理界面；

⑤可伸縮性－能夠有效地復制到另外一個Solr搜索伺服器；

⑥使用XML配置達到靈活性和適配性；

⑦可擴展的插件體系。
solr VS Lucene！？
在比較solr和Lucene之前，要知道什麼是Lucene，那麼首先就來回顧Lucene是個什麼東東？

Lucene是一個基於Java的全文信息檢索工具包，它不是一個完整的搜索應用程序，而是為你的應用程序提供索引和搜索功能。Lucene 目前是 Apache Jakarta(雅加達) 家族中的一個開源項目。也是目前最為流行的基於Java開源全文檢索工具包。目前已經有很多應用程序的搜索功能是基於 Lucene ，比如Eclipse 幫助系統的搜 索功能。Lucene能夠為文本類型的數據建立索引，所以你只要把你要索引的數據格式轉化的文本格式，Lucene 就能對你的文檔進行索引和搜索。
那麼，solr和它相比，是」輸「了？還是「贏」了呢？

其實，Solr與Lucene 並不是競爭對立關系，恰恰相反Solr 依存於Lucene，因為Solr底層的核心技術是使用Lucene 來實現的，Solr和Lucene的本質區別有以下三點：搜索伺服器，企業級和管理。Lucene本質上是搜索庫，不是獨立的應用程序，而Solr是。Lucene專注於搜索底層的建設，而Solr專注於企業應用。Lucene不負責支撐搜索服務所必須的管理，而Solr負責。所以說，一句話概括 Solr: Solr是Lucene面向企業搜索應用的擴展。
下面是solr和 lucene的架構圖： 

這個圖很繁瑣，看不懂，大家不要灰心，在後面的代碼里你就能夠了解了這個圖所講的。

不難看出，綠色的就是lucene的模塊，而藍色的就是solr擴展了lucene。從圖上可以看出以下幾點：

a. 一個真正的擁有動態欄位(Dynamic Field)和唯一鍵(Unique Key)的數據模式(Data Schema) 
b. 對Lucene查詢語言的強大擴展！ 
c. 支持對結果進行動態的分組和過濾 
d. 高級的，可配置的文本分析 
e. 高度可配置和可擴展的緩存機制 
f. 性能優化 
g. 支持通過XML進行外部配置 
h. 擁有一個管理界面 
i. 可監控的日誌 
j. 支持高速增量式更新(Fast incremental Updates)和快照發布(Snapshot Distribution)

說到這，solr的簡介就到此結束了，相信大家也對solr有了初步的了解，下面開始介紹一下solr的常用屬性有哪些？

solr的使用屬性及配置文件
Document 包括一個或多個 Field。Field 包括名稱、內容以及告訴 Solr 如何處理內容的元數據。

例如，Field可以包含字元串、數字、布爾值或者日期，也可以包含你想添加的任何類型，只需用在solr的配置文件中進行相應的配置即可。Field可以使用大量的選項來描述，這些

選項告訴 Solr 在索引和搜索期間如何處理內容。

現在，查看以下圖片 中列出的重要屬性的子集：

在這就先提一下solr的重要文件之一，就是schema.xml的配置文件。

（一） schema.xml

schema.xml這個配置文件可以在你下載solr包的安裝解壓目錄的\solr\example\solr\collection1\conf中找到，它就是solr模式關聯的文件。

打開這個配置文件，你會發現有詳細的注釋。模式組織主要分為三個重要配置：

一、Fieldtype

Fieldtype：就是屬性類型的意思，像int，String，Boolean種類型，而在此配置文件中，FieldType就有這種定義屬性的功能，看下面的圖片： 

圖片上有我們熟悉的int，String，boolean，那麼，後面的配置，是什麼呢？那麼我們就來介紹一下後面的參數：

二、Field

Field：是添加到索引文件中出現的屬性名稱，而聲明類型就需要用到上面的type，如圖所示：

ps：①field: 固定的欄位設置；②dynamicField: 動態的欄位設置,用於後期自定義欄位,*號通配符.例如: test_i就是int類型的動態欄位。

還有一個特殊的欄位Field,一般用於檢索時用的欄位這樣就只對這一個欄位進行索引分詞就行了Field的dest欄位如果有多個source一定要設置

⑺ Lucene 或者 solr 有什麼不一樣分別何時使用

Lucene是一個開放源代碼的全文檢索引擎工具包，即它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構，提供了完整的查詢引擎和索引引擎，部分文本分析引擎（英文與德文兩種西方語言）。Lucene的目的是為軟體開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者是以此為基礎建立起完整的全文檢索引擎.
Solr是一個高性能，採用Java5開發，基於Lucene的全文搜索伺服器。同時對其進行了擴展，提供了比Lucene更為豐富的查詢語言，同時實現了可配置、可擴展並對查詢性能進行了優化，並且提供了一個完善的功能管理界面，是一款非常優秀的全文搜索引擎。它對外提供類似於Web-service的API介面。用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML文件，生成索引；也可以通過Http G Solr et操作提出查找請求，並得到XML格式的返回結果；
Solr和Lucene的本質區別有以下三點：搜索伺服器，企業級和管理。Lucene本質上是搜索庫，不是獨立的應用程序，而Solr是。Lucene專注於搜索底層的建設，而Solr專注於企業應用。Lucene不負責支撐搜索服務所必須的管理，而Solr負責。所以說，一句話概括Solr: Solr是Lucene面向企業搜索應用的擴展

⑻ 為什麼使用solr-solr與Lucene比較及solr 的結構分析

為什麼使用solr-solr與Lucene比較及solr 的結構分析
solr可以對多個core進行綜合管理，並接受請求選擇特定的一個或者多個core執行相關任務。下面來回答什麼是solr的core。
core從文件結構的角度來看的話，主要包括一份索引（也可能還包括拼寫檢查的索引）、一堆配置文件。最主要的配置文件是：solrconfig.xml和schema.xml。solrconfig.xml從整體上對core進行了配置，例如索引的存放路徑、欄位的最大長度（maxFiedlLength）、寫鎖的超時時間（writeLockTimeout）、鎖類型（lockType）、是否壓縮索引（useCompoundFile）、內存索引緩沖區大小（ramBufferSizeMB）、合並因子（mergeFactor）、刪除策略、自動提交策略、緩存設置等，它好比是一份組裝機器人的說明書，裡面詳細描述了各個部件（handler）的參數。

⑼ jsp與solr結合實現網站搜索，怎麼弄

Solr是使用Ant進行管理的源碼, Ant是一種基於Java的build工具。理論上來說，它有些類似於Maven 或者是 C中的make。下載後解壓出來後，進行環境變數設置。
ANT_HOME：E:\Work\apache-ant\1.9.1 (這里為你自己解壓縮的目錄) PATH：%ANT_HOME%\bin （這個設置是為了方便在dos環境下操作）
查看是否安裝成功，在命令行窗口中輸入命令ant，若出現結果:

說明ant安裝成功！因為ant默認運行build.xml文件，這個文件需要我們建立。現在就可以進行build Solr源碼了。在命令行窗口中進入到你的Solr源碼目錄，輸入ant會出現當前build.xml使用提示信息。

其它的先不用管它，我們只要針對我們使用的IDE進行build就行了，如果使用eclipse就在命令行輸入：ant eclipse.如果使用IntelliJ IDEA 就在命令行輸入：ant idea。這樣就能進行build了。
黑窗口裡提示這個。。。

失敗。。。為什麼呢，最後我發現是因為下載的ant中少了一個jar就是這apache-ivy（下載地址：http://ant.apache.org/ivy/）這東東名子真怪 ivy是ant管理jar依賴關系的。當第一次bulid時ivy會自動把build中的缺少的依賴進行下載。網速慢的第一次build要好久的。。。
下載一個jar就行把jar放到ant的lib下（E:\Work\apache-ant\1.9.1\lib）這樣再次運行ant 就會成功了。到現在才可以進行Solr的代碼調試。
4.4配置並運行Solr代碼
不管用什麼IDE首選都要設置Solr Home在IDE的JVM參數設置VM arguments寫入 -Dsolr.solr.home=solr/example/solr一般就行了.不行也可以使用絕對路徑.
solr使用StartSolrJetty文件作為入口文件進行調試代碼,在這里可以設置伺服器使用的埠和solr的webapps目錄.一般都不用設置,默認的就可以進行調試.Solr Home也能可在代碼中設置一樣好用. System.setProperty("solr.solr.home", "E:\\Work\\solr-4.2.0-src-idea\\solr\\example\\solr");
目前是使用自帶的一個example作為solr配置的根目錄，如果你有其他的solr配置目錄，設置之即可。點擊run即可，debug也是一樣可以用了。沒有別的問題就應該能運行了.注意servlet 容器使用的埠,如查提示:
FAILED [email protected]:8983: java.net.BindException: Address already in use: JVM_Bind 就說明當前埠佔用中.改一下就可以了.如果沒有報錯啟動成功後就可以在瀏覽器中輸入地址: http://localhost:8983/solr/ 就可以看到如下界面

到這里Solr就成功配置並運行了.要是想跟代碼調試在啟動時在這個方法里點斷點就可以Initializer的initialize()方法如果想從瀏覽器中找斷點調試就要到SolrDispatchFilter的doFilter方法中點斷點了.
註：IE9在兼容模式下有bug，必須設置為非兼容模式。
5.Solr基礎
因為 Solr 包裝並擴展了Lucene，所以它們使用很多相同的術語。更重要的是，Solr 創建的索引與 Lucene 搜索引擎庫完全兼容。通過對 Solr 進行適當的配置，某些情況下可能需要進行編碼，Solr 可以閱讀和使用構建到其他 Lucene 應用程序中的索引。在 Solr 和 Lucene 中，使用一個或多個 Document 來構建索引。Document 包括一個或多個 Field。Field 包括名稱、內容以及告訴 Solr 如何處理內容的元數據。