第一天： 學習電商行業的背景，電商模式：B2B、B2C、B2B2C、O2O。 分散式，叢集的理解，系統的架構，基於SSO的架構。 使用Maven搭建後臺工程，及SVN的使用。
第二天： dubbo的學習和使用，系統和系統之間通訊的中介軟體。 webservice ：系統之間通訊。應用於外部系統，並且資料交換不是特別大的情況下（傳統行業OA與ERP之間的通訊）。 http+json：系統之間通訊。屬於http的協議，RestFul風格傳遞資料（手機客戶端和後臺進行通訊，SSO系統給手機發布介面呼叫，傳遞JSON）。 dubbo：系統之間的通訊。屬於RPC的協議（底層二進位制協議），使用socket通訊，傳輸效率高，一般用於內部系統之間。作為SOA架構的管理工具，能統計各個服務呼叫的次數。
SSM的整合，逆向工程，商品列表展示，分頁外掛的使用，Easyui的使用（datagrid的使用查詢商品列表）。 學習dubbo的架構及4個角色，如何在spring使用。dubbo的使用貫穿於整合專案，有服務層和表現層的互動就需要使用dubbo。
第三天： 商品類目的選擇，使用EasyUI的tree控制元件。傳統圖片上傳功能，上傳到某一個tomcat，在叢集環境下，上傳之後，有可能由另一臺伺服器提供服務，圖片不存在，所以需要單獨建立圖片伺服器FastDFS（tracker、storage）。 在叢集環境下使用FastDFS來儲存圖片（會使用FASTDFS客戶端上傳下載圖片即可）。還有富文字編輯器KindEditor的使用（純js實現的）。 富文字編輯器：引入JS、定義好資料來源（textarea）、表單提交之前、同步資料、將富文字編輯器中的內容同步到textarea中。
第四天： 商城首頁系統（portal）的搭建 ，使用偽靜態URL攔截形式:*.html。（SEO：搜尋引擎優化） 首頁的資料應當動態展示，需要有一個CMS系統來動態維護（CMS：內容管理系統），就是內容和內容分類管理。輪播圖的動態展示。 首頁訪問壓力很大，需要做快取redis。
第五天： 在首頁中的訪問壓力特別大，需要解決高併發的問題，使用快取技術，學習了redis技術，並使用redis的java客戶端Jedis在內容獲取時的服務層中新增快取及快取同步。 redis：就是一種以KEY-VALUE形式儲存資料在記憶體中的技術（主要用於快取）。
set get expire incr keys * redis五種儲存資料型別：string hash list set sortedset sortedset 用於做排行榜，有序，並且不重複。 redis的持久化方案：RDB、AOF。 RDB：快照。 AOF：(append only file) redis中的每一個操作都記錄起來。一旦重啟，就可以將原來資料恢復。 需要手動開啟AOF持久化方案，預設是開啟RDB。
redis伺服器的搭建及叢集搭建（奇數結點）因為：redis叢集中有投票機制，半數以上投票。 注意：新增快取的邏輯不能影響正常的業務邏輯。應用最多的資料型別是string和hash。
第六、七天： lucene是一個全文檢索的工具包，提供很多的檢索使用的API。 在首頁中如果找不到對應的商品，就需要搜尋商品，實現搜尋的技術是lucene/solr。 學習了lucene相關的介紹，應用場景，以及實現全文檢索的流程。
索引流程及搜尋流程。 學習入門程式：索引流程的程式碼實現。luke的使用。 學習入門程式：搜尋流程的程式碼實現。 索引域及文件的域，以及Field域的說明（是否分詞、是否索引、是否儲存）
索引的維護： 搜尋的兩種型別（使用query子類及queryParser）及lucene搜尋相關的語法。 最簡單的語法：field:value從field查詢包含value的值的資料。
分詞的過程： 分詞（英文單詞，按空格分詞） --> 過濾（標點符號去掉） --> 大寫轉小寫 --> 去掉停用詞。
中文分詞器的IKAnalyzer的使用： 1、jar包新增到工程build path 2、配置檔案（xx.cfg.xml、擴充套件詞典、停用詞詞典）放入classes下 3、定義業務域 特點：可以擴充套件、可以維護、支援中文分詞。
第八天： solr 是(基於lucene)搜尋引擎，可以獨立部署，來實現搜尋功能，高亮顯示，效能優化，可以解決高併發的搜尋需求。 lucene和solr的區別： 1、lucene是工具包，solr是伺服器（打比方：lucene是汽車引擎，solr是汽車） 2、lucene的業務域不需要先定義後使用，solr必須是先定義後使用。 3、lucene加入應用系統的時候，耦合度很高不易擴充套件。 4、solr是伺服器，只需要通過http請求操作索引。維護、升級方便，並且能做效能優化。 使用solrj作為java的客戶端操作索引和搜尋。 京東案例的實現。使用IK分詞器，配置在schema.xml中。
第九天： taotao商城的solr服務在linux的搭建，搜尋服務層系統的搭建，表現層搭建，並使用solr實現商品搜尋功能（中文分析器的配置、業務域定義、入資料到索引庫、索功能的實現）。 solr分頁：通過solrj設定start，設定rows，預設查詢是10條。 查詢的時候需要指定預設的搜尋域。
第十天： 在併發量特別大的情況下，一個solr伺服器無法滿足要求，學習了solr叢集在linux下的搭建，參考教案。 測試了solrj的叢集版的使用，將搜尋功能切換到叢集版。 全域性異常處理：需要建立一個類實現全域性異常處理器的介面（handlerexceptionresolver），配置在配置檔案springmvc。xml中。 全域性異常處理中實現： 1、日誌處理 2、傳送異常資訊郵件給相關人員 3、響應一個友好的錯誤頁面給客戶
第十一天： 索引庫需要同步時，可以使用非同步訊息的中介軟體(activemq)來實現索引庫的同步。
Activemq的使用場景： 不需要同步等待時的系統之間的通訊使用。比如：訂單系統。
產生訂單後，需要傳送響應給客戶，提示成功。但不需要等待使用者點選確定後才繼續產生訂單。訂單系統只需要產生訂單後，非同步傳送一個訊息，又繼續執行下一個產生訂單邏輯而不需要再等待頁面響應。 同步索引庫。 同步快取。 生成靜態頁面。
傳遞訊息的型別： PTP --> queue --> 預設快取在mq伺服器上，只能被一個消費者接收。 publish/subscribe --> topic預設是不快取，可以被多個消費者接收。（需要消費者先訂閱）
訊息的格式（JMS的規範）6種格式。TxtMessage、ObjectMessage、ByteMessage、…… 1、一般是和spring進行整合使用。 2、傳送端：JMSTemplate 傳送訊息。 3、接收端：使用設定一個監聽容器 --> 指定監聽器 (MessageListener)。
第十二天： 商品詳情的系統搭建 （參考京東，訪問商品詳情時，域名已經變化）。 使用jsp和redis實現頁面的高效能動態展示。 如果高併發量：需要實現網頁靜態化來提升響應速度。
freemarker可實現網頁靜態化，使用freemarker的常用語法學習。實現網頁靜態化的方案實現。通過使用activemq實現同步生成靜態網頁。 實現網頁靜態化的方案： 部署不同的伺服器上的（taoao-item-web）工程，分別訂閱了topic（當商品新增/更新的時候傳送的topic包含商品id），工程接收到訊息，產生靜態頁面。 工程所在的伺服器上再部署一個http伺服器，來指定靜態頁面的目錄，提供瀏覽器訪問靜態頁面，提升效率。
第十三天： 在實現靜態化的方案中需要使用nginx，需要學習nginx。nginx能實現的功能： 1、配置虛擬主機，複製server結點即可。 2、反向代理，設定upstream節點來指定服務的ip地址和埠，在location結點設定proxy_pass=http://upstream; 參考教案。 3、負載均衡。 4、作為Http伺服器。 學習實現nginx的高可用的原理。
第十四天： SSO系統：主要解決分散式環境下session共享的問題。 SSO系統的搭建，註冊，登入，通過token（相當於jsessionid）獲取使用者資訊。實現SSO服務，提供給其他客戶端（如手機介面）介面。 登入流程：使用者填入使用者名稱和密碼，如果正確，key是一個uuid生成的唯一值（token）。使用者資訊儲存到redis中，設定此key的有效期模擬session（30分鐘），設定到cookie中（跨域：訪問的埠不同，域名不同）。 使用JSONP的技術：登入之後，在首頁需要顯示使用者資訊。使用JSONP來實現ajax跨域。
第十五天： SSO系統的介面的開發完成及購物車實現以及訂單確認頁面實現。 購物車使用cookie來存放。有缺點：更換裝置不能同步資料，儲存的容量有限，如果cookie一旦被禁用，無法使用。 解決方案： 在使用者未登入的情況下，繼續使用cookie來存放購物車，展示列表以cookie為準。 一旦使用者登入，將cookie的資料同步到資料庫redis中，並刪除cookie的內容，展示購物車列表就以redis中的資料為準，後續的新增到購物車也需要新增到redis中。 進入訂單確認頁面，需要認證身份，通過攔截器來實現。
第十六天： 訂單提交的功能實現。專案的部署，mysql的linux的安裝，系統的網路拓撲圖，伺服器的域名規劃，伺服器的數量規劃及部署。使用tomcat的熱部署，反向代理的配置。
回到頂部 專案中的問題 PS：以下描述若與就業老師所說有衝突，請以就業老師為準，另外參考簡歷一定要改，切不可拿來主義
1、淘淘商城簡歷中的描述 參考簡歷。 注意：在真實的開發專案中，開發工程師不可能開發所有的模組，只會負責某幾個模組，大家所要描述的是：你所負責的模組（一般3到4個模組）。
2、淘淘網站的併發量 大概：說5000左右也行。（此處要問怎麼來的，可以說經過壓力測試出來的，自己沒做過，但是知道。有些情況下，並不是所有的事情都是由你來做，由面試官決定用不用你，你把所知道的說清楚就行）可以滿足目前的業務需求。由於我們的系統是分散式架構，支援水平擴充套件，如果將來併發量提高的話，可以增加伺服器來提高併發量。
3、淘淘商城人員的配置 產品經理：3人，確定需求及給出產品原型圖。 專案經理：1人，專案管理。 前端團隊：5人，根據產品經理給出原型製作出靜態頁面（當然也包括UI）。 後端團端：20人，實現產品的功能（你們就屬於後端團隊）。 測試團隊：5人，負責測試產品的所有的功能。
4、開發週期 現在開發採用敏捷開發，快速迭代，開發週期大概6-8個月，後期一般採用迭代的方式開發，一般迭代的週期為一個月左右。（迭代就是所謂的一個小版本的開發）
5、SKU 表示唯一確定唯一的商品的單位（最小庫存單位）SKU==商品ID 例如：對於京東的一款商品：一種顏色，一種配置，一種配送方式，就唯一確定一個商品，這種就叫做一個SKU。 類似於下圖：
6、你說你用了redis，你們redis存的是什麼格式的資料，都是怎麼存的？ redis中存放資料都是key-value的形式。 我們商城使用string型別來存放的。拿商品來說：商品的id就是key，商品相關的商品資訊組成一個JSON存放。
7、你前臺系統portal採用4伺服器做叢集部署，前臺系統的併發量提升上去，那對於資料庫會不會造成一個瓶頸，這一塊你們是怎麼處理的？ portal在高併發的情況下，可以通過部署叢集來提高併發量，這種時候，如果每次都訪問資料，確實會對資料庫造成很大的壓力，那麼這時候，我們就採用在服務層增加快取，使用redis實現，這樣客戶端請求到達時，先從快取中讀取，如果存在資料則直接返回，而不會再從資料庫查詢，如果快取中沒有，則從資料庫查詢，這樣就可減少資料庫的訪問，達到提升資料的訪問瓶頸。
8、購物車存在cookie中，可以實現不登入就可以使用購物車，如果我沒有登入，購買了商品，現在更換了裝置（電腦），那還能不能看到我買的商品？如果看不到怎麼做cookie同步？ 不能；現階段，淘淘商城是採用cookie的方式存放購物車，以減少服務端的儲存壓力。但是弊端就是當更換裝置後將看不到已新增的商品，也就是不能同步商品資訊。 打算下一步這麼實現：當使用者沒有登入時，商品的資料放入購物車中，將存放於cookie中，此時如果使用者登入，將cookie中的資料存放在redis中，並且是和使用者的ID關聯，並將cookie中的資料刪除。此時如果使用者更換裝置，只要使用同一帳號登入，就可以看到購物車中的商品資訊，就達到了同步cookie的目的。
9、你們商城是通過什麼來做搜尋的？ 因為系統要使用站內搜尋功能，資料量很大，需要使用solr。 solr是(基於lucene)搜尋引擎，可以獨立部署，來實現搜尋功能、高亮顯示、效能優化，可以解決高併發的搜尋需求。 例如：我們系統就是用solr做商品搜尋。--> 怎麼做的呢？ solr是一個伺服器，需要搭建，需要先定義好Field和FieldType，定義中文分詞器，再使用。 通過solr的Java客戶端solrj連線solr服務，它提供豐富的操作索引的方法，可以通過這個客戶端來實現搜尋功能。 你們索引庫一般有多少資料？答：幾百萬 如果資料量特別大？怎麼辦？答：做叢集。 索引庫是如何同步？答：activemq非同步訊息佇列。
10、solr和lucene他們之間有什麼區別？ lucene是一個工具包，類似於一個類庫。 solr是一個基於solr的搜尋引擎，可以獨立執行和部署，它可以通過http請求來索引和搜尋。 打個比方：solr就相當於一輛汽車，而lucene只是汽車中的引擎，你可以開車，但不開引擎。 另外，使用solr可以獨立部署，擴充套件容易，所以可以最大程度的解耦，而lucene使用需要在業務邏輯中新增程式碼，邏輯耦合度很高，不易維護。
11、你們使用activemq應用在哪種業務場景中，既然都是系統通訊，和其他的系統通訊有什麼區別？ 我們使用activemq應用在生成商品詳情，同步索引庫。activemq是一個訊息中介軟體，非同步傳送訊息，而其他通訊技術：比如dubbo，是同步等待。 比如：使用activemq在商品服務模組，新增商品並不需要等待索引庫同步完成後才能繼續新增下一個商品，只需要非同步傳送一個訊息告訴索引服務 ，索引服務通過商品ID查詢商品更新索引。 再有：面試中，要淡定，如果有面試官問：資料庫設計這樣做正確嗎？ 你不清楚的情況下，你就說我們公司就是這麼解決的。其他的我不知道。 有些面試官，可能他也不知道，他也想知道。
12、電商活動倒數計時方案 1、確定一個基準時間。可以使用一個sql語句從資料庫中取出一個當前時間。SELECT NOW() 2、活動開始的時間是固定的。 3、使用活動開始時間減去基準時間可以計算出一個秒為單位的數值。 4、在redis中設定一個key（活動開始標識）。設定key的過期時間為第三步計算出來的時間。 5、展示頁面的時候取出key的有效時間。ttl命令。使用js倒數計時。 6、一旦活動開始的key失效，說明活動開始。 7、需要在活動的邏輯中，先判斷活動是否開始。
13、你們的商城的秒殺方案是什麼？ 1、將商品的數量放入redis中。 2、秒殺時，可以使用decr命令將商品的數量減一。如果不是負數說明搶到。 3、如果返回的是負數，說明商品已經搶完。
14、dubbo服務使用流程，執行流程？zookeeper註冊中心的作用？ 使用流程： 第一步：要在系統中使用dubbo應該先搭建一個註冊中心，一般推薦使用zookeeper。 第二步：有了註冊中心然後是釋出服務，釋出服務需要使用spring容器和dubbo標籤來發布服務。並且釋出服務時需要指定註冊中心的位置。 第三步：服務釋出之後就是呼叫服務。一般呼叫服務也是使用spring容器和dubbo標籤來引用服務，這樣就可以在客戶端的容器中生成一個服務的代理物件，在action或者Controller中直接呼叫service的方法即可。 Zookeeper註冊中心的作用：主要就是註冊和發現服務的作用。類似於房產中介的作用，在系統中並不參與服務的呼叫及資料的傳輸。
15、redis為什麼可以做快取？專案中使用redis的目的是什麼？redis什麼時候使用？ 1、Redis是key-value形式的nosql資料庫。可以快速的定位到所查詢的key，並把其中的value取出來。並且redis的所有的資料都是放到記憶體中，存取的速度非常快，一般都是用來做快取使用。 2、專案中使用redis一般都是作為快取來使用的，快取的目的就是為了減輕資料庫的壓力提高存取的效率。 3、在網際網路專案中只要是涉及高併發或者是存在大量讀資料的情況下都可以使用redis作為快取。當然redis提供豐富的資料型別，除了快取還可以根據實際的業務場景來決定redis的作用。例如使用redis儲存使用者的購物車資訊、生成訂單號、訪問量計數器、任務佇列、排行榜等。
16、AcitveMQ的作用、原理？（生產者。消費者。 p2p、訂閱實現流程） Activemq的作用就是系統之間進行通訊。當然可以使用其他方式進行系統間通訊，如果使用Activemq的話可以對系統之間的呼叫進行解耦，實現系統間的非同步通訊。原理就是生產者生產訊息，把訊息傳送給activemq。Activemq接收到訊息，然後檢視有多少個消費者，然後把訊息轉發給消費者，此過程中生產者無需參與。消費者接收到訊息後做相應的處理和生產者沒有任何關係。
17、ActiveMQ在專案中如何應用的？ Activemq在專案中主要是完成系統之間通訊，並且將系統之間的呼叫進行解耦。例如在新增、修改商品資訊後，需要將商品資訊同步到索引庫、同步快取中的資料以及生成靜態頁面一系列操作。在此場景下就可以使用activemq。一旦後臺對商品資訊進行修改後，就向activemq傳送一條訊息，然後通過activemq將訊息傳送給訊息的消費端，消費端接收到訊息可以進行相應的業務處理。
18、ActiveMQ如果資料提交不成功怎麼辦？ Activemq有兩種通訊方式，點到點模式和釋出訂閱模式。 如果是點到點模式的話，如果訊息傳送不成功此訊息預設會儲存到activemq服務端直到有消費者將其消費，所以此時訊息是不會丟失的。 如果是釋出訂閱模式的通訊方式，預設情況下只通知一次，如果接收不到此訊息就沒有了。這種場景只適用於對訊息送達率要求不高的情況。如果要求訊息必須送達不可以丟失的話，需要配置持久訂閱。每個訂閱端定義一個id，在訂閱時向activemq註冊。釋出訊息和接收訊息時需要配置傳送模式為持久化。此時如果客戶端接收不到訊息，訊息會持久化到服務端，直到客戶端正常接收後為止。
19、當被問到某個模快存在安全性問題（sso單點登入系統）時，如何回答？ 目前商城的sso系統的解決方案中直接把token儲存到cookie中，確實存在安全性問題。但是實現簡單方便。如果想提高安全性可以使用CAS框架實現單點登入。參考連結：
20、當技術面試官問到你某個技術點更深層次研究時，自己沒有深入瞭解怎麼回答？ 如果沒有深入研究就直接回答不知道就可以了。
21、如何把熱點商品或者是推廣商品的排名提高？ 可以設定文件中域的boost值，boost值越高計算出來的相關度得分就越高，排名也就越靠前。
22、solr的原理 Solr是基於Lucene開發的全文檢索伺服器，而Lucene就是一套實現了全文檢索的api，其本質就是一個全文檢索的過程。全文檢索就是把原始文件根據一定的規則拆分成若干個關鍵詞，然後根據關鍵詞建立索引，當查詢時先查詢索引找到對應的關鍵詞，並根據關鍵詞找到對應的文件，也就是查詢結果，最終把查詢結果展示給使用者的過程。
23、solr裡面IK分詞器的原理 IK分析器的分詞原理本質上是詞典分詞。現在記憶體中初始化一個詞典，然後在分詞過程中逐個讀取字元，和字典中的字元相匹配，把文件中的所有的詞語拆分出來的過程。
21、支付介面是怎麼做的？ 面試中可以說支付這部分不是我們做的，我們專案中並沒有涉及支付部分的處理。如果想了解支付是如何實現可以參考之前學過的易寶支付相關處理以及支付寶、微信支付相關文件。
24、業務如何說？先說業務、說表、說具體實現？ 先說總體的業務流程，然後再說具體業務的實現方法及使用的技術。最後說你在系統中負責的內容。不需要說表結構。
25、單點登入系統，如果cookie禁用，你們怎麼解決？ 如果禁用cookie可以使用url中帶引數，把token傳遞給服務端。當然此方法涉及安全性問題，其實在cookie中儲存token同樣存在安全性問題。推薦使用SSO框架CAS實現單點登入。
26、你們做移動端沒有，如果沒有移動端，你們為什麼做單點登入？ 單點登入並不是為移動端準備的，移動端有自己的登入方式。單點登入是解決在同一個公司內部多個互信網站之間進行跳轉時不需要多次登入，多個系統統一登入入口。
27、單點登入的核心是什麼？ 單點登入的核心是如何在多個系統之間共享身份資訊（即共享session）。
28、除了單點登陸，還做過什麼登陸的方式？ 除了單點登入那就是普通登入方式，使用者在同一個公司的多個系統之間跳轉時需要多次登入。
29、單點登入，http無狀態的，別人模仿如何在後端處理？ http是無狀態的，如果別人模仿瀏覽器傳送http請求，一般後臺是無法識別的。如果對安全要求高的情況下應該是https協議。可以保證在通訊過程中無法竊取通訊內容。
30、安全性問題（別的網站使用爬蟲技術爬你的網站怎麼辦？有沒有安全措施） 單位時間內請求次數超過某個閾值就讓輸入驗證碼，可以極大降低抓取的速度，如果多次超過某個閥值可以加入黑名單。還有就是頁面內容使用json返回，資料經常變一變格式，或者js動態生成頁面內容。
31、商品存入資料庫怎麼保證資料庫資料安全？ 1、對使用者安全管理 使用者運算元據庫時，必須通過資料庫訪問的身份認證。刪除資料庫中的預設使用者，使用自定義的使用者及高強度密碼。 2、定義檢視 為不同的使用者定義不同的檢視，可以限制使用者的訪問範圍。通過檢視機制把需要保密的資料對無權存取這些資料的使用者隱藏起來，可以對資料庫提供一定程度的安全保護。實際應用中常將檢視機制與授權機制結合起來使用，首先用檢視機制遮蔽一部分保密資料，然後在檢視上進一步進行授權。 3、資料加密 資料加密是保護資料在儲存和傳遞過程中不被竊取或修改的有效手段。 4、資料庫定期備份 5、審計追蹤機制 審計追蹤機制是指系統設定相應的日誌記錄，特別是對資料更新、刪除、修改的記錄，以便日後查證。日誌記錄的內容可以包括操作人員的名稱、使用的密碼、使用者的IP地址、登入時間、操作內容等。若發現系統的資料遭到破壞，可以根據日誌記錄追究責任，或者從日誌記錄中判斷密碼是否被盜，以便修改密碼，重新分配許可權，確保系統的安全。
32、訂單表的資料量太大，我把訂單分到許多表中，那麼我我想用一條sql查處所有的訂單，怎麼解決？ 分庫情況下：可以使用mycat資料庫中介軟體實現多個表的統一管理。雖然物理上是把一個表中的資料儲存到多個資料庫中，但是邏輯上還是一個表，使用一條sql語句就可以把資料全部查詢出來。 單庫情況下：需要動態生成sql語句。先查詢訂單相關的表，然後將查詢多個表的sql語句使用union連線即可。
33、我們們單點登入模組中，別人偽造我們cookie中的token怎麼辦？ 服務端是無法阻止客戶端偽造cookie的，如果對安全性要求高的話可以可使用CAS框架。
34、第一個是當兩個客戶同時買一件商品時庫存只有一個了，怎麼控制？ 可以使用mysql的行鎖機制，實現樂觀鎖，在更新商品之前將商品鎖定，其他使用者無法讀取，當此使用者操作完畢後釋放鎖。當併發量高的情況下，需要使用快取工具例如redis來管理庫存。
35、對資料庫只是採用了讀寫分離，並沒有完全解決資料庫的壓力，那麼有什麼辦法解決？ 如果資料庫壓力確實很大的情況下可以考慮資料庫分片，就是將資料庫中表拆分到不同的資料庫中儲存。可以使用mycat中介軟體。
36、同一賬號以客戶端登入怎麼擠掉另一端。 使用者登入後需要在session中儲存使用者的id。當使用者登入時，從當前所有的session中判斷是否有此使用者id的存在，如果存在的話就把儲存此使用者id的session銷燬。
37、solr的索引查詢為什麼比資料庫要快？ Solr使用的是Lucene API實現的全文檢索。全文檢索本質上是查詢的索引。而資料庫中並不是所有的欄位都建立的索引，更何況如果使用like查詢時很大的可能是不使用索引，所以使用solr查詢時要比查資料庫快。
38、solr索引庫個別資料索引丟失怎麼辦？ 首先Solr是不會丟失個別資料的。如果索引庫中缺少資料，那就向索引庫中新增。
39、Lucene索引優化 直接使用Lucene實現全文檢索已經是過時的方案，推薦使用solr。Solr已經提供了完整的全文檢索解決方案。