面试时切记:勿紧张,逻辑排列清楚,思路清晰
1.面试基础题:
1.你常用的命令都有哪些?(不要一下次说出很多,常用命令代表你之前有没有工作经验)
答:在某些软件运行不流畅的情况下会先用free查看内存,磁盘使用率做的监控,超过多少的话会报警我们去清理,命令是df -h。有些时候服务未响应会用ps命令查看一下进程,或者查看一下pid文件是否存在。如果服务卡死会使用kill命令来杀掉进程,重新启动服务
2.在公司的日常会做些什么?
答:根据自己简历总结,最好多说一些有关于自动化的与shell脚本的东西,自己懂得技术不需要说太多,关键在于精
3.你写过最长的脚本是哪些?
答:这个需要根据自己来讲,比如说一些rpm包手写启动脚本与开机自启动配置文件,Jenkins+gitlab自动化部署(持续交付)
4.接触过哪些高可用与分布式的架构?
答:博主是这样回答的:由于公司是发展型公司,web端之前使用的是nginx与Keepalived,在当时nginx是完全可以承载初期的访问量的,后期访问量增大以后经过挑选与方便后期维护的方便选用了lvs+keepalived做负载,满足了当下公司访问量变大的需求
代码上线问题:公司之前服务器少,只搭建了一些基础性能方面的架构,并没有去做一键化部署。但是在后期版本不断更新迭代时需要不停的手动部署环境太费时间与人力,于是向公司申请新服务器部署基于Jenkins,docker实现自动化部署(持续交付)
分布式架构:
公司数据库是做的两种四从的方案,实现读写分离与redis缓存机制,来减少数据库缓存读写压力
2.面试进阶题:
1.MySQL中怎么实现主从同步的?
答:
-
- 主库db的更新事件(update、insert、delete)被写到binlog
- 主库创建一个binlog dump thread,把binlog的内容发送到从库
- 从库启动并发起连接,连接到主库
- 从库启动之后,创建一个I/O线程,读取主库传过来的binlog内 容并写入到relay log
- 从库启动之后,创建一个SQL线程,从relay log里面读取内容,从Exec_Master_Log_Pos位置开始执行读取到的更新事件,将更新内容写入到slave的db
2.lvs/nginx/haproxy优缺点?
答:LVS的优点:
```
1、抗负载能力强、工作在第4层仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的;无流量,同时保证了均衡器IO的性能不会受到大流量的影响;
2、工作稳定,自身有完整的双机热备方案,如LVS+Keepalived和LVS+Heartbeat;
3、应用范围比较广,可以对所有应用做负载均衡;
4、配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率;
LVS的缺点:
1、软件本身不支持正则处理,不能做动静分离,这就凸显了Nginx/HAProxy+Keepalived的优势。
2、如果网站应用比较庞大,LVS/DR+Keepalived就比较复杂了,特别是后面有Windows Server应用的机器,实施及配置还有维护过程就比较麻烦,相对而言,Nginx/HAProxy+Keepalived就简单多了。
转载于:沧海一滴
原文地址:https://www.cnblogs.com/softidea/p/5510137.html
```
3.什么叫网站灰度发布?
答:灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式
AB test就是一种灰度发布方式,让一部用户继续用A,一部分用户开始用B
如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面 来
灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度
4.讲一下Keepalived的工作原理?
答:BACKUP不会抢占MASTER,除非它的优先级更高。当MASTER不可用时(BACKUP收不到通告信息)
多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s),以保证服务的连续性
由于安全性考虑,VRRP包使用了加密协议进行加密。BACKUP不会发送通告信息,只会接收通告信息
5.mysql的innodb如何定位锁问题,mysql如何减少主从复制延迟?
答:
mysql的innodb如何定位锁问题:
在使用 show engine innodb status检查引擎状态时,发现了死锁问题
在5.5中,information_schema 库中增加了三个关于锁的表(MEMORY引擎)
innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系
mysql如何减少主从复制延迟:
如果延迟比较大,就先确认以下几个因素:
-
-
-
从库硬件比主库差,导致复制延迟
-
主从复制单线程,如果主库写并发太大,来不及传送到从库就会导致延迟。更高版本的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
未完待续。。。。