1、如何检测某个端口所占用的进程

2、对于linux主机的cpu负载使用，什么情况下user的比例升高，什么情况下system的比例升高，请联系实际举例。

3、在不umount的情况下，如何重新设置mount的参数。

4、如果不小心在系统下执行了chmod -x/sbin/chmod 怎么办？

5、linux文件的权限位x对目录和文件有何不同？

6、找出/taomee目录下的所有常规文件并设置权限644

7、如何查找某一文件被哪个进程打开？

8、新增一块存储设备，lvm操作的命令如何写

9、简述dns原理、端口；使用协议及其作用；View视图；DNS主从

10、系统自动化安装工具，是否用过，简要描述

11、请简述LVS描述，算法、DR优势及其过程描述

12、简述tcpdump的各种使用

13、简述cacti原理、nagios原理。比较；客户端服务端。agent名称

14、简要描述mysql主从的搭建及其故障恢复，

15、iptables简要描述，几个表。几条链

16、简要描述VLAN原理等

17、简述 对Access、Hybrid和Trunk三种模式的理解

18、如何使不同VLAN间通信

19、简要描述二层交换机三层交换机有什么不同

20、简要描述单臂路由知识

21、linux网卡bounding。bounding的主备模式下如何进行网络连接达到主备，上层路由端需要什么设置？

22、判断一个文件是否为字符设备，如果是将其拷贝至/etc

23、在A目录下创建50个文件file1-file50，然后将其移至/path/B

24、LINUX系统软件安装和卸载的常见方法

25、Windows和LINUX常用的远程连接工具有那些

26、如何修改LINUX的IP地址、网关和主机名

27、编写脚本实现以下功能；
每天早上5点开始做备份
要备份的是/var/mylog里所有文件和目录可以压缩进行备份
备份可以保存到别一台器上192、168、1、2 FTP帐号 aaa 密码 bbb
要示每天的备份文件要带有当天的日期标记

28、1000台服务器需要放一个2G的单个文件，请设计几种放置方法，并且描述各种方法利弊 （涉及到一个对单播多播组播概念的描述，如果明白，为较好的一种方法）

29、双网卡服务器，对网络做高可用，画一个简图

30、如何将本地80端口的请求转发到8080端口，当前主机IP为192.168.2.1 ？

31、Shell循环语句有哪些？

32、通过Apache访问日志access.log 统计IP和每个地址访问的次数，按从大到小前10名？

33、编写shell脚本，获取本机的网络地址。比如IP地址是192.168.100.2/255.255.255.0，那么它的网络地址是192.168.100.1/255.255.255.0

34、写一个脚本查找最后创建时间是3天前，后缀是*.log的文件并删除。

35、写一个脚本将数据库备份并打包至远程服务器192.168.1.1 /backup目录下

36、如何重置mysqlroot密码?

37、如何让history命令显示具体时间？

38、如何查看占用端口8080 的进程

39、LVS四层负载均衡与Nginx七层负载均衡原理

40、keepalived高可用原理

Git 和 Svn 的区别

Git 是分布式的，而 Svn 不是分布的;

Git 把内容按元数据方式存储，而 SVN 是按文件;

Git 没有一个全局版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征;

Git 的内容的完整性要优于 SVN: GIT 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏;

Git 下载下来后，在 OffLine 状态下可以看到所有的 Log,SVN 不可以; SVN 必须先 Update 才能 Commit,忘记了合并时就会出现一些错误，git 还是比较少的出现这种情况。

克隆一份全新的目录以同样拥有五个分支来说，SVN 是同时复製 5 个版本的文件,也就是说重复五次同样的动作。而 Git 只是获取文件的每个版本的 元素，然后只载入主要的分支(master)在我的经验,克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约 1500 个文件的 SVN,耗了将近一个小时！而 Git 只用了区区的 1 分钟！

版本库（repository):SVN 只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git 可以有无限个版本库。或者，更正确的说法，每一个 Git 都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於 GitHub 的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

分支（Branch）在 SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。

Git 的分支名是可以使用不同名字的。例如：我的本地分支名为 OK，而在主要版本库的名字其实是 master。

提交（Commit）在 SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而 Git 的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git 的“推”其实是在执行“同步”（Sync）。

总结：SVN 的特点是简单，只是需要一个放代码的地方时用是 OK 的。

Git 的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(当然这是开发者最关心的地方)，不过想各位能更好使用它，需要花点时间尝试一下。

mysql 主从原理？主从不同步怎么办？主从慢，差的多咋办？

master 将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）slave 将 master 的 binary log events 拷贝到它的中继日志 (relay log) slave 重做中继日志中的事件，将改变反映它自己的数据。或从库生成两个线程，一个 I/O 线程，一个 SQL 线程；

i/o 线程去请求主库 的 binlog，并将得到的 binlog 日志写到 relay log（中继日志） 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o 线程传 binlog；

SQL 线程，会读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

