什麼是負載均衡高可用
nginx做爲負載均衡器，全部請求都到了nginx，可見nginx處於很是重點的位置，若是nginx服務器宕機後端web服務將沒法提供服務，影響嚴重。
爲了屏蔽負載均衡服務器的宕機，須要創建一個備份機。主服務器和備份機上都運行高可用（High Availability）監控程序，經過傳送諸如「I am alive」這樣的信息來監控對方的運行情況。當備份機不能在必定的時間內收到這樣的信息時，它就接管主服務器的服務IP並繼續提供負載均衡服務；當備份管理器又從主管理器收到「I am alive」這樣的信息時，它就釋放服務IP地址，這樣的主服務器就開始再次提供負載均衡服務。前端
什麼是FastDFS
FastDFS是用c語言編寫的一款開源的分佈式文件系統。FastDFS爲互聯網量身定製，充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標，使用FastDFS很容易搭建一套高性能的文件服務器集羣提供文件上傳、下載等服務。node
（搜索）mysql
solr怎麼設置搜索結果排名靠前（得分）？
能夠設置文檔中域的boost值，boost值越高計算出來的相關度得分就越高，排名也就越靠前。此方法能夠把熱點商品或者是推廣商品的排名提升。 nginx
elsticsearchweb
一、elasticsearch瞭解多少，說說大家公司es的集羣架構，索引數據大小，分片有多少，以及一些調優手段 。
解答：
如實結合本身的實踐場景回答便可。
好比：ES集羣架構13個節點，索引根據通道不一樣共20+索引，根據日期，每日遞增20+，索引：10分片，每日遞增1億+數據，
每一個通道天天索引大小控制：150GB以內。
僅索引層面調優手段：
1.一、設計階段調優面試
1）根據業務增量需求，採起基於日期模板建立索引，經過roll over API滾動索引；
2）使用別名進行索引管理；
3）天天凌晨定時對索引作force_merge操做，以釋放空間；
4）採起冷熱分離機制，熱數據存儲到SSD，提升檢索效率；冷數據按期進行shrink操做，以縮減存儲；
5）採起curator進行索引的生命週期管理；
6）僅針對須要分詞的字段，合理的設置分詞器；
7）Mapping階段充分結合各個字段的屬性，是否須要檢索、是否須要存儲等。 …redis
1.二、寫入調優spring
1）寫入前副本數設置爲0；
2）寫入前關閉refresh_interval設置爲-1，禁用刷新機制；
3）寫入過程當中：採起bulk批量寫入；
4）寫入後恢復副本數和刷新間隔；
5）儘可能使用自動生成的id。sql
1.三、查詢調優數據庫
1）禁用wildcard；
2）禁用批量terms（成百上千的場景）；
3）充分利用倒排索引機制，能keyword類型儘可能keyword；
4）數據量大時候，能夠先基於時間敲定索引再檢索；
5）設置合理的路由機制。
二、elasticsearch的倒排索引是什麼？
面試官：想了解你對基礎概念的認知。
解答：通俗解釋一下就能夠。
傳統的咱們的檢索是經過文章，逐個遍歷找到對應關鍵詞的位置。
而倒排索引，是經過分詞策略，造成了詞和文章的映射關係表，這種詞典+映射表即爲倒排索引。
有了倒排索引，就能實現o（1）時間複雜度的效率檢索文章了，極大的提升了檢索效率。
學術的解答方式：
倒排索引，相反於一篇文章包含了哪些詞，它從詞出發，記載了這個詞在哪些文檔中出現過，由兩部分組成——詞典和倒排表。
加分項：倒排索引的底層實現是基於：FST（Finite State Transducer）數據結構。
lucene從4+版本後開始大量使用的數據結構是FST。FST有兩個優勢：
1）空間佔用小。經過對詞典中單詞前綴和後綴的重複利用，壓縮了存儲空間；
2）查詢速度快。O(len(str))的查詢時間複雜度。
三、elasticsearch 索引數據多了怎麼辦，如何調優，部署？
面試官：想了解大數據量的運維能力。
解答：索引數據的規劃，應在前期作好規劃，正所謂「設計先行，編碼在後」，這樣纔能有效的避免突如其來的數據激增致使集羣處理能力不足引起的線上客戶檢索或者其餘業務受到影響。
如何調優，正如問題1所說，這裏細化一下：
四、elasticsearch是如何實現master選舉的？
解答：
前置前提：
1）只有候選主節點（master：true）的節點才能成爲主節點。
2）最小主節點數（min_master_nodes）的目的是防止腦裂。
這個我看了各類網上分析的版本和源碼分析的書籍，雲裏霧裏。
覈對了一下代碼，核心入口爲findMaster，選擇主節點成功返回對應Master，不然返回null。選舉流程大體描述以下：
第一步：確認候選主節點數達標，elasticsearch.yml設置的值discovery.zen.minimum_master_nodes；
第二步：比較：先斷定是否具有master資格，具有候選主節點資格的優先返回；若兩節點都爲候選主節點，則id小的值會主節點。注意這裏的id爲string類型。
五、詳細描述一下Elasticsearch搜索的過程？
面試官：想了解ES搜索的底層原理，再也不只關注業務層面了。
解答：
搜索拆解爲「query then fetch」 兩個階段。
query階段的目的：定位到位置，但不取。
步驟拆解以下：
1）假設一個索引數據有5主+1副本 共10分片，一次請求會命中（主或者副本分片中）的一個。
2）每一個分片在本地進行查詢，結果返回到本地有序的優先隊列中。
3）第2）步驟的結果發送到協調節點，協調節點產生一個全局的排序列表。
fetch階段的目的：取數據。
路由節點獲取全部文檔，返回給客戶端。
六、Elasticsearch在部署時，對Linux的設置有哪些優化方法？
面試官：想了解對ES集羣的運維能力。
解答：
1）關閉緩存swap;
2）堆內存設置爲：Min（節點內存/2, 32GB）;
3)設置最大文件句柄數；
4）線程池+隊列大小根據業務須要作調整；
5）磁盤存儲raid方式——存儲有條件使用RAID10，增長單節點性能以及避免單節點存儲故障。
七、lucence內部結構是什麼？
解答：
Lucene是有索引和搜索的兩個過程，包含索引建立，索引，搜索三個要點。能夠基於這個脈絡展開一些。
什麼是sso系統
單點登陸是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。
登陸的處理流程：
一、登陸頁面提交用戶名密碼。
二、登陸成功後生成token。Token至關於原來的jsessionid，字符串，可使用uuid。
三、把用戶信息保存到redis。Key就是token，value就是TbUser對象轉換成json。
四、使用String類型保存Session信息。可使用「前綴:token」爲key
五、設置key的過時時間。模擬Session的過時時間。通常半個小時。
六、把token寫入cookie中。
如何判斷是否登陸
1.從cookie中取token
2.取不到未登陸
3.取到token，到redis中查詢token是否過時
4.若是過時，爲登陸狀態
5.沒有過時，登陸狀態
實現購車商品數據同步
一、要求用戶登陸。
二、把購物車商品列表保存到數據庫中。推薦使用redis。
三、Key：用戶id，value：購車商品列表。推薦使用hash，hash的field：商品id，value：商品信息。
四、在用戶未登陸狀況下寫cookie。當用戶登陸後，訪問購物車列表時，
a)把cookie中的數據同步到redis。
b)把cookie中的數據刪除
c)展現購物車列表時以redis爲準。
d)若是redis中有數據cookie中也有數據，須要作數據合併。相同商品數量相加，不一樣商品添加一個新商品。
五、若是用戶登陸狀態，展現購物車列表以redis爲準。若是未登陸，以cookie爲準。
瀏覽器跨域問題
跨域是指從一個域名的網頁去請求另外一個域名的資源。瀏覽器出於安全的考慮，不容許不一樣源的請求
JSONP解決AJAX跨域問題：
JSONP是服務器與客戶端跨源通訊的經常使用方法。最大特色就是簡單適用，老式瀏覽器所有支持，服務器改造很是小。
它的基本思想是，網頁經過添加一個<script>元素，向服務器請求JSON數據，這種作法不受同源政策限制；服務器收到請求後，將數據放在一個指定名字的回調函數裏傳回來。
海量數據的存儲問題
現在隨着互聯網的發展，數據的量級也是呈指數的增加，從GB到TB到PB。對數據的各類操做也是越發的困難，傳統的關係性數據庫已經沒法知足快速查詢與插入數據的需求。這個時候NoSQL的出現暫時解決了這一危機。它經過下降數據的安全性，減小對事務的支持，減小對複雜查詢的支持，來獲取性能上的提高。
可是，在有些場合NoSQL一些折衷是沒法知足使用場景的，就好比有些使用場景是絕對要有事務與安全指標的。這個時候NoSQL確定是沒法知足的，因此仍是須要使用關係性數據庫。若是使用關係型數據庫解決海量存儲的問題呢？此時就須要作數據庫集羣，爲了提升查詢性能將一個數據庫的數據分散到不一樣的數據庫中存儲。
什麼是數據庫分片
簡單來講，就是指經過某種特定的條件，將咱們存放在同一個數據庫中的數據分散存放到多個數據庫上面，以達到分散單臺設備負載的效果。
數據的切分（Sharding）根據其切分規則的類型，能夠分爲兩種切分模式。
1.一種是按照不一樣的表來切分到不一樣的數據庫（主機）之上，這種切能夠稱之爲數據的垂直切分
2.另一種則是根據表中的數據的邏輯關係，將同一個表中的數據按照某種條件拆分到多臺數據庫上面，這種切分稱之爲數據的水平切分。
如何實現數據庫分片
當數據庫分片後，數據由一個數據庫分散到多個數據庫中。此時系統要查詢時須要切換不一樣的數據庫進行查詢，那麼系統如何知道要查詢的數據在哪一個數據庫中？當添加一條記錄時要向哪一個數據庫中插入呢？這些問題處理起來都是很是的麻煩。
這種狀況下可使用一個數據庫中間件mycat來解決相關的問題。
什麼是Mycat？
簡單的說，MyCAT就是：一個新穎的數據庫中間件產品，支持mysql集羣，提供高可用性數據分片集羣。你能夠像使用mysql同樣使用mycat。對於開發人員來講根本感受不到mycat的存在。
Mycat讀寫分離
數據庫讀寫分離對於大型系統或者訪問量很高的互聯網應用來講，是必不可少的一個重要功能。對於MySQL來講，標準的讀寫分離是主從模式，一個寫節點Master後面跟着多個讀節點，讀節點的數量取決於系統的壓力，一般是1-3個讀節點的配置
電商活動倒計時方案(秒殺方案）：
一、肯定一個基準時間。可使用一個sql語句從數據庫中取出一個當前時間。SELECT NOW()；
二、活動開始的時間是固定的。
三、使用活動開始時間-基準時間能夠計算出一個秒爲單位的數值。
四、在redis中設置一個key（活動開始標識）。設置key的過時時間爲第三步計算出來的時間。
五、展現頁面的時候取出key的有效時間。Ttl命令。使用js倒計時。
六、一旦活動開始的key失效，說明活動開始。
七、須要在活動的邏輯中，先判斷活動是否開始。
秒殺方案：
八、把商品的數量放到redis中。
九、秒殺時使用decr命令對商品數量減一。若是不是負數說明搶到。
十、一旦返回數值變爲0說明商品已售完。
因爲宜立方商城是基於SOA的架構，表現層和服務層是不一樣的工程。因此要實現商品列表查詢須要兩個系統之間進行通訊。
如何實現遠程通訊？
一、Webservice：效率不高基於soap協議。項目中不推薦使用。
二、使用restful形式的服務：http+json。不少項目中應用。若是服務太多，服務之間調用關係混亂，須要治療服務。
三、使用dubbo。使用rpc協議進行遠程調用，直接使用socket通訊。傳輸效率高，而且能夠統計出系統之間的調用關係、調用次數。
關於dubbo或者spring cloud
什麼是dubbo
DUBBO是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案
Dubbo就是資源調度和治理中心的管理工具。
dubbo服務開發流程，運行流程？zookeeper註冊中心的做用？
使用流程：
第一步：要在系統中使用dubbo應該先搭建一個註冊中心，通常推薦使用zookeeper。
第二步：有了註冊中心而後是發佈服務，發佈服務須要使用spring容器和dubbo標籤來發布服務。而且發佈服務時須要指定註冊中心的位置。
第三步：服務發佈以後就是調用服務。通常調用服務也是使用spring容器和dubbo標籤來引用服務，這樣就能夠在客戶端的容器中生成一個服務的代理對象，在action或者Controller中直接調用service的方法便可。
Zookeeper註冊中心的做用主要就是註冊和發現服務的做用。相似於房產中介的做用，在系統中並不參與服務的調用及數據的傳輸。
什麼是spring cloud(你怎麼理解的），有什麼好處，什麼壞處。對裏面具體組件的理解，跟dubbo比較
電商項目中是如何解決高併發和高可用的？
1.頁面靜態化
2.fastDFS圖片服務器
3.數據緩存服務器
4.數據庫集羣、庫表散列（數據庫的各類優化、數據庫的拆分）
5.負載均衡
什麼是負載均衡
當一臺服務器的單位時間內的訪問量越大時，服務器壓力就越大，大到超過自身承受能力時，服務器就會崩潰。爲了不服務器崩潰，讓用戶有更好的體驗，咱們經過負載均衡的方式來分擔服務器壓力。
咱們能夠創建不少不少服務器，組成一個服務器集羣，當用戶訪問網站時，先訪問一箇中間服務器，在讓這個中間服務器在服務器集羣中選擇一個壓力較小的服務器，而後將該訪問請求引入該服務器。如此以來，用戶的每次訪問，都會保證服務器集羣中的每一個服務器壓力趨於平衡，分擔了服務器壓力，避免了服務器崩潰的狀況。
負載均衡是用反向代理的原理實現的。
redis爲何能夠作緩存？項目中使用redis的目的是什麼？redis何時使用？
1）Redis是key-value形式的nosql數據庫。能夠快速的定位到所查找的key，並把其中的value取出來。而且redis的全部的數據都是放到內存中，存取的速度很是快，通常都是用來作緩存使用。
2）項目中使用redis通常都是做爲緩存來使用的，緩存的目的就是爲了減輕數據庫的壓力提升存取的效率。
3）在互聯網項目中只要是涉及高併發或者是存在大量讀數據的狀況下均可以使用redis做爲緩存。固然redis提供豐富的數據類型，除了緩存還能夠根據實際的業務場景來決定redis的做用。例如使用redis保存用戶的購物車信息、生成訂單號、訪問量計數器、任務隊列、排行榜等。
redis支持五種數據類型存儲：1.字符串2.散列3.列表4.集合5.有序集合（問深一點可能會問道底層數據結構，以及每種數據結構經常使用情景）這裏也能夠列舉一些：
應用場景
計數器
數據統計的需求很是廣泛，經過原子遞增保持計數。例如，點贊數、收藏數、分享數等。
排行榜
排行榜按照得分進行排序，例如，展現 近、 熱、點擊率 高、活躍度 高等等條件的top list。
用於存儲時間戳
相似排行榜，使用redis的zset用於存儲時間戳，時間會不斷變化。例如，按照用戶關注用戶的 新動態列表。記錄用戶斷定信息
記錄用戶斷定信息的需求也很是廣泛，能夠知道一個用戶是否進行了某個操做。例如，用戶是否點贊、用戶是否收藏、用戶是否分享等。
社交列表
社交屬性相關的列表信息，例如，用戶點贊列表、用戶收藏列表、用戶關注列表等。
緩存
緩存一些熱點數據，例如，PC版本文件更新內容、資訊標籤和分類信息、生日祝福壽星列表。
隊列
Redis能做爲一個很好的消息隊列來使用，經過list的lpop及lpush接口進行隊列的寫入和消費，自己性能較好能解決大部分問題。可是，不提倡使用，更加建議使用rabbitmq等服務，做爲消息中間件。
會話緩存 使用Redis進行會話緩存。例如，將web session存放在Redis中。
業務使用方式
String(字符串): 應用數, 資訊數等, (避免了select count(*) from ...)
Hash（哈希表）: 用戶粉絲列表, 用戶點贊列表, 用戶收藏列表, 用戶關注列表等。
List（列表）：消息隊列, push/sub提醒。
SortedSet（有序集合）：熱門列表, 新動態列表, TopN, 自動排序。
Redis集羣中，某個節點宕機怎麼辦？你碰見過嗎？你的解決思路是什麼？
redis集羣：通常的是至少是2臺服務器，主從服務器！若是redis集羣的主服務器掛了，沒有關係還有備服務器
（哨兵模式和集羣模式）
中間件問題
AcitveMQ的做用、原理、特色？（生產者。消費者。 p2p、訂閱實現流程）
Activemq的做用就是系統之間進行通訊。固然可使用其餘方式進行系統間通訊，若是使用Activemq的話能夠對系統之間的調用進行解耦，實現系統間的異步通訊。原理就是生產者生產消息，把消息發送給activemq。Activemq接收到消息，而後查看有多少個消費者，而後把消息轉發給消費者，此過程當中生產者無需參與。消費者接收到消息後作相應的處理和生產者沒有任何關係。
ActiveMQ若是數據提交不成功怎麼辦？
Activemq有兩種通訊方式，點到點形式和發佈訂閱模式。若是是點到點模式的話，若是消息發送不成功此消息默認會保存到activemq服務端知道有消費者將其消費，因此此時消息是不會丟失的。
若是是發佈訂閱模式的通訊方式，默認狀況下只通知一次，若是接收不到此消息就沒有了。這種場景只適用於對消息送達率要求不高的狀況。若是要求消息必須送達不能夠丟失的話，須要配置持久訂閱。每一個訂閱端定義一個id，在訂閱是向activemq註冊。發佈消息和接收消息時須要配置發送模式爲持久化。此時若是客戶端接收不到消息，消息會持久化到服務端，直到客戶端正常接收後爲止。
此處可能會問各類消息中間件的區別以及應用場景，即RabbitMQ、Kafka、RocketMQ之間的區別，以及裏面的組件，好比我遇到過被問到RabbitMQ裏面五種模式的具體寫法與區別，kafka的處理重複數據，超時等
sku的幾種經常使用設計方法，你的sku是怎麼設計的？
sku:Stock Keeping Unit（庫存量單位)產品統一編號的簡稱，每種產品均對應有惟一的SKU號
SKU屬性的設計，能夠分爲兩類：
(1)經過屬性集關聯SKU屬性 適合品類較少的網站，管理容易些。
(2)產品和SKU屬性直接關聯
適合品類不少網站，比較靈活，可是維護起來數據量比較大。
爲了簡化，我增長SKU屬性關聯產品分類（可爲空，表示是全局的），這樣在建立產品時，能夠只列出全局的+本產品分類的SKU屬性，這樣就不會一會兒列出不少SKU屬性了。SKU屬性分爲前端名稱和後臺名稱兩個，方便不一樣業務含義的SKU屬性，在前端也可以用同一個名稱顯示，如顏色、容量等。另外在操做上能夠作些優化，好比用下拉列表顯示可選的SKU屬性時，能夠同時顯示該屬性的屬性描述，供產品維護人員參考。
基於SKU方式來管理產品時，產品的價格、庫存和圖片等信息必然是放在產品SKU表中處理的，和訂單、購物車等表的關聯，也是經過產品SKU表，而不是產品表。至於產品表，其實是一個總的業務彙總和外部關聯表，但實際銷售的並非它。咱們網站作的更細些，會就每一個產品SKU生成獨立的URL（僞靜態），但從SEO方面考慮，每一個產品SKU擁有獨立
單點登陸具體實現了什麼功能？
Redis在其中是怎麼用的？起了什麼做用？
redis中存儲的都是key-value格式的。拿商品數據來講，key就是商品id，value是商品相關信息的json數據。
在商城系統中當併發量比較高，頻繁的對數據庫進行讀操做的時候都須要添加緩存。例如頁面中內容數據的緩存、商品數據的緩存以及用戶數據的緩存等。
作商品數據的緩存時，由於商品的數據量很大，並且緩存是把數據保存到內存中，此時不可能把全部的商品數據都放到緩存中。因此須要設置商品數據緩存的有效期，當用戶訪問到非熱點數據後，此數據放到緩存中，當緩存到期後就從緩存中刪除，並且長時間不會添加到緩存。而熱點數據一旦從緩存中刪除會立刻又添加到緩存。這樣能夠提升緩存的利用率，同時也減輕了數據庫的壓力。
各模塊是怎麼設計的，如商品參數，廣告位等，數據庫設計思路。。。
總的來講調用和設計上的問的較多，以及秒殺，比較多的是細節，好比秒殺中遇到的一些問題，怎麼解決之類的（面經）