一次面试经历

大约两个月前,和蚂蚁金服后端大佬约了场技术面试,今天和大伙聊一聊这次面试经历,复盘一下面试现场,个人认为干货还是不少,在此和大家分享,也希望能起到前人栽树后人乘凉的作用。

自我介绍

开场前免不了热身,自我介绍就是热身运动。

基本信息简历上都有我也是一笔带过,重点介绍了一下自己比较擅长的的技能、广泛涉及的技能、做过的比较满意的项目,希望深入研究的技术方向,也提了一句抗压能力比较强。

主要想突出自己较强的做事能力和抗压能力。过程没有掐表,应该不超过五分钟。

面试现场

1、数据库

大佬:最擅长什么技术领域?

我:专攻数据库领域,也涉及一些泛数据库领域的技能。

大佬:最熟悉什么数据库?

我:Oracle、MySQL、SQL server都搞过,过去的一年更专注Oracle领域,目前而言更熟悉Oracle。

大佬:先问你几个Oracle的问题,搭过DG吗?

我:搭过。

大佬:说说Oracle DG架构以及实现原理?

我:Oracle DG架构主要依赖于日志传输服务实现,将主库产生的日志数据传到从库。并更新从库的数据文件。DataGuard支持两种日志传输方式:同步、异步。实现原理上主要讲一下adg模式,这是使用最多的模式。客户端提交一个事务,在Redo Buffer中生成一些redo record 。LGWR从Log buffer中读取redo record并将其写入Online Redo Logs,于此同时等待LNS进程的确认。LNS从Redo Buffer中读取相同的redo record,通过ONS将其传输到从库。RFS接收日志,将其写入Standby Redo Logs,RFS写日志。LGWR无需等待LNS的确认信息。巴拉巴拉说了一通,这个问题我感觉自己回答的还可以。

大佬:RAC环境维护过吗?

我:维护过一些。

大佬:RAC和DG两种架构模式分别适用与什么场景?

我:各自的侧重点不同,DG 侧重于容灾,独立存储,是一种异地容灾的解决方案。RAC侧重于高可用及负载均衡。是本地的高可用集群,多节点共享存储。

大佬:(似乎不太满意,想让我继续补充)

我:……

大佬:谈谈RAC架构?我:这个涉及的比较广泛,你这边重点想了解哪方面呢?

大佬:这个先不聊了,说MySQL吧。

大佬:MySQL有哪几种事务隔离级别?分别解决了什么问题?

我:读未提交,读已提交,可重复读,(有点忘)默认是可重复读。

大佬:MySQL通过MVCC可以解决不可重复读和幻读的问题吗?

我:可以。大佬:实现原理是什么?

我:(卧槽,不太确定的样子)语无伦次凭感觉说了一堆。

大佬:还有吗?我:不好意思,记不太清了。

大佬:在数据库主从同步的情况下,如果从库同步主库的数据延迟比较高,怎么才能在写到主库后立刻能够读取到数据?

我:(解释了主从同步的原理)要保证当写到主库的时候立刻能读到数据,要么就直接配置那个接口读数据的话直接走主库,因为这种写完主库立刻要读取数据的场景比较少,可以做些特殊配置。

大佬:如何保证缓存和数据库的双写一致性?

我:巴拉巴拉…(感觉有点文不对题)。

大佬:你们常用的MySQL高可用架构是什么?如果线上环境发现从节点大幅落后主节点,原因可能有哪些?怎么解决?

我:(这些都是比较常见的问题,可以提前准备)。

大佬:假设有一张用户表,正常的表只能存放大概一千万或是两千万左右的数据。但是阿里巴巴有上亿的用户?你会怎么存储呢?我:可以纵向分割与横向分割。

大佬:那你觉得这里应该纵向还是横向呢?我:纵向(嘴瓢)。

大佬:(很有耐心)可是这样我的数据库还是放不下啊。

我:刚刚说错了,应该是横向分割,把表拆分成多个表然后分布式存储。

大佬:那你觉得我们怎样分割比较合适呢?

我:(锲而不舍)可以根据地域,但是根据用户分布的情况来说,还是会有某些地域访问稠密而有些地域比较稀疏的问题。难道按照用户等级?

大佬:不,用户等级会变动,不合适。你这个阶段暂时没有考虑这个问题

我:……

大佬:如何保证缓存与数据库的双写一致性?

我:(有点不想面了)巴拉巴拉说了一通,感觉不太行的样子。

大佬:SQL优化做的多吗?

我:比较多,几乎每天都会分析一些性能问题。

大佬:如何知道一条SQL预计使用了哪些索引?

我:看执行计划。

大佬:什么是回表?什么是最左前缀匹配原则?

我:巴拉巴拉…


关于优化这块我已经准备好从表设计到存储引擎到字段类型到索引到缓存再到表连接大讲一番,结果没有后续了…。


2、项目经历

大佬:最近做过的最有挑战的项目?

我:(那必须吹一吹)前段时间重点在做数据库运行监控体系,整个项目的实施过程中捋了一边。这块也确实刚刚做完,记得比较清楚。

