将要面试腾讯TEG的运维开发实习生，围绕简历预测一下面试内容，提前准备，以防到时候死得太难看
希望面试官手下留情，在此跪谢！！！
（以下均为本菜鸟的自导自演）
Q1：你的简历我大致看了一下，首先自我介绍一下吧？你学的东西？
A1：好的，姓名性别啥的就不说了，和简历上一样。是目前就读于**大学的，信息管理与信息系统专业的大三学生。在大二到大三期间，跟着导师一起做项目，（我们本科导师制的），包括简历上写到的varnish+nginx实现CDN加速和ELK+redis+http，都是导师带领然后自己独立完成，刚开始的时候带着我们看架构，谷歌、亚马逊、IBM这些...问我们有没有兴趣了解一下，有的话就带着我们做项目，然后还会花时间给我们讲讲包括最近的区块链、比特币这些，大概就是这样介绍吧。。。
Q2：平时常用的命令有哪些？
A2：ls: 类似于dos下的dir命令
cd： 用于切换用户当前工作目录
pwd：用于显示用户当前工作目录
cat：类似于dos下的type命令，显示或连结一般的ascii文本文件 echo：将输入的字符串送往标准输出，输出的字符串间以空白字符隔开， 并在最后加上换行符，脚本编写中常用
head，tail：查看文本文件，区别在于： head显示文件的头n行，tail显示文件的尾n行
wc：用于统计指定文件中的字节数、字数、行数 grep：用于从文件面搜索包含指定模式的行并打印出来，它是一种强大的文本搜索工具，支持使用正则表达式搜索文本，多用于脚本
man：相当于Unix/Linux的联机Help，像查字典
管道符：两个命令连用的时候，利用Linux所提供的管道符“|”将两个命令隔开，管道符左边命令的输出就会作为管道符右边命令的输入
basename用于查看文件不含路径的名字，dirname则用于查看文件路径
uname -a ",可显示电脑以及操作系统的相关信息
"cat /proc/version",说明正在运行的内核版本
"cat /etc/issue", 显示的是发行版本信息
【腾讯一面准备】Q3：防火墙是什么？常用的防火墙策略有哪些？
A3：使用防火墙肯定是为了网络安全，实现访问控制，防火墙就像一个保护屏障一样的存在，就像过安检
防火墙策略一般分为两种，一种叫“通”策略，一种叫“堵”策略，通策略，默认门是关着的，必须要定义谁能进。
“赌”策略是大门洞开，但不是谁都能进，必须有身份认证，否则不能进。所以我们要定义，让进来的进来，让出去的出去。
所以通，是要全通，赌，是要选择
用的比较多的功能有3个：1.filter 定义允许或者不允许；2.nat 定义地址转换； 3.mangle功能:修改报文原数据
Q4：高级网络配置有哪些？工作原理？
A4：team和网桥。在 linux 中， centOS7之前都是使用bond机制来实现多网络绑定同一个IP 地址,按不同的模式来负载均衡或者轮回接替管理处理数据，而到了contos7之后，有了nmcli，使用网路组 team 机制。
team ：也是链路聚合 最多支持8块网卡，team 和bond功能类似，不需要手动加载相应内核模块
支持4种模式：广播容错 broadcast轮询roundrubin主备activebackup负载均衡loadbalance
网桥：就是把一台机器上若干个网络接口连接起来，使得网口之间的报文能够相互转发。一个网口收到报文后，
在这个网口复制转发
网桥的难点在于：
1.mac地址，起初，网桥是没有任何端口与地址的对应关系的，但是又非常关心数据包的来源，到底是从哪个端
口来的，所以要
建立地址-端口对照表
2.报文转发，每发送一个数据包，网桥都会提取目的mac地址，再从CAM表中找哪个端口把数据包发出去
Q5：关于LNMP搭建？
A5：L是Linux，N是nginx，M是mysql，P是php，一个网站服务架构，这四种软件均为免费开源软件，组合到一起，成为一个免费、高效、扩展性强的网站服务系统
如果把nginx换成apache就是LAMP架构
这里就不得不提nginx的优点了，性能稳定、功能丰富、运维简单、处理静态文件速度快、消耗的资源少，支持高并发
apache 也有自身优势，开源、稳定、模块功能丰富，缺点是有些臃肿，内存和cpu开销大
虽然apache作为web服务器来负载php是最好的选择，但是如果流量很大，还是会用到nginx来负载非php的web请求
解决web服务器的缓存，apache有自己的缓存模块，还可以外加squid模块进行缓存，把squid放在apache的前端来缓存web服务器生成的动态页面。访问量过大，则可以考虑使用memcache来做分布式缓存
php是在服务器端执行的嵌入HTML文档的脚本语言，php的加速依靠eAccelerator加速器实现，优化动态缓存，是php脚本在编译状态下，消除对服务器的开销，优化脚本，提高执行率
Q6：lvs原理是什么？
A6：lvs是一个虚拟服务器集群。假设有一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个负载调度器。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访 问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检 测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器。
Q7：keepalived+lvs怎样实现高可用负载均衡？
A7：在这个项目中，lvs的作用就是负载均衡，工作在网络层，可以把很多低性能服务器集中在一起形成一个集群，众人拾柴火焰高嘛，形成一个超级服务器。这个架构总共有3层，最前端是负载均衡，中间是服务器集群，底端是数据共享存储。在web服务器集群之前一定有一个负载均衡器，他的任务是作为web服务器的入口，挑选一个最合适的web，将客户端的请求转发给他，看似是客户直接访问了后端服务器，其实不是，这对用户来说是透明的
lvs的转发：NAT模式和DR模式，修改IP地址和修改MAC地址
nat：用户发起访问请求，经过网关服务器（负载均衡服务器），将目的地址修改，web服务器中响应一致的IP地址又返回给网关，这个时候网关再将IP地址修改回原来的。外网和内网地址映射技术
DR：用户发起访问请求，请求由LVS接受，返回的时候由真实提供服务的服务器返回，不经过LVS。经过网关，LVS只修改MAC地址，找到web中一致的MAC地址，源IP和目的IP都不变，LVS做了一下移花接木。网关收到LVS转发来的包，链路层发现Mac是自己的，传给网络层，发现IP也是自己的，这个包就被合法接受了。由于物理IP和目的IP一致，不需要负载均衡器进行地址转换，直接将数据包返回给用户，避免负载均衡器的网卡带宽瓶颈
Q8：什么是主从复制？过程是怎样的？
A8：主从复制有多种类型一主一从、一主多从、多主一从、主主复制、联级复制。主要用于灾备时的故障切换；读写分离时提供查询服务；备份避免影响业务。原理：
MySQL数据库的复制需要启动三个线程来实现：其中1个在主服务器上，另两个在从服务器上。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程，是从服务器创建用于读取中继日志并执行日志中包含的更新。
在前面的描述中，每个从服务器有3个线程。有多个从服务器的主服务器创建为每个当前连接的从服务器创建一个线程；每个从服务器有自己的I/O和SQL线程。
这样读取和执行语句被分成两个独立的任务。如果语句执行较慢则语句读取任务没有慢下来。例如，如果从服务器有一段时间没有运行了，当从服务器启动时，其I/O线程可以很快地从主服务器索取所有二进制日志内容，即使SQL线程远远滞后。如果从服务器在SQL线程执行完所有索取的语句前停止，I/O 线程至少已经索取了所有内容，以便语句的安全拷贝保存到本地从服务器的中继日志中，供从服务器下次启动时执行。这样允许清空主服务器上的二进制日志，因为不再需要等候从服务器来索取其内容。
Q9：在主从复制中可能会出现什么问题吗？如何解决？
A9：主库宕机后，数据可能丢失，从库只有一个sql thread，主库写压力大，复制很可能延时
解决方法是：半同步复制---解决数据丢失的问题；并行复制----解决从库复制延迟的问题
Q10：半同步复制的原理是什么？
A10:MySQL通过复制实现存储系统的高可用。目前，MySQL支持的复制方式有：
1.异步复制：原理最简单，性能最好。但是主备之间数据不一致的概率很大。2.半同步复制：相比异步复制，半同步复制牺牲了一定的性能，提升了主备之间数据的一致性（有一些情况还是会出现主备数据不一致）。3.组复制：基于Paxos算法实现分布式数据复制的强一致性。只要大多数机器存活就能保证系统可用。相比半同步复制，组复制的数据一致性和系统可用性更高
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
还有一种全同步复制，指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
Q11：半同步复制是不是完美的？会不会有什么潜在问题？
A11：半同步复制可能存在的问题：
事务还没发送到从库上
此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。
事务已经发送到从库上
此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。
Q12：并行复制的原理是什么？
A12：在MySQL 5.6版本之前，Slave服务器上有两个线程I/O线程和SQL线程。I/O线程负责接收二进制日志（更准确的说是二进制日志的event），SQL线程进行回放二进制日志。如果在MySQL 5.6版本开启并行复制功能，那么SQL线程就变为了coordinator线程，coordinator线程主要负责以前两部分的内容：
若判断可以并行执行，那么选择worker线程执行事务的二进制日志
若判断不可以并行执行，如该操作是DDL，亦或者是事务跨schema操作，则等待所有的worker线程执行完成之后，再执行当前的日志
这意味着coordinator线程并不是仅将日志发送给worker线程，自己也可以回放日志，但是所有可以并行的操作交付由worker线程完成。coordinator线程与worker是典型的生产者与消费者模型。
MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave服务器的回放与主机是一致的即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制，对于二进制日志格式也无特殊的要求（基于库的并行复制也没有要求）。MySQL 5.7并行复制的思想简单易懂，一言以蔽之：一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）。
Q13：什么是MySQL的读写分离？实现原理是什么？
A13：MySQL通过读写分离来提升数据库的并发负载能力 ，应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器使用专门的数据库访问模块，使数据库读写分离对应用透明。
Q14：关于hadoop平台了解多少？
A14：要解释清楚什么是Hadoop那得要从大数据说起，90年代的数据量相当于10个零件，一个小朋友1分钟走一趟搬1个零件，花10分钟可以搬走这些零件;
90年代以后的数据量相当于10000个零件，这个小朋友也长大了，他1分钟走一趟可以搬4个零件，那么要搬走这些零件要花2500分钟，数据读取技术的发展完全跟不上数据量的增长速度。运用分布式解决单体能力有限的问题，就是hadoop。我们完全没必要培养一个1分钟能搬100个人零件的壮汉，那也不太现实1个人搬零件搬得太慢我们可以请10个人呀，再不行就请100个人、1000个人，这就是所谓的分布式。
Hadoop核心设计：HDFS和MapReduce
大数据时代我们面临的是以TB、PB甚至EB为单位的数据，我们需要建立一个既能存的下如此大量的数据，而且还能高速高效地读写文件的文件管理系统——HDFS。HDFS也就是Hadoop分布式文件系统，将一份巨型的文件分散到多台存储设备中，并配合一个调度程序来管理这些文件。
关于什么是HDFS？举个例子来说明，就是某零件厂的老板(客户Client)手里有一大批零件要存放。然而一个单独的仓库根本无法存放如此之多的零件。于是老板想到了建立一个仓库集群(HDFS)，把自己的零件分批存放在不同的仓库(主机host)里，再建立一个覆盖所有仓库的管理系统。当文件都通过HDFS存放好之后，我们就要考虑如何来利用这些数据了。人们常常通过数据之间的关联来挖掘出数据中的潜在价值，而杂乱无章的数据会对数据挖掘产生很大的阻碍。这时候就需要建立一个编程模型来对数据进行排序整理，这就是Hadoop的另一个核心——Mapreduce
关于什么是Mapreduce？还是举个例子来说明，依旧是那个零件厂老板，有一天，他突然要求把所有的零件分类统计数量，于是，他安排管理员和清点员，管理员又指挥清点员把每包零件拆开数个数，这是Map。零件拆完之后还得装回去，于是又安排整理员去整理，整理员1负责整理零件A和零件B，整理员2负责整理零件C和零件D......之后开始统计，清点员向整理员他所清点的零件的种类及个数，最后整理员将信息汇总起来，这是reduce。总体说来，HDFS是Hadoop的储存基础，是数据层面的，提供储存海量数据的方法(分布式储存)。而MapReduce，是一种引擎或是一种编程模型，可以理解为数据的上一层，我们可以通过编写MapReduce程序对HDFS中海量的数据进行计算处理(分布统计整合)。
Q15：zabbix和cacti监控原理？
A15：Zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
工作原理：zabbix agent需要安装到被监控的主机上，它负责定期收集各项数据，并发送到zabbix server端，zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展现和绘图。这里agent收集数据分为主动和被动两种模式： 主动：agent请求server获取主动的监控项列表，并主动将监控项内需要检测的数据提交给server/proxy 被动：server向agent请求获取监控项的数据，agent返回数据。 cacti是用php语言实现的一个软件，它的主要功能是用snmp服务获取数据，然后用rrdtool储存和更新数据，当用户需要查看数据的时候用rrdtool生成图表呈现给用户。因此，snmp和rrdtool是cacti的关键。Snmp关系着数据的收集，rrdtool关系着数据存储和图表的生成。
工作原理：分三个部分。Cacti首先要做的工作就是收集数据，cacti使用Poller（轮询器）收集数据。Poller是操作系统scheduler的扩展，现在的IT设施中会有许多不同的设备，如服务器、网络设备等，cacti主要使用SNMP协议来从远端的设备上收集数据，所有可以使用SNMP协议的设备都可以被cacti监控。
存储收集到的数据有许多方法，可以使用数据库、平面文件等，cacti使用的是RDDTool。RRD是Round Robin Database（环形数据库）的缩写，RRD用来存储和显示时间序列数据，如网络带宽、机房温度、服务器负载等，RRD使用非常紧凑的方式存储数据，数据不会随着时间的推移而增大，RRD还可以生成美观的图形。
Cacti最大的一个特点是内置了RRDTool画图功能，将其与通用的web服务器相结合，可以实现在任意平台上使用浏览器就可以查看监控画面
