A. 美團前端面試難嗎
美團目前也是在大量的招人啊～～當時參加的是美團打車部門的面試（一年工作經驗以上的），部門技術棧vue，後台就是node，一面通過，等了兩個小時面試二面，然後通知我回去等消息，一般這樣就是掛掉了，毫無疑問。美團是一次性全部面完的。所以去參加最好做好面試四個小時的打算。
先來聊聊一面吧～哈哈
一面
1.簡單的自我介紹，與大體的了解我。。。
一面面試官非常不錯，先問了下幾個項目和用到的技術，會先對我懂的東西做一個大體的了解，比如webpack的單頁面的多頁面切換，webpack的按需載入，一些webpack的配置有哪些，問了有沒有看vue源碼，我說了一個vue的watch，大體問了問我框架方面的東西，發現我對框架並不是很熟練，安慰我說沒有關系。
2.promise的原理
這個面試官最讓人欣賞的就是不會去問你不了解的東西，一開問了我promise，發現我用的並不是很多，就很自然的說沒事，換一種方法問你～～～好和藹啊～
然後就讓我用原生js寫一個回調函數，其實就是問promise的原理了，js寫一個。
3.this指向
這個是面試官手寫了一道變態長以及繞的this指向題，可以自行網路js this指向面試題，看幾道沒有啥問題，需要關注的是其中也考了，argument，和apply(null)。以後想起來再寫吧
4.bind與函數柯里化
也就是寫個bind，這個紅皮書高級函數（22章）有，
可以看下。不過還是得先理解bind的用法，返回一個函數，以及可以傳遞的參數。參數這里涉及到了函數柯里化。都是手寫代碼，而且最好寫的整潔，因為我有些一筆帶過，面試官都讓我寫完整，明確說要看我寫代碼水平
5.==, isNaN, typeof
問這個之前先問了我有幾種數據類型（七種，下圖再加symbol），這里隱形的看你知不知道es6，symbol這個新出的類型。說出了symbol自然會問你這個類型有什麼用。
然後就寫了好多個typeof，isNaN，==的問輸出，這個就是基礎題
6.知道什麼http請求頭？
這個可以說的很多，說了幾個，又主動說了下有關跨域請求頭，之前項目用的cors，於是和他聊了一會，其實面試就是主動表現自己，把自己知道的都說出來，不然幾個請求頭說細不細，要問細了能把人問蒙了，最好把話題引到自己知道的地方。
7.問了css
問了css盒子並畫出來，清除浮動與bfc，兩列布局。
8.說了一大堆其實就是想考我防抖
面試完這個問我想問的問題，我直接問還有二面么？回答有的，又介紹了一會美團打車，說是後台是node，看來要求是前端也要有後台的知識嘍。
二面
二面的是我的學長，可是我被問慘了。。。。問的顯然比一面深入很多，都問了java
1.自我介紹，問項目
針對項目問了不少，當時有一個支付行為的項目，於是問了很多安全方面的問題，蒙蒙的，完全不知道。第一個就很失敗了。然後問了其他的項目，問了websocket。
2.node的EventEmitter用js實現出來
寫出來了，但是可以看出來代碼寫的不規范，學長面試官表示看起來很亂。不過大約算是可以的，指出了幾個問題，讓我進行修改。（之後完善）
3.虛擬dom
其實vue中就有jsx，react的特點之一有jsx，虛擬dom和代碼優化有點關系。
先說下正常對dom的操作，在瀏覽器中分為渲染引擎和js引擎，現在瀏覽器內核一般都是渲染引擎（生成渲染樹），因為js引擎越來越獨立了（所謂的v8引擎？）
然而你在js中獲取dom元素的時候你必須要通過渲染引擎，這樣兩個線程之間的數據交換自然會很慢。所以在前端優化中總是要考慮減少dom操作這一項。包括獲取dom元素變數儲存起來。
jsx是把dom元素變成了儲存在內存中的數據結構。js很快，操作dom也很快。不過也存在缺點，目前的理解就這么點了。
4.路由的實現原理
餓，不知道。。（待會看！）
5.node文件流，java的映射機制（記不太清楚）？
餓。。
6.數組方法map和recer區別？
餓
7.進程與線程的區別
終於有個我會的了，這個顯然想問你js的運行機制。先介紹了下進程與線程。
一個瀏覽器是一個進程，雖然js是單線程的，但是瀏覽器是多線程的，v8引擎也是多線程的，比如有渲染線程，有處理請求的線程。然後說說任務隊列，eventloop。沒有理解很深也不敢往下說。
事件循環可以看下這個，鏈接
8.樹遍歷
先序，中序，後序。我只知道這么多了，顯然想讓我寫一個的，可是不會。也顯然面試官內心已經把我pass掉了，沒多問。
9.問了個演算法
KMP？？反正我不知道。
B. 請問面試美團的正常流程是什麼
美團面試主要是分為筆試和面試，美團是分批面的，基本是一次性面完總共三面，全都是技術面的。一面沒通過，直接說farewell了。前兩面沒壓力，面試官是和顏悅色；到第三面，能明顯感覺到差別，基本面無表情，做好心理准備。面試過程：筆試題目，演算法程序題多，最後安卓前端題，題目還是不難的，題目在lintcode上刷到過一樣的。第一面：隨時Be Nice，一個普通員工就可能是你的面試官；首先做自我介紹。面試官對我的經歷問了幾個問題，然後就是問些很基礎，進程和線程的區別；進程間同步方式，。還問到如何編程實現 a^n ，我就說用二分的思想。說到思想，美團蠻注重思想的，第二第三面過程里如果有什麼你一下子難實現的，你就講清楚你是怎麼個思路，不要消極對待就好。然後就是隨意提問，問到了Java裡面的各種語言機制，問到了計算機網路裡面的三次四次握手，UDP和TCP區別，get和post區別等等，沒有深問。問的很雜很多。
第二面：基本上是沒問操作系統和網路的題目，就出演算法題，有如何判斷一個二叉樹是另一棵二叉樹的子樹；像列印機一樣，倒過來列印一棵樹，比如一個樹是這樣的，輸出4、5、6、2、3、1，這個就用層次遍歷，存儲遍歷過的節點，在每一層的結尾存儲該層的個數……面試官檢查驗證代碼超級仔細，所以面試過程中做題目的時候還是要更加專心一點，不然被他發現錯誤. 接著，第二個問題，自己寫一個Stack類，要實現push、pop操作。
第三面：面試官基本是Boss級別的吧，各種問題啊，興趣愛好未來規劃啥，了解你這個人的性格和美團契合。三面都是技術面，最後還是要寫代碼
1）實現 char* upcase(const char* src, int len)。
2) 類似6，7，8，1，2，3，4，5 的序列中用二分查找某個數。他還會問問看過的書啊，問幾個簡單的問題，能答上來就好。基本是工作要求里提到的名著或者就是教材里學到的東西，因為三面的面試官是大佬，是希望能我們能有積極解決問題熱情。
前期准備：對美團注重演算法早有耳聞，還是很早就開始准備刷題。面試時筆試和面試里都遇到了在lintcode 做過的原題。總之，面美團演算法必要刷，難以實現就用邏輯清晰的思路來拯救面試；在技術都OK前提下，面試官看重的更多是優秀邏輯思維能力，善於從復雜系統表象中分析問題，對解決復雜問題充滿激情。不要遇到困難有消極情緒！
C. 美團面試題：如何設計負載均衡架構支撐千萬級用戶的高並發訪問
1.1 負載均衡介紹
1.1.1 負載均衡的妙用
1.1.2 為什麼要用lvs
那為什麼要用lvs呢？
ü 簡單一句話，當並發超過了Nginx上限，就可以使用LVS了。
ü 日1000-2000W PV或並發請求1萬以下都可以考慮用Nginx。
ü 大型門戶網站，電商網站需要用到LVS。
1.2 LVS介紹
LVS是linux Virtual Server的簡寫，意即Linux虛擬伺服器，是一個虛擬的伺服器集群系統，可以在UNIX/LINUX平台下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立，是 中國國內最早出現的自由軟體項目之一 。
1.2.1 相關參考資料
LVS官網： http://www.linuxvirtualserver.org/index.html
相關中文資料
1.2.2 LVS內核模塊ip_vs介紹
ü LVS無需安裝
ü 安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive
ü ipvsadm是通過命令行管理，而keepalive讀取配置文件管理
ü 後面我們會用Shell腳本實現keepalive的功能
1.3 LVS集群搭建
1.3.1 集群環境說明
主機說明
web環境說明
web伺服器的搭建參照：
Tomcat：
http://www.cnblogs.com/clsn/p/7904611.html
Nginx：
http://www.cnblogs.com/clsn/p/7750615.html
1.3.2 安裝ipvsadm管理工具
安裝管理工具
查看當前LVS狀態，順便激活LVS內核模塊。
查看系統的LVS模塊。
1.3.3 LVS集群搭建
命令集 ：
檢查結果 ：
ipvsadm參數說明： (更多參照 man ipvsadm)
1.3.4 在web瀏覽器配置操作
命令集 ：
至此LVS集群配置完畢 ！
1.3.5 進行訪問測試
瀏覽器訪問：
命令行測試：
抓包查看結果：
arp解析查看：
1.4 負載均衡（LVS）相關名詞
術語說明：
1.4.1 LVS集群的工作模式--DR直接路由模式
DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實伺服器的，而真實伺服器將響應後的處理結果直接返回給客戶端用戶。
DR技術可極大地提高集群系統的伸縮性吵拆昌。但要求調度器LB與真實伺服器RS都有一塊物理升扒網卡連在同一物理網段上，即必須在同一區域網環境。
DR直接路由模式說明：
a)通過在調度御攜器LB上修改數據包的目的MAC地址實現轉發。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。
b)請求的報文經過調度器，而RS響應處理後的報文無需經過調度器LB，因此，並發訪問量大時使用效率很高，比Nginx代理模式強於此處。
c)因DR模式是通過MAC地址的改寫機制實現轉發的，因此，所有RS節點和調度器LB只能在同一個區域網中。需要注意RS節點的VIP的綁定(lo:vip/32)和ARP抑制問題。
d)強調一下：RS節點的默認網關不需要是調度器LB的DIP，而應該直接是IDC機房分配的上級路由器的IP(這是RS帶有外網IP地址的情況)，理論上講，只要RS可以出網即可，不需要必須配置外網IP，但走自己的網關，那網關就成為瓶頸了。
e)由於DR模式的調度器僅進行了目的MAC地址的改寫，因此，調度器LB無法改變請求報文的目的埠。LVS DR模式的辦公室在二層數據鏈路層（MAC），NAT模式則工作在三層網路層（IP）和四層傳輸層（埠）。
f)當前，調度器LB支持幾乎所有UNIX、Linux系統，但不支持windows系統。真實伺服器RS節點可以是windows系統。
g)總之，DR模式效率很高，但是配置也較麻煩。因此，訪問量不是特別大的公司可以用haproxy/Nginx取代之。這符合運維的原則：簡單、易用、高效。日1000-2000W PV或並發請求1萬以下都可以考慮用haproxy/Nginx(LVS的NAT模式)
h)直接對外的訪問業務，例如web服務做RS節點，RS最好用公網IP地址。如果不直接對外的業務，例如：MySQL，存儲系統RS節點，最好只用內部IP地址。
DR的實現原理和數據包的改變
(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址
(d) 由於DS和RS在同一個網路中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那麼此時數據包將會發至Real Server。
(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之後，將響應報文通過lo介面傳送給eth0網卡然後向外發出。 此時的源IP地址為VIP，目標IP為CIP
(f) 響應報文最終送達至客戶端
1.5 在web端的操作有什麼含義？
1.5.1 RealServer為什麼要在lo介面上配置VIP？
既然要讓RS能夠處理目標地址為vip的IP包，首先必須要讓RS能接收到這個包。
在lo上配置vip能夠完成接收包並將結果返回client。
1.5.2 在eth0網卡上配置VIP可以嗎？
不可以，將VIP設置在eth0網卡上,會影響RS的arp請求,造成整體LVS集群arp緩存表紊亂，以至於整個負載均衡集群都不能正常工作。
1.5.3 為什麼要抑制ARP響應？
① arp協議說明
為了提高IP轉換MAC的效率，系統會將解析結果保存下來，這個結果叫做ARP緩存。
ARP緩存表是把雙刃劍
ARP廣播進行新的地址解析
測試命令
windows查看arp -a
③arp_announce和arp_ignore詳解
lvs在DR模式下需要關閉arp功能
arp_announce
對網路介面上，本地IP地址的發出的，ARP回應，作出相應級別的限制:
確定不同程度的限制,宣布對來自本地源IP地址發出Arp請求的介面
arp_ignore 定義
對目標地定義對目標地址為本地IP的ARP詢問不同的應答模式0
抑制RS端arp前的廣播情況
抑制RS端arp後廣播情況
1.6 LVS集群的工作模式
DR（Direct Routing）直接路由模式
NAT（Network Address Translation）
TUN（Tunneling）隧道模式
FULLNAT（Full Network Address Translation）
1.6.1 LVS集群的工作模式--NAT
通過網路地址轉換，調度器LB重寫請求報文的目標地址，根據預設的調度演算法，將請求分派給後端的真實伺服器，真實伺服器的響應報文處理之後，返回時必須要通過調度器，經過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。
收費站模式---來去都要經過LB負載均衡器。
NAT方式的實現原理和數據包的改變
(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP
(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c). IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為後端伺服器IP，然後將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP
(d). POSTROUTING鏈通過選路，將數據包發送給Real Server
(e). Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP
(f). Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然後響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP
LVS-NAT模型的特性
l RS應該使用私有地址，RS的網關必須指向DIP
l DIP和RIP必須在同一個網段內
l 請求和響應報文都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸
l 支持埠映射
l RS可以使用任意操作系統
l 缺陷：對Director Server壓力會比較大，請求和響應都需經過director server
1.6.2 LVS集群的工作模式--隧道模式TUN
採用NAT技術時，由於請求和響應的報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。
為了解決這個問題，調度器把請求的報文通過IP隧道(相當於ipip或ipsec )轉發至真實伺服器，而真實伺服器將響應處理後直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。
由於一般網路服務應答數據比請求報文大很多，採用 VS/TUN技術後，集群系統的最大吞吐量可以提高10倍。
VS/TUN工作流程,它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。
調度器根據各個伺服器的負載情況，連接數多少，動態地選擇一台伺服器，將原請求的報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的真實伺服器。
真實伺服器收到報文後，先將收到的報文解封獲得原來目標地址為VIP地址的報文, 伺服器發現VIP地址被配置在本地的IP隧道設備上(此處要人為配置)，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。
TUN原理和數據包的改變
(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP 。
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然後發至POSTROUTING鏈。 此時源IP為DIP，目標IP為RIP
(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。 此時源IP為DIP，目標IP為RIP
(e) RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裡面還有一層IP首部，而且目標是自己的lo介面VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo介面送給eth0網卡，然後向外傳遞。 此時的源IP地址為VIP，目標IP為CIP
(f) 響應報文最終送達至客戶端
LVS-Tun模型特性
1.6.3 LVS集群的工作模式--FULLNAT
LVS的DR和NAT模式要求RS和LVS在同一個vlan中，導致部署成本過高；TUNNEL模式雖然可以跨vlan，但RealServer上需要部署ipip隧道模塊等，網路拓撲上需要連通外網，較復雜，不易運維。
為了解決上述問題，開發出FULLNAT
該模式和NAT模式的區別是：數據包進入時，除了做DNAT，還做SNAT（用戶ip->內網ip）
從而實現LVS-RealServer間可以跨vlan通訊，RealServer只需要連接到內網。類比地鐵站多個閘機。
1.7 IPVS調度器實現了如下八種負載調度演算法：
a) 輪詢（Round Robin）RR
調度器通過"輪叫"調度演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。
b) 加權輪叫（Weighted Round Robin）WRR
調度器通過"加權輪叫"調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器處理更多的訪問流量。
調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。
c) 最少鏈接（Least Connections） LC
調度器通過"最少連接"調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。
如果集群系統的真實伺服器具有相近的系統性能，採用"最小連接"調度演算法可以較好地均衡負載。
d) 加權最少鏈接（Weighted Least Connections） Wlc
在集群系統中的伺服器性能差異較大的情況下，調度器採用"加權最少鏈接"調度演算法優化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。
e) 基於局部性的最少鏈接（Locality-Based Least Connections） Lblc
"基於局部性的最少鏈接" 調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。
該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器 是可用的且沒有超載，將請求發送到該伺服器。
若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務 器，將請求發送到該伺服器。
f) 帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）
"帶復制的基於局部性最少鏈接"調度演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。
它與LBLC演算法的不同之處是它要維護從一個 目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。
該演算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小連接"原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器。
若伺服器超載，則按"最小連接"原則從這個集群中選出一 台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。
同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低復制的 程度。
g) 目標地址散列（Destination Hashing） Dh
"目標地址散列"調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
h) 源地址散列（Source Hashing）SH
"源地址散列"調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器。
若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
1.8 LVS+Keepalived方案實現
1.8.1 keepalived功能
1. 添加VIP
2. 添加LVS配置
3. 高可用（VIP漂移）
4. web伺服器 健康 檢查
1.8.2 在負載器安裝Keepalived軟體
# 檢查軟體是否安裝
1.8.3 修改配置文件
lb03上keepalied配置文件
lb04的Keepalied配置文件
keepalived persistence_timeout參數意義 LVS Persistence 參數的作用
http://blog.csdn.net/nimasike/article/details/53911363
1.8.4 啟動keepalived服務
1.8.5 在web伺服器上進行配置
注意：web伺服器上的配置為臨時生效，可以將其寫入rc.local文件，注意文件的執行許可權。
使用curl命令進行測試
至此keepalived+lvs配置完畢
1.9 常見LVS負載均衡高可用解決方案
Ø 開發類似keepalived的腳本，早期的辦法，現在不推薦使用。
Ø heartbeat+lvs+ldirectord腳本配置方案，復雜不易控制，不推薦使用
Ø RedHat工具piranha，一個web界面配置LVS。
Ø LVS-DR+keepalived方案，推薦最優方案，簡單、易用、高效。
1.9.1 lvs排錯思路