忠告
这篇文章只适合2年内工作经验、甚至没有工作经验的朋友阅读。
如果你是2年以上工作经验，请果断划走，对你没啥帮助~
主人公
这篇文章内容来自 「升职加薪」星球星友 的投稿，坐标二线，去年毕业，只有实习经验，无真实项目经验，自学一段时间后，在找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进行可视化和查询。
总结
我个人是觉得上面这些问题比较简单，比较符合“一年工作经验”的求职设定。
为什么这位朋友会觉得无从下手，说不好呢？究其原因还在于缺少真实的项目经历。
要么去花时间恶补项目经验，要么找个明白人针对项目多做模拟面试。
本文转载自微信公众号「 程序员升级打怪之旅」，作者「王中阳Go」，可以通过以下二维码关注。
转载本文请联系「 程序员升级打怪之旅」公众号。
