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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

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

Q4

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

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

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

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

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

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

问：一个场景，用户购买商品，写入数据库到一半时崩了，如何保证正确写入？

在处理用户购买商品的场景中，确保正确写入数据库是非常重要的。为了保证数据的完整性和一致性，可以采取以下措施：

1. 使用事务：将写入数据库的操作放在一个事务中。事务是一组原子性的操作，要么全部成功提交，要么全部回滚。在购买商品的过程中，可以将相关的数据库操作（如创建订单、扣减库存、记录交易日志等）放在同一个事务中。如果在事务执行过程中发生错误，可以回滚事务，确保数据的一致性。
2. 数据库锁定：在写入数据库时，可以使用数据库的锁机制来保证数据的正确写入。例如，可以使用行级锁或表级锁来控制并发访问，避免多个用户同时修改同一条数据。这样可以确保在写入过程中不会发生数据冲突。
3. 异常处理和重试：在写入数据库时，需要进行异常处理，并在发生错误时进行适当的重试。例如，可以捕获数据库操作的异常，并进行回滚和重试操作，直到数据成功写入数据库为止。
4. 数据备份和恢复：定期进行数据库备份，并确保备份的完整性和可靠性。如果在写入过程中发生崩溃或数据丢失，可以通过备份进行数据恢复，以保证数据的正确性。
5. 监控和报警：设置数据库监控和报警系统，及时发现数据库异常和故障，并采取相应的措施进行修复。这样可以减少数据丢失的风险，并及时处理潜在的问题。

Q12

问：在你们的项目中，哪种场景下可以用协程？

1. 并发请求：在电商项目中，可能需要同时向多个服务发送请求，如商品库存查询、价格计算、物流查询等。使用协程可以并发地发送这些请求，并在所有请求完成后进行结果的汇总和处理，提高请求的效率和响应速度。
2. 并发数据处理：电商项目通常需要对大量的数据进行处理，如订单数据、用户数据等。使用协程可以并发地处理这些数据，提高数据处理的效率。例如，可以使用协程并发地读取和写入数据库，进行数据的批量插入或更新。
3. 异步任务处理：电商项目中可能存在一些耗时的任务，如发送邮件、生成报表、处理图片等。使用协程可以将这些任务转化为异步操作，提高系统的并发能力和响应性能。例如，可以使用协程异步地处理订单的邮件通知，而不会阻塞主线程的执行。
4. 并发库存更新：在电商项目中，库存的更新是一个重要的操作。使用协程可以并发地更新库存，避免因为库存更新操作的串行执行而导致的性能瓶颈。通过使用协程，可以同时处理多个库存更新请求，提高库存更新的效率。

Q13

问：linux命令操作会吗，平时操作日志是怎么查，在db上还是有专门的日志库？

管理后台的操作日志在管理后台能直接查看，有表进行记录。

错误日志和请求日志是通过查看log日志的方式查看的：比如，tail -f xxx.log

另外补充一下：

• cat：用于查看文件的内容，可以使用cat filename命令来查看日志文件的内容。
• tail：用于查看文件的末尾内容，可以使用tail filename命令来实时查看日志文件的最新内容。
• grep：用于在文件中搜索指定的字符串，可以使用grep pattern filename命令来搜索日志文件中的特定内容。
• less：用于分页查看文件的内容，可以使用less filename命令来逐页查看日志文件的内容。

在实际应用中，日志通常会记录在文件中，可以通过上述命令来查看和分析日志。日志文件的位置和命名方式可能因不同的应用程序和配置而有所不同。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

需要这份系统化的资料的朋友，可以添加戳这里获取**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！