共计 4366 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章内容来自「升职加薪」星球星友 的投稿，坐标二线，去年毕业，只有实习教训，无实在我的项目教训，自学一段时间后，在找 Golang 后端开发的工作。
先说下这位敌人的自我面评：
- 上周在二线城市大略约到了 4 个面试，自我感觉八股文答复的还能够，因为星球中的面试题没少背。
- 然而问 我的项目的问题就很垮，或者说是特地垮，因为并没有实在的一年工作教训，有很多货色不晓得怎么说，经不起斟酌。
我帮他做了面试复盘之后的感触：
- 根底的确还能够，然而我的项目教训真的拉胯，很多概念都不分明。
- 很重要的一点：很不自信，碰到不会的就狐疑本人，就去恶补。你才一年的工作教训，难道要什么都会吗！？不论你是几年工作教训，有些不是你负责的，你就是不会，这没啥丢人的，不必瞎编，再去恶补，这么搞，总也筹备不完。
- 如果是自信的应聘者，会很明确本人的技能边界在哪里？ 哪些是我负责的，我精通的；哪些是组内其他人负责的，我有打过配合。有哪些是我晓得有在用，然而没实操过，然而我能和你聊聊我的实现思路，如果让我做的话，我会这样设计：巴拉巴拉 …
复盘面试
上面是联合他“ 1 年工作教训 ”的状况，整顿的一部分面试问题和答案， 心愿对短少我的项目教训的小伙伴们有所启发。
这位敌人在前公司做了一个 toB 的电商 SAAS 平台，业务难度不高，而且他理论参加的开发工作并不多，并没有整体视线，也不懂得“开黑”。（咱能够不实在开发，然而和敌人抽烟吹水的时候，也聊聊我的项目的技术难点，为当前写简历做做筹备，防止到时候抓瞎~）
Q1
问：你说对服务进行了拆分，为什么要拆分，拆分的根据是什么？
首先咱们的我的项目不是微服务架构，是中台架构。拆分的根据是站在业务和性能的模块进行拆分，不同的组开发不同的服务，目前咱们是拆分成了：商品服务、订单服务、领取服务、音讯服务、根底服务。
Q2
问：和前端交互的页面是在哪个模块？
整体我的项目都是前后端拆散的设计，每个模块都会和前端交互，go 写服务和接口。
（我就很好奇，这个面试官到底想问啥 ….）
Q3
问：你说次要负责了订单模块，那这个订单的状态及流转是怎么实现的？
咱们是通过以下形式实现：
- 订单状态定义：首先，须要定义订单的不同状态。常见的订单状态包含：待领取、已领取、待发货、已发货、已实现、已勾销等。依据业务需要，咱们也能够依据理论状况定义更多的订单状态。
订单流转：订单的状态会随着用户的操作和零碎的解决而发生变化。订单的流转通常包含以下几个环节：
- 下单：用户下单后，订单状态为待领取。
- 领取：用户实现领取后，订单状态变为已领取。
- 发货：商家依据库存状况进行发货操作，订单状态变为待发货。
- 物流更新：商家更新物流信息后，订单状态变为已发货。
- 确认收货：用户确认收货后，订单状态变为已实现。
- 勾销订单：用户或商家勾销订单后，订单状态变为已勾销。
- 状态变更触发：订单状态的变更通常由用户的操作、零碎的主动解决或商家的操作触发。例如，用户领取胜利后，零碎会主动将订单状态更新为已领取；商家发货后，零碎会主动将订单状态更新为已发货。
- 状态流转记录：为了跟踪订单状态的变动，通常会在数据库中记录订单状态的流转历史。每次订单状态发生变化时，会记录相应的状态变更工夫和操作人员等信息。
- 后盾治理界面：为了不便商家治理订单，通常会提供一个后盾治理界面，用于查看订单列表、解决订单状态变更、更新物流信息等操作。
Q4
问：你说订单实现后接入音讯队列异步更新库存销量，那多个客户下单了一个商品，如何保障商品不会多卖，在并发场景下是如何解决的，相似于两个申请同时买一件商品。
在并发场景下，确保商品不会多卖是一个常见的问题。为了解决这个问题，能够采取以下措施：
- 库存管制：在解决订单时，须要对商品的库存进行管制。在每个订单中，须要查看商品的库存数量是否足够，如果库存有余，则不容许持续下单。这能够通过在数据库中应用事务来实现，确保在并发状况下对库存的精确管制。
- 锁机制：在并发场景下，能够应用锁机制来保障对库存的原子性操作。例如，能够应用数据库的行级锁或乐观锁来管制对库存的并发拜访。这样能够确保在多个申请同时拜访库存时，只有一个申请可能胜利更新库存，其余申请会期待或进行相应的解决。
- 音讯队列程序解决：在音讯队列中，能够应用程序解决的形式来确保订单的解决程序。即便多个客户同时下单了同一个商品，音讯队列会依照程序将订单音讯发送给消费者进行解决。这样能够防止并发状况下的竞争条件，确保订单的解决是有序的。
- 幂等性设计：在解决订单时，能够设计幂等性操作，即便屡次解决雷同的订单申请，也不会对系统产生副作用。这样能够防止反复解决订单，即便多个申请同时达到，也只会解决一次。
通过以上措施的组合利用，能够在并发场景下保障商品不会多卖。具体的实现形式会依据零碎架构和业务需要的不同而有所差别。在设计和实现过程中，须要综合思考并发性、性能和数据一致性等因素。
更多的解决思路能够看我之前分享的 秒杀零碎设计
Q5
问：这个我的项目是从 0 到 1 还是曾经有残缺的我的项目在失常迭代？
不是从 0 到 1 的，这个我的项目之前是 PHP 开发的。咱们应用 Go 语言进行重写的。
Q6
问：用户人群是什么样的，用户量是多少?
咱们是一个 Saas 零碎，我接触到的客户是 B 端客户，会和技术支持一起解决一些客户反馈的问题和需要。
B 端用户大略十几家在对接，B 端用户对应的 C 端用户不是很分明。因为咱们我的项目是反对私有化独立部署的，
Q7
问：订单会做日志吗，比如说每天成交了多少订单。
会做长久化存储，存储到 MySQL 中；也会做日志，公司有负责数据分析的共事。大略几千单吧，我次要是负责商品核心的，订单这部分不是很理解。
Q8
问：你们数据库是本人保护吗，存储 phone 字段用什么类型？
是的，咱们能够保护本人本地开发的数据库；如果要批改测试库和正式库的字段信息，要向领导申请。
phone 是 11 位的 varchar
Q9
问：平时开发过程中是和数据库直连吗，还是两头有缓存层吗？
有直连的也有退出 redis 缓存层的，不同的场景解决形式不一样。
比方我负责的商品核心，热点商品接口是会用缓存的。
商品可售状态就不会走缓存，而是间接查询数据库，依据用户抉择的商品规格和所在地间接查询数据库。
Q10
问：你用说 redis 缓存，什么时候查库呢？
看场景和具体的需要，就像后面提到的：
商品可售状态就不会走缓存，而是间接查询数据库，依据用户抉择的商品规格和所在地间接查询数据库。
Q11
问：一个场景，用户购买商品，写入数据库到一半时崩了，如何保障正确写入？
在解决用户购买商品的场景中，确保正确写入数据库是十分重要的。为了保证数据的完整性和一致性，能够采取以下措施：
- 应用事务：将写入数据库的操作放在一个事务中。事务是一组原子性的操作，要么全副胜利提交，要么全副回滚。在购买商品的过程中，能够将相干的数据库操作（如创立订单、扣减库存、记录交易日志等）放在同一个事务中。如果在事务执行过程中产生谬误，能够回滚事务，确保数据的一致性。
- 数据库锁定：在写入数据库时，能够应用数据库的锁机制来保证数据的正确写入。例如，能够应用行级锁或表级锁来管制并发拜访，防止多个用户同时批改同一条数据。这样能够确保在写入过程中不会产生数据抵触。
- 异样解决和重试：在写入数据库时，须要进行异样解决，并在产生谬误时进行适当的重试。例如，能够捕捉数据库操作的异样，并进行回滚和重试操作，直到数据胜利写入数据库为止。
- 数据备份和复原：定期进行数据库备份，并确保备份的完整性和可靠性。如果在写入过程中产生解体或数据失落，能够通过备份进行数据恢复，以保证数据的正确性。
- 监控和报警：设置数据库监控和报警零碎，及时发现数据库异样和故障，并采取相应的措施进行修复。这样能够缩小数据失落的危险，并及时处理潜在的问题。
Q12
问：在你们的我的项目中，哪种场景下能够用协程？
- 并发申请：在电商我的项目中，可能须要同时向多个服务发送申请，如商品库存查问、价格计算、物流查问等。应用协程能够并发地发送这些申请，并在所有申请实现后进行后果的汇总和解决，进步申请的效率和响应速度。
- 并发数据处理：电商我的项目通常须要对大量的数据进行解决，如订单数据、用户数据等。应用协程能够并发地解决这些数据，进步数据处理的效率。例如，能够应用协程并发地读取和写入数据库，进行数据的批量插入或更新。
- 异步工作解决：电商我的项目中可能存在一些耗时的工作，如发送邮件、生成报表、解决图片等。应用协程能够将这些工作转化为异步操作，进步零碎的并发能力和响应性能。例如，能够应用协程异步地解决订单的邮件告诉，而不会阻塞主线程的执行。
- 并发库存更新：在电商我的项目中，库存的更新是一个重要的操作。应用协程能够并发地更新库存，防止因为库存更新操作的串行执行而导致的性能瓶颈。通过应用协程，能够同时解决多个库存更新申请，进步库存更新的效率。
Q13
问：linux 命令操作会吗，平时操作日志是怎么查，在 db 上还是有专门的日志库？
治理后盾的操作日志在治理后盾能间接查看，有表进行记录。
谬误日志和申请日志是通过查看 log 日志的形式查看的：比方，tail -f xxx.log
另外补充一下：
- cat：用于查看文件的内容，能够应用 cat filename 命令来查看日志文件的内容。
- tail：用于查看文件的开端内容，能够应用 tail filename 命令来实时查看日志文件的最新内容。
- grep：用于在文件中搜寻指定的字符串，能够应用 grep pattern filename 命令来搜寻日志文件中的特定内容。
- less：用于分页查看文件的内容，能够应用 less filename 命令来逐页查看日志文件的内容。
在理论利用中，日志通常会记录在文件中，能够通过上述命令来查看和剖析日志。日志文件的地位和命名形式可能因不同的应用程序和配置而有所不同。
此外，有些应用程序会将日志记录在数据库中，以便更不便地进行查问和剖析。这些应用程序通常会提供专门的日志库或工具，用于治理和查问日志数据。例如，Elasticsearch、Logstash 和 Kibana（ELK Stack）是一套罕用的日志治理和剖析工具，能够将日志数据存储在 Elasticsearch 中，并应用 Kibana 进行可视化和查问。
总结
我集体是感觉下面这些问题比较简单，比拟合乎“一年工作教训”的求职设定。
为什么这位敌人会感觉无从下手，说不好呢？究其原因还在于短少实在的我的项目经验。
要么去花工夫恶补我的项目教训，要么找个明白人针对我的项目多做模仿面试，这才是找工作的正途。可别想着走捷径。
一起提高
独行难，众行易，一个人刻意练习是孤单的。
欢送退出咱们的小圈子，一起刻意练习，结伴成长！
微信号：wangzhongyang1993
公众号：程序员升职加薪之旅
也欢送大家 关注我的账号 ，点赞、留言、转发。 你的反对，是我更文的最大能源！
