后端工程师求职实录：二线城市就业攻略与心得分享_二线城市的程序员的有什么出路(2)

2401_84919661

于 2024-05-13 04:27:44 发布

阅读量611

点赞数 11

分类专栏：程序员文章标签： go 学习面试

本文链接：https://blog.csdn.net/2401_84919661/article/details/138778920

版权

程序员专栏收录该内容

57 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

这篇文章内容来自「升职加薪」星球星友的投稿，坐标二线，去年毕业，只有实习经验，无真实项目经验，自学一段时间后，在找Golang后端开发的工作。

先说下这位朋友的自我面评：

上周在二线城市大概约到了4个面试，自我感觉八股文回答的还可以，因为星球中的面试题没少背。
但是问项目的问题就很垮，或者说是特别垮，因为并没有真实的一年工作经验，有很多东西不知道怎么说，经不起推敲。

我帮他做了面试复盘之后的感受：

基础确实还可以，但是项目经验真的拉胯，很多概念都不清楚。
很重要的一点：很不自信，碰到不会的就怀疑自己，就去恶补。你才一年的工作经验，难道要什么都会吗！？不管你是几年工作经验，有些不是你负责的，你就是不会，这没啥丢人的，不用瞎编，再去恶补，这么搞，总也准备不完。
如果是自信的应聘者，会很明确自己的技能边界在哪里？ 哪些是我负责的，我精通的；哪些是组内其他人负责的，我有打过配合。有哪些是我知道有在用，但是没实操过，但是我能和你聊聊我的实现思路，如果让我做的话，我会这样设计：巴拉巴拉…

复盘面试

下面是结合他“1年工作经验”的情况，整理的一部分面试问题和答案，希望对缺少项目经验的小伙伴们有所启发。

这位朋友在前公司做了一个toB的电商SAAS平台，业务难度不高，而且他实际参与的开发工作并不多，并没有整体视野，也不懂得“开黑”。（咱可以不真实开发，但是和朋友抽烟吹水的时候，也聊聊项目的技术难点，为以后写简历做做准备，避免到时候抓瞎~）

Q1

问：你说对服务进行了拆分，为什么要拆分，拆分的依据是什么？

首先我们的项目不是微服务架构，是中台架构。拆分的依据是站在业务和功能的模块进行拆分，不同的组开发不同的服务，目前我们是拆分成了：商品服务、订单服务、支付服务、消息服务、基础服务。

Q2

问：和前端交互的页面是在哪个模块？

整体项目都是前后端分离的设计，每个模块都会和前端交互，go写服务和接口。

（我就很好奇，这个面试官到底想问啥…）

Q3

问：你说主要负责了订单模块，那这个订单的状态及流转是怎么实现的？

我们是通过以下方式实现：

订单状态定义：首先，需要定义订单的不同状态。常见的订单状态包括：待支付、已支付、待发货、已发货、已完成、已取消等。根据业务需求，我们也可以根据实际情况定义更多的订单状态。
订单流转：订单的状态会随着用户的操作和系统的处理而发生变化。订单的流转通常包括以下几个环节：
- 下单：用户下单后，订单状态为待支付。
- 支付：用户完成支付后，订单状态变为已支付。
- 发货：商家根据库存情况进行发货操作，订单状态变为待发货。
- 物流更新：商家更新物流信息后，订单状态变为已发货。
- 确认收货：用户确认收货后，订单状态变为已完成。
- 取消订单：用户或商家取消订单后，订单状态变为已取消。
状态变更触发：订单状态的变更通常由用户的操作、系统的自动处理或商家的操作触发。例如，用户支付成功后，系统会自动将订单状态更新为已支付；商家发货后，系统会自动将订单状态更新为已发货。
状态流转记录：为了跟踪订单状态的变化，通常会在数据库中记录订单状态的流转历史。每次订单状态发生变化时，会记录相应的状态变更时间和操作人员等信息。
后台管理界面：为了方便商家管理订单，通常会提供一个后台管理界面，用于查看订单列表、处理订单状态变更、更新物流信息等操作。

Q4

问：你说订单完成后接入消息队列异步更新库存销量，那多个客户下单了一个商品，如何保证商品不会多卖，在并发场景下是如何处理的，类似于两个请求同时买一件商品。

在并发场景下，确保商品不会多卖是一个常见的问题。为了解决这个问题，可以采取以下措施：

库存控制：在处理订单时，需要对商品的库存进行控制。在每个订单中，需要检查商品的库存数量是否足够，如果库存不足，则不允许继续下单。这可以通过在数据库中使用事务来实现，确保在并发情况下对库存的准确控制。
锁机制：在并发场景下，可以使用锁机制来保证对库存的原子性操作。例如，可以使用数据库的行级锁或乐观锁来控制对库存的并发访问。这样可以确保在多个请求同时访问库存时，只有一个请求能够成功更新库存，其他请求会等待或进行相应的处理。
消息队列顺序处理：在消息队列中，可以使用顺序处理的方式来确保订单的处理顺序。即使多个客户同时下单了同一个商品，消息队列会按照顺序将订单消息发送给消费者进行处理。这样可以避免并发情况下的竞争条件，确保订单的处理是有序的。
幂等性设计：在处理订单时，可以设计幂等性操作，即使多次处理相同的订单请求，也不会对系统产生副作用。这样可以避免重复处理订单，即使多个请求同时到达，也只会处理一次。

通过以上措施的组合应用，可以在并发场景下保证商品不会多卖。具体的实现方式会根据系统架构和业务需求的不同而有所差异。在设计和实现过程中，需要综合考虑并发性、性能和数据一致性等因素。

更多的解决思路可以看我之前分享的秒杀系统设计