常见的Linux系统简单面试题（三）

适用与任何一名运维工程师,用于Linux运维面试专用，持续更新中~

2020-08-02 更新~

---

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

2. 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 库：

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

> show master status;也正常。

> show master status;
+------------------+-----------+--------------+------------------+-------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+-----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 692143213 |              |                  |                   |
+------------------+-----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

再到 Slave 上查看

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

下面介绍两种解决方法：

• 方法一

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

> stop slave; 
#表示跳过一步错误，
后面的数字可变 
> set global sql_slave_skip_counter =1; 

>start slave; 
#开启同步

> show slave status\G
#查看主从状态
Slave_IO_Running: Yes Slave_SQL_Running: Yes ok
#现在主从同步状态正常了。。。

• 方法二

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

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

$ mysqldump -uroot -p -hlocalhost > mysql.bak.sql 
#进行数据备份

> show master status;
+------------------+-----------+--------------+------------------+-------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+-----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 692143213 |              |                  |                   |
+------------------+-----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

把 mysql 备份文件传到从库机器，进行数据恢复

$ scp mysql.bak.sql root@10.103.25.11:/tmp/ 

停止从库的状态

> stop slave; 

> source /tmp/mysql.bak.sql 
#然后到从库执行 mysql 命令，导入数据备份

设置从库同步，注意该处的同步点，就是主库 show master status 信息里的 | File | Position 两项

> change master to master_host = '10.103.25.10',master_user = 'bak', master_port=3306, master_password='******', master_log_file = 'mysqld-bin.000001', master_log_pos=692143213; 

> start slave; 
#重新开启从同步 

> show slave status\G
#查看同步状态
Slave_IO_Running: Yes Slave_SQL_Running: Yes

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

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

• 二个可以减少延迟的参数:

–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。

3. 消息队列 kafka 和 mq 的区别

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

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

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

4. 软链接和硬链接区别

软连接，其实就是新建立一个文件，这个文件就是专门用来指向别的文件的（那就和 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 开关可以创建软链接

5. 打印一个目录下所有包含字符串 A 的行

$ grep -rn "A" ./ 

或

$ find ./ -name "*.*" | xargs grep  "A"

6. Kill 掉所有包含服务名 a 的进程（xargs 命令）

$ ps -ef | grep "^a" | grep -v grep | cut -c 9-15 | xargs kill -9 

或

ps x | grep a | grep -v grep | awk '{print $1}' | xargs kill -9

7. 谈下对 systemctl 理解

Linux 服务管理两种方式 service 和 systemctl

systemd 是 Linux 系统最新的初始化系统(init),作用是提高系统的启动速度，尽可能启动较少的进程，尽可能更多进程并发启动。

systemd 对应的进程管理命令是 systemctl

systemctl 命令兼容了 service, systemctl 命令管理 systemd 的资源 Unit

8. 谈下对 iptables 的了解

iptables 其实不是真正的防火墙，我们可以把它理解成一个客户端代理，用户通过 iptables 这个代理，将用户的安全设定执行到对应的"安全框架"中，这个"安全框架"才是真正的防火墙，这个框架的名字叫 netfilter iptables 其实是一个命令行工具，位于用户空间，我们用这个工具操作真正的框架。

所以说，虽然我们使用 service iptables start 启动 iptables"服务"，但是其实准确的来说，iptables 并没有一个守护进程，所以并不能算是真正意义上的服务，而应该算是内核提供的功能。

iptables 有 4 表 5 链：

 - filter 表——过滤数据包
 - Nat 表——用于网络地址转换（IP、端口）
 - Mangle 表——修改数据包的服务类型、TTL、并且可以配置路由实现 QOS
 - Raw 表——决定数据包是否被状态跟踪机制处理
 - INPUT 链——进来的数据包应用此规则链中的策略
 - OUTPUT 链——外出的数据包应用此规则链中的策略
 - FORWARD 链——转发数据包时应用此规则链中的策略
 - PREROUTING 链——对数据包作路由选择前应用此链中的规则（所有的数据包进来的时侯都先由这个链处理）
 - POSTROUTING 链——对数据包作路由选择后应用此链中的规则（所有的数据包出来的时侯都先由这个链处理）

9. 页面无法访问排查思路

• 场景一:

无错误状态码 无错误状态码，多数情况下是“ERRCONNECTIONTIMED_OUT”问题。

出现 ERR_CONNECTION_TIMED_OUT错误原因，可以总结为以下 5 点：

 - 服务器带宽跑满
 - 服务没有启动
 - 端口没有正常监听
 - 防火墙或者防火墙策略限制

• 排查思路说明：

1.使用命令 telnet IP + Port 进行测试端口

如果端口是通的，则排查 查看服务器带宽是否跑满

2.如果端口不通，则排查：

 - web 服务没有正常启动
 - 端口没有正常监听
 - 防火墙/安全组/ACL等拦截

若是 web 服务没有正常启动，需要启动服务

若是端口没有正常监听，需要修改配置文件

若是防火墙拦截，需要关闭防火墙进行测试，或者找到相关限制规则进行修改。

• 场景二：网站访问异常代码 4XX。

排查思路：

 - 通过查看其配置文件，并检测其配置文件语法，发现语法正常；
 - 通过ps等命令行查看其 web 服务端口运行正常，没有进程僵尸状况；
 - 具体读配置文件，然后再查找客户客户配置文件所指定的具体目录；
 - 查看磁盘IO或磁盘空间使用率

问题定位到之后，重新以正确的方式挂载客户网站数据；重启服务，问题得以圆满解决；

基于类似问题还可以关注下目录权限等问题。

针对网站访问报错问题几点排查建议：

• 服务器配置文件权限，以及语法的正确性；
• 配置文件中指定的网站相关目录存在问题，及相关权限问题；
• 运行 web 服务的用户和相关权限问题；
• 防火墙的设置问题，导致服务不可达；
• 服务器服务进程僵死问题；
• 配置文件中的非法字符问题；（特别是从 windows 平台直接 cp 过来的配置文件容易报错）这样的问题较难排查，可以通过 type
• 命令或者 file 命令查看文件类型；最好是二进制格式或者 ascii 码，linux 平台可以安装 dos2unix 解决；
• 服务器的错误日志亦是非常关键的问题突破口；
• 查看硬盘使用率

10. redhat 6.X 版本系统 和 centos 7.X 版本有啥区别？

 - 桌面系统（6/GNOE2.x、7/GNOME3.x）
 - 文件系统（6/ext4、7/xfs）
 - 内核版本（6/2.6x、7/3.10x）
 - 防火墙（6/iptables、7/firewalld）
 - 默认数据库（6/mysql、7/mariadb）
 - 启动服务（6/service 启动、7/systemctl 启动）
 - 网卡（6/eth0、7/ens192）等。

---

Over~

1148 0 2020-08-02