技术支持linux面试,面试Linux运维，回来的总结，慢慢成长！

最新推荐文章于 2024-07-05 08:00:00 发布

白告爱吃面

最新推荐文章于 2024-07-05 08:00:00 发布

阅读量281

点赞数

文章标签：技术支持linux面试

好久没面试了，最近也总是在玩，面试前总是很紧张，忐忑的去了，途中在地铁里，人事打来电话不知道什么事，上了下邮件看面试约的时间是3：30估计到那也就不到3点。

去了首先开始做题

几个比较有价值的问题

1.从下面图中，你可以看到那些信息

当时面试官纠正我犯的一个错误就是：

我把10.0.0.1认为是当前用户的ip地址，这一条应该是上一个用户登录的地址。

但回来后我发现其实从w 输出的内容里，我们是可以看到当前用户的登录地址即为10.0.0.1，有很多时候，基础不扎实，就容易像我这样。

从下面的w输出的内容，我们也可以看到8time这个用户的登录时间为19：49

查看到的信息

1当前的登录用户为8time.

2.系统运行时间，登录的用户数

3.系统的负载

4.上一个用户登录的ip

2.数据库问题

1.有一个数据库有60列5000万行，请从锁的角度来说明，会不会影响数据库的性能，如果影响应该怎样解决。(偏题了)

1.首先可以协调程序，对数据库进行水平切分或垂直切分，然后分别存放在不同的数据库里。

2.使用mysql的主从的架构，采用读写分离的方式(读从库，写主库)。对多个从库采用集群的方式，来提高读的性能。

2.Mysql锁的一些知识总结：(未完成)

mysql锁是一个线程阻止其他线程去更新数据的一种方式

A对一个数据进行修改则B只能等待A修改完才能对数据进行修改。

锁的种类：

读锁： A发起一个test表发起一个读锁，则B也可以读到test的内容，但C想写则不能写；简单理解为排他写，(一个读锁后，其他的用户不可以写)；读锁可以理解为一个表加了个门，其他人可以看见里面的内容，但不能进去修改，只能看.

写锁： A发起一个test的写锁，则其他的用户则既不能读，也不能写。写锁相当于为一个表加一个保险柜，既不能看，又不能修改。

死锁： A对表test1发起一个写锁，B也对表test2发起一个写锁，如果此时，A需要访问test2表，则只能等待；如果此时B也要对test1进行操作，则也只能等待；双方都在等待对方，则就产生了死锁

本地锁：A对test1表发起一个本地锁lcok tables test1 read local则B用户则只能在test1表的尾部进行数据的添加。

写的请求大于读的请求，如果同样都是在等待，那写锁则优先于读锁。

默认为写优先，show variables like‘%low%’查看默认为off

在日常的数据库管理中，不建议给普通用户lcok权限。

表锁：锁定一个表大多数引擎都支持

行锁： innodb支持

查看innodb行锁的状态的信息

Show variables like‘%innodb_lock%’;

S-shared共享锁允许对事务进行读

X-exclusive派他所允许对事务进行更新改变一个值

IS 有意向S锁

IX 有意向X锁

3.lvs+keepalived的一些细节

1.问题一：

当我们查看lvs+keepalived架构中，后端一台真实的web服务器上没有负载，通常你会从那些角度去排查呢。

1首先可以在lvs主上面查看使用ipvsadm -L -n --stat查看下lvs上面后端RS的状态，如果此时我们在RS里看不到后端那台真实的web服务器，其他的却正常，我们应该检查下keepalived的配置文件，比如端口是不是写错了、检查的方式是不是有问题、其他配置是不是有问题等。

2.如果确定配置keepalived的配置文件没问题，且ipvsadm查看状态时，发现后端web服务器有数据流。则就检查web服务器上是否有做VIP。

3.检查后端web服务器的80端口是否正常开放。

4.如果上述都正常，那可能就是网络有问题了。解决方法暂时没遇到不好说。

问题二：

Lvs+keepalived中各自的功能是什么？

global_defs {

notification_email {

}

notification_email_from Alexandre.Cassen@firewall.loc

smtp_server 192.168.200.1邮件服务器的地址

smtp_connect_timeout 30

router_id LVS_DEVEL这里仅仅是一个名称而已

}

vrrp_instance VI_1 {

state MASTER主备状态 Master(主) backup(备

interface eth0监听的网卡

virtual_router_id 55通信的频道号，多播的MAC地址

在这个频道里就是，lvs里后端服务器的mac地址表

priority 100权重，权重高的竞选为主

advert_int 1检查的间隔时间

authentication {

auth_type PASS使用的验证方式密码密码为8090

auth_pass 8090

}

virtual_ipaddress {

10.0.0.50vip地址

}

virtual_server 10.0.0.50 80 {设置一个VIP地址跟端口

delay_loop 6服务器轮训的时间

lb_algo wlclvs的调度算法

lb_kind DRlvs使用的模式

persistence_timeout 60会话保持的时间

protocol TCP健康检查的方式

real_server 10.0.10.53 80 {后端真实服务器的地址

weight 100每台机器的权重

TCP_CHECK {TCP检查

connect_timeout 10 连接超时的时间

nb_get_retry 3重试的检查次数

delay_before_retry 3重新检查的间隔

connect_port 80检查的端口

}

real_server 10.0.10.54 80 {

weight 100

TCP_CHECK {

connect_timeout 10

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

浅析lvs跟keepalived的功能

1.如果没有keepalived的，lvs依然可以调度后面的web服务器。

2.对后端服务器的检查，这个我以前一直以为是keepalived做的，其实想想就知道了。面试的时候，面试官跟我说的是keepalived做的。回来我想想也是。也是夜深了，想想真的是么。

为什么不是？

首先lvs是工作在四层，lvs+keepalived中，对后端真实服务器的检测方式，有两种一种是基于端口的，一种是基于脚本的，比如我们可以设置curl -Ihttp://www.test.com端口正常网页不一定正常。后面的明显是基于七层的Http，所以keepalived是lvs中对后端服务器的检测的实现。

所以lvs+keepalived对后端RS的检测应该是keepalived的，有时间我会实验下。