先上 Master 库：

mysql>show processlist;查看下进程是否 Sleep 太多。发现很正常。

show master status;也正常。

mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +-------------------+----------+--------------+-------------------------------+ | mysqld-bin.000001 | 3260 | | mysql,test,information_schema | +-------------------+----------+--------------+-------------------------------+ 1 row in set (0.00 sec) 再到 Slave 上查看

mysql> show slave status\G
Slave_IO_Running: Yes Slave_SQL_Running: No 可见是 Slave 不同步

下面介绍两种解决方法：

方法一：忽略错误后，继续同步 该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况 解决：

stop slave; #表示跳过一步错误，后面的数字可变 set global sql_slave_skip_counter =1; start slave; 之后再用mysql> show slave status\G查看：

Slave_IO_Running: Yes Slave_SQL_Running: Yes ok，现在主从同步状态正常了。。。

方式二：重新做主从，完全同步 该方法适用于主从库数据相差较大，或者要求数据完全统一的情况 解决步骤如下：

先进入主库，进行锁表，防止数据写入 使用命令：mysql> flush tables with read lock; 注意：该处是锁定为只读状态，语句不区分大小写

进行数据备份 #把数据备份到 mysql.bak.sql 文件 [root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql 这里注意一点：数据库备份一定要定期进行，可以用 shell 脚本或者 python 脚本，都比较方便，确保数据万无一失

查看 master 状态 mysql> show master status; ±------------------±---------±-------------±------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | ±------------------±---------±-------------±------------------------------+ | mysqld-bin.000001 | 3260 | | mysql,test,information_schema | ±------------------±---------±-------------±------------------------------+ 1 row in set (0.00 sec) 把 mysql 备份文件传到从库机器，进行数据恢复 #使用 scp 命令 [root@server01 mysql]# scp mysql.bak.sql root@192.168.128.101:/tmp/ 停止从库的状态 mysql> stop slave; 然后到从库执行 mysql 命令，导入数据备份 mysql> source /tmp/mysql.bak.sql 设置从库同步，注意该处的同步点，就是主库 show master status 信息里的 | File | Position 两项 change master to master_host = ‘192.168.128.100’, master_user = ‘rsync’, master_port=3306, master_password=’’, master_log_file = ‘mysqld-bin.000001’, master_log_pos=3260; 重新开启从同步 mysql> start slave; 查看同步状态 mysql> show slave status\G查看：

Slave_IO_Running: Yes Slave_SQL_Running: Yes 好了，同步完成啦。

如果延迟比较大，就先确认以下几个因素：

从库硬件比主库差，导致复制延迟; 主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。更高版本的 mysql 可以支持多线程复制 慢 SQL 语句过多 网络延迟 master 负载：主库读写压力大，导致复制延迟，架构的前端要加 buffer 及缓存层 slave 负载 一般的做法是，使用多台 slave 来分摊读请求，再从这些 slave 中取一台专用的服务器，只作为备份用，不进行其他任何操作。另外，2 个可以减少延迟的参数:

–slave-net-timeout=seconds 单位为秒，默认设置为 3600 秒

#参数含义：当 slave 从主数据库读取 log 数据失败后，等待多久重新建立连接并获取数据

– master-connect-retry=seconds?单位为秒?默认设置为 60 秒 #参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。通常配置以上 2 个参数可以减少网络问题导致的主从数据同步延迟 MySQL 数据库主从同步延迟解决方案;

最简单的减少 slave 同步延时的方案就是在架构上做优化，尽量让主库的 DDL 快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1之类的设置，而 slave 则不需要这么高的数据安全，完全可以讲sync_binlog设置为 0 或者关闭 binlog，innodb_flushlog也可以设置为 0 来提高 sql 的执行效率。另外就是使用比主库更好的硬件设备作为 slave。

kafka 和 mq 的区别

作为消息队列来说，企业中选择 mq 的还是多数，因为像 Rabbit，Rocket 等 mq 中间件都属于很成熟的产品，性能一般但可靠性较强，而 kafka 原本设计的初衷是日志统计分析，现在基于大数据的背景下也可以做运营数据的分析统计，而 redis 的主要场景是内存数据库，作为消息队列来说可靠性太差，而且速度太依赖网络 IO，在服务器本机上的速度较快，且容易出现数据堆积的问题，在比较轻量的场合下能够适用。

RabbitMQ,遵循 AMQP 协议，由内在高并发的 erlanng 语言开发，用在实时的对可靠性要求比较高的消息传递上。

kafka 是 Linkedin 于 2010 年 12 月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

k8s service 类型？

ClusterIP 集群内部容器访问地址，会生成一个虚拟 IP 与 pod 不在一个网段。

NodePort 会在宿主机上映射一个端口，供外部应用访问模式。

Headless CluserIP 无头模式，无 serviceip，即把 spec.clusterip 设置为 None 。

LoadBalancer 使用外部负载均衡。

