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排错思路