我写的 C2C NFT 交易市场项目已经上线了，已经稳定运行了一段时间了。这也是对我来说非常有成就感的事情，所以准备详细的介绍下整个项目的交易流程的从0到1的设计和实现。后端项目使用的技术栈是 Node.js + TypeScript + Nest.js + MySQL + Redis + kubenetes。消息队列使用的是 Redis 的 Stream 实现的。
交易流程图的梳理
因为我经验不多，而且业务相对很重要不容出错，所以开发前我首先是将流程图画了出来，这样可以帮助我更清晰的梳理整个业务流程的逻辑，也可以更好的发现业务流程中的 Bug.
业务的完整逻辑主要体现在时序图里面，流程图描述的是时序图中的关键步骤的具体实现。
上架NFT
上架NFT时序图
上架NFT创建卖单流程图
上架NFT流程图
上架NFT消息处理流程图
下单购买NFT
下单购买NFT流程时序图
创建买单流程图
创建第三方支付订单流程图
第三方支付回调流程图
发货消息处理流程图
下架NFT
下架NFT流程时序图
下架NFT流程图
下架NFT消息处理流程图
卖单和买单状态变更图
卖单状态变更图
买单状态变更图
一些需要注意的地方
- 订单状态的变更，需要根据状态变更图来进行，在修改订单状态的时候可以使用乐观锁来保证修改订单状态不会出现并发问题。
- 在服务运行的过程中难免会出现异常，甚至系统突然的宕机，这些情况会引起一些异常问题，比如：
- 没有接收到支付方的支付完成回调信息
- 用户付款发货后，上架NFT和下架NFT等操作在链上执行成功但是系统宕机订单状态没有修改成功
面对前两个问题我们需要引入一些机制来自动处理这些异常订单问题。问题1的话比较好解决，如果没有收到支付方的支付完成回调信息，那么我们的订单状态一定还是在付款中的状态，那么我们可以在订单超时未支付自动取消的时候去查询第三方支付平台的订单状态，如果订单状态是已支付，那么就可以执行发货操作。面对问题2这我们需要在执行上链操作前记录下这笔交易的 transaction hash，这样就可以通过这个 transaction hash 来查询链上的交易状态。如何在发送交易前记录 transaction hash，可以参考我以前写的这篇如何在上链前确定一笔交易的transaction hash。
目前项目业务量还不大也就5万个用户左右，所以在用户量大了以后会有什么问题还不清楚，后面有问题再来补充。