项目描述:

  1. 深入理解当前客户的痛点问题以及未来的期望,面向客户,建立统一的数据库运行监控体系;
  2. 提供数据库性能分析报告,建立一个周期性的数据库巡检机制,为客户提供有据可依的DB性能趋势分析对比;
  3. 全量分钟级别的sql执行统计信息,提供数据库性能波动快速根因分析(SQL层面);
  4. 通过规范化和标准化,提供一个稳定,可靠,经过验证的数据库交付环境。

项目任务:

  1. 数据库监控体系需求调研、收集各方业务需求、运维平台对接方式及方案评审;
  2. 方案设计:包括数据来源、数据落地格式、数据处理流程、SQL结构、代码规范和约束;
  3. 代码开发及测试:包括代码结构化、配置化、可快速复用、代码边界安全(并发防重,内存和连接防泄露)、易阅读易维护、日志输出格式清晰;
  4. 前端展示部分,包括数据库性能指标大盘展现页面、SQL性能指标展现页面、基础性能展示页面开发及性能趋势基线对比页面;
  5. 客户环境部署(快速部署)。

技术实现:

  1. 巡检代码:Python+SQL
  2. 数据采集库:Oracle+MySQL
  3. 数据加工库:MySQL

3、Linux

大佬:熟悉Linux操作系统?

我:常用的命令还行。

大佬:会写shell吗?
我:写过。

大佬:知道库函数和内核调用吗?

我:内核调用是指进入内核态然后执行指令然后再回到用户态吗?

大佬:对

我:我知道的大概就这么多了,只了解一些概念上的内容。

大佬:查看进程常用什么命令?

我:ps命令。

大佬:查看系统资源常用什么命令?

我:sar、top、iostat

大佬:你在做系统监控时常用的监控指标有哪些?

我:主要包括CPU、load、内存、磁盘、IO、网络、内核参数、端口采集、DNS解析。

大佬:比如说采集CPU、IO指标,你从哪里采集的?

我:CPU通过采集/proc/stat就可以,参考sar命令的统计输出。IO采集/proc/diskstats.

大佬:buffer和cache如何区分?

我:buffer和cache都是内存中的一块区域,当CPU需要写数据到磁盘时,先把数据存进buffer,然后CPU去执行其他任务,buffer中的数据会定期写入磁盘;当CPU需要从磁盘读入数据时,可以把即将用到的数据提前存入cache,CPU直接从Cache中拿数据要快的多。

大佬:如何实时查看网卡流量为多少?如何查看历史网卡流量?

我:安装sysstat包,使用sar命令查看

大佬:说说你对Linux标准大页和透明大页的认识?

我:讲了一下两者的优缺点,两者最大的区别在于标准大页管理是预分配的方式,透明大页管理是动态分配的方式。

大佬:Linux进程如何有效避免OOM(out-of-memory)?

我:1、设置参数/proc/PID/oom_adj为-17(为什么是-17而不是其他数值,这是由Linux内核定义的);2、修改内核参数禁止OOM机制(vm.panic_on_oom=1),1表示关闭,默认为0表示开启。

大佬:从数据库到服务器到网络存储,有全链路定位故障问题的能力吗?

我:有过类似的案例,然后巴拉巴拉讲了一个以前的例子。

4、Spring

大佬:我看你用过这个Spring啊。

我:只是接触过。

大佬:在Spring事务中执行多条SQL语句,是对应多个和一个数据库连接?

我:一个。

大佬:既然是一个连接,Spring前后执行多条SQL时,如何保证当前线程获取到同一个连接?

我:(这不扯犊子么)不太清楚。

大佬:为什么我们要使用Spring呢?我:(我来之前他们就在用了啊)spring是一个庞大的框架,它封装了很多成熟的功能能够让我们无需重复做相同的工作。

大佬:没了?

我:(我不是搞这个的啊)不好意思,我多Spring了解有限。

5、JVM

大佬:你了解JAVA虚拟机吗?

我:(如果你通知我明天面试,我就了解了)不好意思,这一块知识我不熟悉,但是我很愿意去了解。

6、分布式

大佬:接触过分布式数据库吗?

我:接触过一些,了解不太懂,工作场景使用的较少。

大佬:ok。那你觉得分布式的话会遇到什么问题呢?

我:那就是经典的CAP问题了。没有数据库能够同时满足这三个问题

大佬:那你能具体解释一下CAP代表什么吗?

我:(有点懵)Consistency?Atomic?P…Persistency???

大佬:…

大佬:你们系统中的分布式锁是如何实现的?

我:redis。

大佬:使用redis锁实现分布式会有什么问题?
我:……

大佬:redis集群如何扩容?

我:巴拉巴拉。

大佬:你在工作中使用redis遇到过什么问题吗?

我:比较常见的有热Key。

大佬:你怎么解决的?

我:(早有准备)。

7、其他

最后和大佬聊聊工作状况,下一步的打算。工作地点北京杭州二选一。

END

以上就是我面试的全部经历了,希望对你有帮助。

觉得本文有用,请转发、点赞或点击“在看”聚焦技术与人文,分享干货,共同成长更多内容请关注“数据与人”

为您推荐

发表评论

您的电子邮箱地址不会被公开。