25届秋招 快手-电商部门-测试开发工程师一面

面试时间：10.9上午11点，总体时长：1小时

总体收获：更加清晰了大厂对于工程师，或者不同业务部门对校招生的一些总体要求，技术栈选型深度。客观反映了目前本人总体知识体系架构能够和大厂招聘需求相匹配，需要提升改进的地方是对技术底层的深入理解，以及所学知识在实际场景中的应用，即理论和实际相结合。

简历中笔者写了一个电扇平台后端开发的一个自学开源项目，刚刚好今天的面试官就是在快手的电商技术开发，在电商这一块就被狠狠拷打了，缓存和数据库的一致性问题被深挖

不过也感谢了这样的一次经历，笔者更加清晰了想要做好程序员，软件开发工程师，数据库是一个绕不过去的问题，在数据库方向上深入绝对能有意想不到的收获，笔者可以尽情安排接下来的学习计划了

接下来复盘整个一面流程（作者面试时并没有录音，单凭记忆力进行总体的复盘）

一上来就是手撕算法：区间闭合，作者秒了，代码功底不够熟练，编码的过程花了些时间

接下来就是拷打项目，和实习经历

Q:这里看到你实习过程中写了数据库幻读的问题，请你讲一讲是什么情况？

A:(真实情况呢是笔者确实遇到了幻读的情况，但是实习当时并没有深入去探究其背后产生的原因，主要是手动在数据库解决了数据报错问题，并且对相关功能进行了限制，幻读到底是什么，为什么产生幻读，以及怎么去解决幻读，接下来做个详细总结)

说起来幻读就不得不提到“三剑客”，脏读，不可重复读，幻读，三个都带有一个读字

脏读：读取未提交数据

不可重复读：前后多次读取，数据内容不一致

幻读：前后多次读取，数据总量不一致

   回顾笔者实习经历中遇到的问题主要是出现了数据导入的问题，笔者在实习中主要负责的是一个薪酬管理系统的开发，在薪酬管理中考勤打卡是薪酬统计的重要数据，但是往往现实情况中考勤不只有：打卡和缺卡的简单两种情况，可能还存在补打卡的情况。而在薪酬管理系统中便存在着一个重要的功能就是补打卡的审核，重新提交打卡的记录，而这个过程是员工进行提交，hr进行重复审核的，但由于hr端的审核往往需要一定的时间，员工有时候又以为提交失败进行重复的补卡打卡提交，这情况下就会出现系统的幻读问题，员工补打卡条数莫名增加(增加到3条，实际上都是同一条缺勤记录)，同时hr的天数审核也会出现超过了一月的天数的状况。

解决办法：幻读是最难解决的一种数据库错误情况。在数据库中的事务隔离级别一般有四种：read uncommitted， read committed， repeatable read， serializable。可串行化是理论上可行的解决方案，但是往往会造成数据库的利用效率低下，导致大量的操作超时和锁竞争，大大降低了数据库的性能。所以笔者在后端上对该功能的提交进行了增加互斥变量的处理，即在hr审核操作的时候，用户不能再对缺勤记录上传，同时只能有一个人在进行读或者写的操作。

Q:(这是面试官听到有意思的了，自己给自己挖坑)那我说如果是极端的情况，你在整个系统中使用的是两个服务器，缺勤提交服务和审核服务部署在了两台不一样的服务器上，而这个时候出现了极端情况，两个请求并发了或者冲突了，你要怎么去解决。

A:（笔者这一块就听懵了，笔者虽然一直在学习互联网相关的技术栈，但其实很少接触了实际的业务场景，所以在面试的当时并不能理解面试官所描述的那个场景）现在回过头来，估计是想问我怎么去解决不同服务器上关联的请求处理先后的问题。

以下的解答，仅凭个人的理解，如果有误多多指正。那在笔者的认知当中比较可行的解决办法就是在后端对服务进行一个处理，先读后写，就是说每一次员工提交缺勤的记录都要在hr处理完上一条的补打卡记录之后才能再次进行提交，将两者同时对数据库进行读写进行一个时间上的分离。另外一种解决办法就是增加一个缓存或者是消息队列。将员工多次提交的补打卡记录进行缓存，首先在缓存中记录下员工的提交记录，并在后面重复提交的数据中比较缓存中的数据，如果是重复的那就丢弃掉，之后每隔一段时间才将记录写入数据库，供hr进行审核。还有就是使用消息队列，hr可以一个个对应提交上来的请求，作为消费者慢慢消化掉生产者发布的消息

Q:说说你对缓存和数据库怎么保持一致性的一些解决方案？(缓存数据库同步策略)

A:(这里笔者又是懵的一笔，之前简单了解过一些，现在一问就记不起来了)

缓存和数据库一致性问题是指在使用缓存系统的同时，如果数据库中的数据发生了变化，缓存中的数据是否能够及时进行更新，保持一致性。

以下是几种常见的解决方案：

1. 读写时更新（Write-through）：在更新数据库时，先更新数据库，然后再更新缓存。这样可以确保缓存中的数据始终与数据库一致。但是由于每次写入都需要更新缓存，会降低写操作的性能。

2. 延迟更新（Write-behind）：在更新数据库时，只更新数据库，延迟更新缓存。这样可以提高写操作的性能，但可能存在一段时间内缓存中的数据与数据库不一致的情况。

