投了那么久简历，终于有人理我了，看看2020年第一波企业运维面试题吧

作者：一盏烛光，贤牛特邀工程师。

防伪码：去时风雨锁寒江 归来落樱染轻裳 山河无恙在我胸 愿君归来若春风

总体来说19年到现在大环境不太好，各行各业都受影响，前段时间听说苏宁开启全员卖货模式，连副总裁都开始在朋友圈卖内裤了，哈哈哈，真是患难见忠臣啊，当然也听说xx二手车强制转岗、降薪，变相裁员。

疫情期间让员工主动离职，不给赔偿，更可恶的是HR私自登录员工系统提交离职报告。我微信里的一个做二手服务器回收的老哥，18年收了两千多万的服务器，去年一半都不到；还有的朋友，单位开不出来工资，生活也受到很大的影响。总而言之，我是比较幸运的，有稳定的工作，有时候也会做一些游戏代练挣一些外快，反正吃饱饭是没问题了，哈哈。

来说说自己的情况吧，2.3号回来就一直在工作，偶尔也会登录Boss直聘投投简历，看看用人单位有哪些技能要求，但是很无奈，要么多半是外包，要么就是已读不回，还有的拿了你的简历就没影了，曾经我手机上唯一的求职软件，我也要卸载了。想想这些年，3584次沟通，投递779份简历，也算是给我的运维经历画上完美的句号了，如图所示：

前一段时间正式开始启用智联招聘，哇，真的是让我眼前一亮，以前不可以和HR沟通，现在也可以沟通了，而且每日签到功能还有各种福利，例如简历超级曝光、优先推荐、offer迷你吸铁石、精美简历模板、超级面霸养成，而且你一投递简历，很快就有HR联系你，总体体验感是非常棒的，我也来说说我找工作的要求吧：

1. 距离超过35km不考虑（时间成本）
2. 外包不考虑（无归属感，福利待遇得不到保障）
3. 规模比较小的不考虑（有可能发不出工资，或者掐网线也是你负责哈哈）
4. 第一轮去直接技术面试，否则免谈，跟你扯半天还不如实打实的来一场技术的碰撞。下图是我在智联招聘盲投5天的结果。

接下来咱们就开始聊技术吧，我把面试题发出来，大家参考一下：

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

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不同步

下面介绍两种解决方法：

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