共计 3294 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章主要介绍“Linux 经典面试题有哪些”的相关知识，丸趣 TV 小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“Linux 经典面试题有哪些”文章能帮助大家解决问题。
1、介绍下自己？
（几乎每家公司首先都会让你做个自我介绍，好像是必修课一样）
回答：此处省略笔者的自我介绍，笔者建议介绍自己的时间不宜过长，3- 4 分钟为宜，说多了面试官会觉得你太啰嗦了。说太少了也不行，那样会让人感觉你的经历太简单了、太空了。
正常情况下，一般你在做自我介绍的同时，面试官这个时候在看你的简历，他需要一边看简历、一边听你介绍自己，如果你说个几句话就把自己介绍完了，他肯定还没缓过神来，对你的映像会减分的。在介绍的同时思维要清晰，逻辑要清楚，*** 是根据你简历上写的经历来介绍，这样可以把面试官的思路带到你这里来，让他思路跟着你走。不要东扯一句，西扯一句。
尽量少介绍自己的性格、爱好（*** 能不说就不说），你可以简单罗列干过几家公司（最多罗列 3 家公司 / 也包含目前所在的公司，注意顺序不要乱），都在那几家公司负责什么工作，都用过什么技术，在着重介绍一下你目前所在的公司是负责哪些工作的，可以稍微详细一点介绍，不要让面试官听着晕头转向的感觉。
2、灰度发布如何实现？
回答：这个问题事后在知乎上看到了一位网友的建议觉得不错，大家可以参考看一下！
仔细考虑一下灰度发布系统要达到哪些目的，基本就能有答案了。需要注意的是，客户端应用（无论 PC 端还是移动端）的灰度发布要比 Web 应用的灰度发布更为复杂，因为应用运行在用户持有的终端上，数据采集和回滚都更为困难（但可采集的数据类型要更加丰富）。
注：本人缺乏移动客户端产品的经验，下述内容可能不适用于移动客户端产品。
我所理解的灰度发布系统，主要任务是从产品用户群中按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的显式反馈（论坛、微博）或隐式反馈（应用自身统计数据），对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
从上述描述可以得出灰度发布系统需要具备的一些要素：
用户标识
用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名 Web 应用比较容易有这个问题）。匿名 Web 应用可采用 IP、Cookie 等，需登录的应用可直接采用应用的帐号体系。
目标用户选取策略
即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，*** 能够提供让用户自主回滚至旧版本的渠道。
对于客户端应用，可以考虑类似 Chrome 的多 channel 升级策略，让用户自主选择采用 stable、beta、unstable channel 的版本。在用户有明确预期的情况下自行承担试用风险。
数据反馈
用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。
新版本回滚策略
当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的 Web 应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。
对于移动客户端，新版本发布成本较高，需要 Appstore、Market 审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成 Web App，会更有利于升级和回滚。（不过苹果对纯 Web App 类的 App 有较强的限制，好像已经不允许在 Appstore 上发布这类应用了？）
新版本公关运营支持
对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。
3、Mongodb 熟悉吗，一般部署几台？
回答：部署过，没有深入研究过，一般 mongodb 部署主从、或者 mongodb 分片集群；建议 3 台或 5 台服务器来部署。MongoDB 分片的基本思想就是将集合切分成小块。这些块分散到若干片里面，每个片只负责总数据的一部分。对于客户端来说，无需知道数据被拆分了，也无需知道服务端哪个分片对应哪些数据。
数据在分片之前需要运行一个路由进程，进程名为 mongos。这个路由器知道所有数据的存放位置，知道数据和片的对应关系。对客户端来说，它仅知道连接了一个普通的 mongod，在请求数据的过程中，通过路由器上的数据和片的对应关系，路由到目标数据所在的片上，如果请求有了回应，路由器将其收集起来回送给客户端。
4、如何发布和回滚，用 jenkins 又是怎么实现？
回答：发布：jenkins 配置好代码路径（SVN 或 GIT），然后拉代码，打 tag。需要编译就编译，编译之后推送到发布服务器（jenkins 里面可以调脚本），然后从分发服务器往下分发到业务服务器上。
回滚：按照版本号到发布服务器找到对应的版本推送
5、Tomcat 工作模式？
回答：Tomcat 是一个 JSP/Servlet 容器。其作为 Servlet 容器，有三种工作模式：独立的 Servlet 容器、进程内的 Servlet 容器和进程外的 Servlet 容器。
进入 Tomcat 的请求可以根据 Tomcat 的工作模式分为如下两类：
Tomcat 作为应用程序服务器：请求来自于前端的 web 服务器，这可能是 Apache, IIS, Nginx 等；
Tomcat 作为独立服务器：请求来自于 web 浏览器；
6、监控用什么实现的？
回答：现在公司的业务都跑在阿里云上，我们 *** 的监控就是用阿里云监控，阿里云监控自带了 ECS、RDS 等服务的监控模板，可结合自定义报警规则来触发监控项。上家公司的业务是托管在 IDC，用的是 zabbix 监控方案，zabbix 图形界面丰富，也自带很多监控模板，特别是多个分区、多个网卡等自动发现并进行监控做得非常不错，不过需要在每台客户机（被监控端）安装 zabbix agent。
7、你是怎么备份数据的，包括数据库备份？
回答：在生产环境下，不管是应用数据、还是数据库数据首先在部署的时候就会有主从架构，这本身就是是属于数据的热备份；
其实考虑冷备份，用专门一台服务器做为备份服务器，比如可以用 rsync+inotify 配合计划任务来实现数据的冷备份，如果是发版的包备份，正常情况下有台发布服务器，每次发版都会保存好发版的包。
总结一下面试注意几点事项：
***，你要对自己的简历很熟悉
简历上的写的技能自己一定要能说出个一二，因为面试官的很多问题都会挑你简历上写的问。比如你简历上写了这么一条技能“熟悉 mysql 数据库的部署安装及原理”。你即然写了这么一条技能，你在怎么不熟悉你也要了解 mysql 的原理，能说出个大概意思。万一面试官问到了你写的这一条，你都答不上来，那在他心里你又减分了，基本上这次面试希望不大。
第二，不要不懂装懂
如果面试官问到你不会的问题，你就说这个不太熟悉，没有具体研究过，千万别不懂装懂，还扯一堆没用的话题来掩饰，这样只会让面试官反感你。
第三，准备充分
竟可能多的记住原理性的知识，一般面试问的多的就是原理。很少问具体的配置文件是怎么配置的。面试前也要了解清楚“职位描述”和“岗位要求”，虽然有时候大多数不会问到岗位要求的问题，但也要了解和熟悉。
第四，面试完后一定要总结
关于“Linux 经典面试题有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注丸趣 TV 行业资讯频道，丸趣 TV 小编每天都会为大家更新不同的知识点。