3. 手动更新（Cache-aside）：应用程序在读写数据时，先从缓存中查询数据，如果缓存中没有，则从数据库中查询，并将查询结果存入缓存。在更新数据时，先更新数据库，然后再删除缓存中对应的数据。这种方式可以保证数据的一致性，但需要手动编写代码来管理缓存。

4. 自动更新（Cache-invalidation）：在更新数据库时，同时更新缓存中的数据。可以通过触发器、消息队列等方式实现。这种方式可以保证数据的实时一致性，但可能会增加数据库的负载。

5. 周期性刷新（Cache-refresh）：定期清空缓存，然后重新从数据库中加载数据到缓存。可以通过定时任务、定时器等方式实现。这种方式可以保证缓存数据的一致性，但可能存在数据更新的延迟。

Q:即然你做过了电商平台的开发，简历上也写了分布式锁解决超买超卖的问题，不知道你在设计电商平台的时候有没有考虑过库存回流的问题？

A:（又是实际业务场景，也是涉及到笔者的知识盲区了，这个过程面试官重新帮我讲解了一遍这样的一个业务场景，同时也感谢面试官拓展了我整个对电商业务的理解，受用良多）。我大概重新去描述业务场景

在实际应用场景的时候呢，比如卖键盘，库存是有100个的，用户在下单的时候，完成下单的动作，但是并没有没有支付，只是完成抢单(类似双十一之前的一些预售手段)，假设此时今天是11.10号，离双十一当天还有一天时间就开始了预售，下单的数量可能下单了50个。但是这下单的50个并不一定都是会全部卖出去的，那如果双十一当天又有用户下单了51个键盘，这个时候就超库存了，用户并不能成功下单。实际上在真实的仓库里的键盘都还是100个实际上没有变过。也可能仅仅刚刚通过快递发出了20个，实际还剩80个。另一种情况就是在11.10号下单的50个键盘中，并不是所有的订单都能成功去支付，可能是50单，刚好成交了49单。那实际库存剩下的是51件键盘，但是由于订单的原因。双十一当天想要买51件键盘就无法进行下单操作，但实际上来讲库存是足够的。问题的关键是库存量如何在这样的一个复杂过程中做一个合理的修改。面试官给出的思路就要进行一个库存的回流，预存(可能涉及到有关算法，对库存的预测一些问题)。同时对数据库的不同的数据是会做一个状态的管理，冷动态，不可修改态，可能修改态。不同时间段下的同一数据的状态不仅相同。

接下来就是一些八股文的问答：

有些简单的笔者就不再重复了，接下来写都是笔者当时没回答很好，现在复盘总结的

Q:Linux内核的架构

A:Linux内核的架构是模块化的，由许多不同的模块组成。这些模块包括：

1. 进程管理模块：负责进程的创建、调度和管理。
2. 内存管理模块：负责管理系统的物理内存和虚拟内存。
3. 文件系统模块：负责文件的管理和访问。
4. 网络模块：负责网络协议的处理和数据传输。
5. 设备驱动模块：负责与硬件设备进行通信。
6. 文件系统支持模块：提供对不同文件系统格式的支持。
7. 网络协议模块：支持不同的网络协议，如TCP/IP。
8. 中断处理模块：负责处理硬件中断。
9. 系统调用模块：负责提供用户程序与内核之间交互的接口。

Linux内核的架构允许不同的模块可以动态加载和卸载，从而提供了灵活性和可扩展性。这允许用户根据自己的需求定制内核，同时还可以方便地添加新的功能和驱动程序。

Q:简单介绍IO多路复用

A:IO多路复用（IO Multiplexing）是一种用于处理多个IO事件的机制。在传统的IO模型中，每个IO操作通常都需要阻塞等待完成，这会导致程序在等待IO操作完成的同时无法处理其他任务，效率低下。而IO多路复用则可以让一个线程同时监听多个IO事件，一旦有任何一个IO事件就绪，就会通知程序进行处理，这样就能够提高程序的运行效率。

常见的IO多路复用模型有select、poll和epoll。这些模型都提供了一个函数，可以通过一个文件描述符集合来监听多个IO事件。当其中任何一个文件描述符上有可读、可写或出错事件时，函数就会返回，并将就绪的文件描述符返回给程序。程序可以在返回后针对就绪的文件描述符进行相应的操作。

IO多路复用的优点是可以同时监听多个IO事件，可以节省系统资源，提高程序的性能。它适用于需要同时处理多个IO事件的场景，比如服务器端的网络编程。但是需要注意的是，在使用IO多路复用时需要注意处理就绪事件的顺序，以保证程序的正确性。

总结：是一场酣畅淋漓的面试历程，虽然最后结果不如人意，不出意外的挂掉了，但是笔者依旧乐观，很快调整好心态，重新书写了这篇一面面经，希望各位路过的看客，动动手点个赞和关注吧，也是我秋招过程小小的动力。也感谢那个看起来很年轻的面试官，一场面试主要是面试管在输出给了笔者很多收获，也更加明确数据库方向在软件方面的优势，希望自己能够在这方面有意向不到的收获。同时也收获了很多有关实际业务场景的经验，让笔者重新思考了自己为数不多的实习经历，重新梳理了整个项目经历。经历项目更上一层楼，或许面试的意义也在此，能够强迫你不断回顾自身的经历，去做一个体系的输出，但是这样的一些梳理，在平时可能都不会去做专门的梳理，没有合适的一个切入角度，也算是一次很重要的体验，秋招路漫漫继续征战加油