k8s 健康检查方式

存活性探针（liveness probes）和就绪性探针（readiness probes） 用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。语法是一样的。

k8s pod 状态

Pod --Pending 状态

Pending 说明 Pod 还没有调度到某个 Node 上面。可以通过 kubectl describe pod命令查看到当前 Pod 的事件，进而判断为什么没有调度。可能的原因包括

资源不足，集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源。

HostPort 已被占用，通常推荐使用 Service 对外开放服务端口

Pod --Waiting 或 ContainerCreating 状态

首先还是通过 kubectl describe pod 命令查看到当前 Pod 的事件。可能的原因包括

镜像拉取失败，比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大，拉取超时等。

CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如无法配置 Pod 、无法分配 IP 地址

容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数。

Pod – ImagePullBackOff 状态

这也是我们测试环境常见的，通常是镜像拉取失败。这种情况可以使用 docker pull 来验证镜像是否可以正常拉取。

或者 docker images | grep 查看镜像是否存在（系统有时会因为资源问题自动删除一部分镜像），

Pod – CrashLoopBackOff 状态

CrashLoopBackOff 状态说明容器曾经启动了，但可能又异常退出了。此时可以先查看一下容器的日志 kubectl logskubectl logs --previous

这里可以发现一些容器退出的原因，比如

容器进程退出 健康检查失败退出 Pod --Error 状态

通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括

依赖的 ConfigMap、Secret 或者 PV 等不存在。请求的资源超过了管理员设置的限制，比如超过了 LimitRange 等。

违反集群的安全策略，比如违反了 PodSecurityPolicy 等。

容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定。

Pod --Terminating 或 Unknown 状态 从 v1.5 开始，Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态。想要删除这些状态的 Pod 有三种方法：

从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node。Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。用户强制删除。用户可以执行 kubectl delete pods–grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是 StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题。

Pod – Evicted 状态

出现这种情况，多见于系统内存或硬盘资源不足，可 df-h 查看 docker 存储所在目录的资源使用情况，如果百分比大于 85%，就要及时清理下资源，尤其是一些大文件、docker 镜像。

k8s 资源限制

对于一个 pod 来说，资源最基础的 2 个的指标就是：CPU 和内存。Kubernetes 提供了个采用 requests 和 limits 两种类型参数对资源进行预分配和使用限制。

limit 会限制 pod 的资源利用：

当 pod 内存超过 limit 时，会被 oom。当 cpu 超过 limit 时，不会被 kill，但是会限制不超过 limit 值。

软链接和硬链接区别

软连接，其实就是新建立一个文件，这个文件就是专门用来指向别的文件的（那就和 windows 下的快捷方式的那个文件有很接近的意味）。软链接产生的是一个新的文件，但这个文件的作用就是专门指向某个文件的，删了这个软连接文件，那就等于不需要这个连接，和原来的存在的实体原文件没有任何关系，但删除原来的文件，则相应的软连接不可用（cat 那个软链接文件，则提示“没有该文件或目录“）

硬连接是不会建立 inode 的，他只是在文件原来的 inode link count 域再增加 1 而已，也因此硬链接是不可以跨越文件系统的。相反是软连接会重新建立一个 inode，当然 inode 的结构跟其他的不一样，他只是一个指明源文件的字符串信息。一旦删除源文件，那么软连接将变得毫无意义。而硬链接删除的时候，系统调用会检查 inode link count 的数值，如果他大于等于 1，那么 inode 不会被回收。因此文件的内容不会被删除。

硬链接实际上是为文件建一个别名，链接文件和原文件实际上是同一个文件。可以通过 ls -i 来查看一下，这两个文件的 inode 号是同一个，说明它们是同一个文件；而软链接建立的是一个指向，即链接文件内的内容是指向原文件的指针，它们是两个文件。

软链接可以跨文件系统，硬链接不可以；软链接可以对一个不存在的文件名(filename)进行链接（当然此时如果你 vi 这个软链接文件，linux 会自动新建一个文件名为 filename 的文件）,硬链接不可以（其文件必须存在，inode 必须存在）；软链接可以对目录进行连接，硬链接不可以。两种链接都可以通过命令 ln 来创建。ln 默认创建的是硬链接。使用 -s 开关可以创建软链接

mount 永久挂载

vi /etc/fstab UUID=904C23B64C23964E /media/aborn/data ntfs defaults 0 2 其中第一列为 UUID, 第二列为挂载目录（该目录必须为空目录，必须存在），第三列为文件系统类型，第四列为参数，第五列 0 表示不备份，最后一列必须为２或 0(除非引导分区为 1)

参考链接 ：
干货｜面试真题分享一 ： https://mp.weixin.qq.com/s/2XDtMeMoEdoGC4xaCfAwAw

参考链接 ：

干货｜面试真题分享一 ：https://mp.weixin.qq.com/s/2XDtMeMoEdoGC4xaCfAwAw