前段时间有面试机会的时候准备了一下,我也不记得是在哪里找到的,然后就保存在我的有道云笔记里面,今天有点时间,就上传了上来。
回答:部署过,没有深入研究过,一般mongodb部署主从、或者mongodb分片集群;建议3台或5台服务器来部署。MongoDB分片的基本思想就是将集合切分成小块。这些块分散到若干片里面,每个片只负责总数据的一部分。 对于客户端来说,无需知道数据被拆分了,也无需知道服务端哪个分片对应哪些数据。数据在分片之前需要运行一个路由进程,进程名为mongos。这个路由器知道所有数据的存放位置,知道数据和片的对应关系。对客户端来说,它仅知道连接了一个普通的mongod,在请求数据的过程中,通过路由器上的数据和片的对应关系,路由到目标数据所在的片上,如果请求有了回应,路由器将其收集起来回送给客户端。
回答:发布:jenkins配置好代码路径(SVN或GIT),然后拉代码,打tag。需要编译就编译,编译之后推送到发布服务器(jenkins里面可以调脚本),然后从分发服务器往下分发到业务服务器上。
回滚:按照版本号到发布服务器找到对应的版本推送
回答:Tomcat是一个JSP/Servlet容器。其作为Servlet容器,有三种工作模式:独立的Servlet容器、进程内的Servlet容器和进程外的Servlet容器。
进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类:
Tomcat作为应用程序服务器:请求来自于前端的web服务器,这可能是Apache, IIS, Nginx等;
Tomcat作为独立服务器:请求来自于web浏览器;
回答:现在公司的业务都跑在阿里云上,我们首选的监控就是用阿里云监控,阿里云监控自带了ECS、RDS等服务的监控模板,可结合自定义报警规则来触发监控项。上家公司的业务是托管在IDC,用的是zabbix监控方案,zabbix图形界面丰富,也自带很多监控模板,特别是多个分区、多个网卡等自动发现并进行监控做得非常不错,不过需要在每台客户机(被监控端)安装zabbix agent。
回答:在生产环境下,不管是应用数据、还是数据库数据首先在部署的时候就会有主从架构、或者集群,这本身就是属于数据的热备份;其实考虑冷备份,用专门一台服务器做为备份服务器,比如可以用rsync+inotify配合计划任务来实现数据的冷备份,如果是发版的包备份,正常情况下有台发布服务器,每次发版都会保存好发版的包
回答:这个问题我觉得面试官司没问好,正常都会这么问“LVS有哪些负载均衡技术和调度算法?"。我回答就是按我说的这种问法回答的,反正他也频繁点头,当然,笔者回答的可能没有下面我整理出来的那么详细,大概意思我都说明白了。
LVS是Liunx虚拟服务器的简称,利用LVS提供的负载均衡技术和linux操作系统可实现高性能、高可用的服务器集群,一般LVS都是位于整个集群系统的最前端,由一台或者多台负载调度器(Director Server)组成,分发给应用服务器(Real Server)。它是工作在4层(也就是TCP/IP中的传输层),LVS是基于IP负载均衡技术的IPVS模块来实现的,IPVS实现负载均衡机制有三种,分别是NAT、TUN和DR,详述如下:
VS/NAT: 即(Virtual Server via Network Address Translation)
也就是网络地址翻译技术实现虚拟服务器,当用户请求到达调度器时,调度器将请求报文的目标地址(即虚拟IP地址)改写成选定的Real Server地址,同时报文的目标端口也改成选定的Real Server的相应端口,最后将报文请求发送到选定的Real Server。在服务器端得到数据后,Real Server返回数据给用户时,需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户,完成整个负载调度过程。
可以看出,在NAT方式下,用户请求和响应报文都必须经过Director Server地址重写,当用户请求越来越多时,调度器的处理能力将称为瓶颈。
VS/TUN :即(Virtual Server via IP Tunneling)
也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样,只是它的报文转发方法不同,VS/TUN方式中,调度器采用IP隧道技术将用户请求转发到某个Real Server,而这个Real Server将直接响应用户的请求,不再经过前端调度器,此外,对Real Server的地域位置没有要求,可以和Director Server位于同一个网段,也可以是独立的一个网络。因此,在TUN方式中,调度器将只处理用户的报文请求,集群系统的吞吐量大大提高。
VS/DR: 即(Virtual Server via Direct Routing)
也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样,但它的报文转发方法又有不同,VS/DR通过改写请求报文的MAC地址,将请求发送到Real Server,而Real Server将响应直接返回给客户,免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的,但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。
回答负载调度算法,IPVS实现在八种负载调度算法,我们常用的有四种调度算法(轮叫调度、加权轮叫调度、最少链接调度、加权最少链接调度)。一般说了这四种就够了,也不会需要你详细解释这四种算法的。你只要把上面3种负载均衡技术讲明白面试官就对这道问题很满意了。接下来你在简单说下与nginx的区别:
LVS的优点:
- 抗负载能力强、工作在第4层仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的;无流量,同时保证了均衡器IO的性能不会受到大流量的影响;
- 工作稳定,自身有完整的双机热备方案,如LVS+Keepalived和LVS+Heartbeat;
- 应用范围比较广,可以对所有应用做负载均衡;
- 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率。
LVS的缺点:
- 软件本身不支持正则处理,不能做动静分离,这就凸显了Nginx/HAProxy+Keepalived的优势。
- 如果网站应用比较庞大,LVS/DR+Keepalived就比较复杂了,特别是后面有Windows Server应用的机器,实施及配置还有维护过程就比较麻烦,相对而言,Nginx/HAProxy+Keepalived就简单一点
Nginx的优点:
- 工作在OSI第7层,可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则比HAProxy更为强大和灵活;
- Nginx对网络的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势所在;
- Nginx安装和配置比较简单,测试起来比较方便;
- 可以承担高的负载压力且稳定,一般能支撑超过几万次的并发量;
- Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点;
- Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web环境,大有和LAMP环境分庭抗礼之势,Nginx在处理静态页面、特别是抗高并发方面相对apache有优势;
- Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,有需求的朋友可以考虑用其作为反向代理加速器;
Nginx的缺点:
- Nginx不支持url来检测。
- Nginx仅能支持http和Email,这个它的弱势。
- Nginx的Session的保持,Cookie的引导能力相对欠缺。
回答:reids集群原理:
其实它的原理不是三两句话能说明白的,redis 3.0版本之前是不支持集群的,官方推荐最大的节点数量为1000,至少需要3(Master)+3(Slave)才能建立集群,是无中心的分布式存储架构,可以在多个节点之间进行数据共享,解决了Redis高可用、可扩展等问题。集群可以将数据自动切分(split)到多个节点,当集群中的某一个节点故障时,redis还可以继续处理客户端的请求。
redis分片:
分片(partitioning)就是将你的数据拆分到多个 Redis 实例的过程,这样每个实例将只包含所有键的子集。当数据量大的时候,把数据分散存入多个数据库中,减少单节点的连接压力,实现海量数据存储。分片部署方式一般分为以下三种:
(1)在客户端做分片;这种方式在客户端确定要连接的redis实例,然后直接访问相应的redis实例;
(2)在代理中做分片;这种方式中,客户端并不直接访问redis实例,它也不知道自己要访问的具体是哪个redis实例,而是由代理转发请求和结果;其工作过程为:客户端先将请求发送给代理,代理通过分片算法确定要访问的是哪个redis实例,然后将请求发送给相应的redis实例,redis实例将结果返回给代理,代理最后将结果返回给客户端。
(3)在redis服务器端做分片;这种方式被称为“查询路由”,在这种方式中客户端随机选择一个redis实例发送请求,如果所请求的内容不再当前redis实例中它会负责将请求转交给正确的redis实例,也有的实现中,redis实例不会转发请求,而是将正确redis的信息发给客户端,由客户端再去向正确的redis实例发送请求。
redis用在了哪些环境:java、php环境用到了redis,主要缓存有登录用户信息数据、设备详情数据、会员签到数据
回答:其实这种问题都没有具体答案,只是看你回答的内容与面试官契合度有多高,能不能说到他想要的点上,主要是看你排查问题的思路。我是这么说的:问清楚反应的人哪个服务应用或者页面调取哪个接口慢,叫他把页面或相关的URL发给你,首先,最直观的分析就是用浏览器按F12,看下是哪一块的内容过慢(DNS解析、网络加载、大图片、还是某个文件内容等),如果有,就对症下药去解决(图片慢就优化图片、网络慢就查看内网情况等)。其次,看后端服务的日志,其实大多数的问题看相关日志是最有效分析,最好用tail -f 跟踪一下日志,当然你也要点击测试来访问接口日志才会打出来。最后,排除sql,,找到sql去mysql执行一下,看看时间是否很久,如果很久,就要优化SQL问题了,expain一下SQL看看索引情况啥的,针对性优化。数据量太大的能分表就分表,能分库就分库。如果SQL没啥问题,那可能就是写的逻辑代码的问题了,一行行审代码,找到耗时的地方改造,优化逻辑
zabbix和nagios。说完了之后,面试官就让我说一下这两个监控有啥区别:
从web功能及画图来讲:
Nagios简单直观,报警与数据都在同一页面, 红色即为问题项。Nagios web端不要做任何配置。 Nagios需要额外安装插件,且插件画图不够美观。
Zabbix监控数据与报警是分开的,查看问题项需要看触发器,查看数据在最新数据查看。而且zabbix有很多其它配置项, zabbix携带画图功能,且能手动把多个监控项集在一个图中展示。
从监控服务来讲:
Nagios自带的监控项很少。对一些变动的如多个分区、多个网卡进行监控时需要手动配置。
Zabbix自带了很多监控内容,感觉zabbix一开始就为你做了很多事,特别是对多个分区、多个网卡等自动发现并进行监控时,那一瞬间很惊喜,很省心的感觉。
从批量配置和报警来讲:
Nagios对于批量监控主机,需要用脚本在server端新增host,并拷贝service文件。 Nagios用脚本来修改所有主机的services文件,加入新增服务。
Zabbix在server端配置自动注册规则,配置好规则后,后续新增client端不需要对server端进行操作。 Zabbix只需手动在模板中新增一监控项即可。
总体来讲:
Nagios要花很多时间写插件,Zabbix要花很多时间探索功能。
Nagios更易上手,Nagios两天弄会,Zabbix两周弄会。
Zabbix画图功能比Nagios更强大
Zabbix对于批量监控与服务更改,操作更简洁;Nagios如果写好自动化脚本后,也很简单,问题在于写自动化脚本很费神。
面试经典题目收集
http://blog.51cto.com/sandshell/2072733