采购流程梳理与解决方案 第1篇
在分析采购业务中的幂等性问题前，我们先了解下什么是接口幂等性问题呢？比如说我在某电商网站上选中了一个商品后提交订单，后台当然会暴露一个接口来被调用创建订单，那么正常情况下调用一次接口，后台就创建一个订单了，如下图所示：
对于以上重复创建订单的情况肯定是不能接受的；如果说重复创建几个订单对于用户来说可能感触不深，那么接下来就是付款的操作了，如果用户在付款操作时，调用扣款的接口也因为网络延迟重试，正常情况下只会扣一次钱，结果接口被重试了好几次导致用户的钱多次扣款，这样麻烦就大了。
一个接口如果不做一些校验机制直接让它裸奔执行的话，就会面被临重复调用、接口逻辑重复被执行的糟糕结果。接口幂等性的保障，简单来说就是在调用接口时会判断下接口之前有没有被调用过，如果没有被调用肯定是可以执行的，倘若发现接口已经被调用过了，那么此时就得想方设法不能让同一逻辑被重复执行，这里处理的方式有很多种，比如方法如果没有返回值就直接return，或者直接报错都是可以的，简而言之就是接口要具备识别出已经执行过一次的逻辑就不能被重复执行了，如上面的创建订单案例，就算网络延迟重试了，也只允许创建一个订单，付款时也只允许扣款一次。
采购流程梳理与解决方案 第2篇
电商系统的核心业务简单来说就是销售商品，一开始仓库里当然什么货都没有，要做的第一件事就是采购货物。
首先采购员或者说有采购需求的部门的人，他们会填写并提交采购单发起采购请求，如果采购需求不合理或者采购超出预算等原因，采购单就会被驳回重新修改，如下图所示：
当采购需求、预算等条件都符合采购条件时，采购单就被审核通过了，这里审核采购单后就会触发调度中心的逻辑，调度中心会在内存中基于采购单的信息创建一个采购入库单，此时在调度中心中创建的采购入库单暂时还没有落库，仅仅是在内存层面创建采购入库单，如下图所示：
紧接着调度中心调用WMS的接口，把创建好的采购入库单传递给WMS，在WMS中才会把采购入库单给保存到数据库中，同时采购单的状态会被更新为待入库的状态。
目前采购中心有一张审核通过的采购单，WMS中有一张与之对应的采购入库单，负责采购的人员看到有一张审核通过的采购单，就会根据采购单信息去找供应商进货，而在仓库的工作人员同时也在等着供应商将货物运到仓库里，如下图所示：
仓库工作人员可能等了几天后，终于等到供应商把货物运送到仓库中了，仓库中的工作人员这时打开系统中的采购入库单，一边把运来的货物上架到货物上，一边把具体什么货物、时间、上了几件、上到那个位置这些信息同时给填写到采购入库单的对应上架条目信息栏当中。
当解决完货物的问题后，仓库管理人员就会审批通过采购入库单，这时采购入库单的审批操作在电商系统后台系统中触发的操作比较多了：
一方面要更新下采购单和采购入库单的状态，因为当前货物已经入库检验完毕，所以采购入库单状态从待入库状态流转为已入库状态，同时采购单的状态也从待入库状态流转为已入库状态，采购单和采购入库单的状态在关键的节点出要联动着更新。
另一方面就是库存信息的更新，这里的库存信息就涉及到了WMS的库存、调度中心的库存以及库存中心的库存。如果电商系统是第一次使用，WMS、调度中心以及库存中心对应的库存信息在最开始都是没有的，都是先要通过采购入库单的信息先创建出来的，比如库存中心需要创建商品库存信息，调度中心和WMS需要创建商品库存信息、商品货位库存信息和商品货位库存明细信息。
这里比较容易混淆的，就是在调度中心以及WMS中商品货位库存明细的信息是从哪来的，还记得当货物送到仓库时不是要把每件货物都一一上架吗，而之前已经将上架的详细信息填写到采购入库单上的上架条目中了，所以采购入库单上架条目就是货位库存明细信息的数据来源，如下图所示：
订单状态更新以及库存信息更新完成之后，最后还会发送请求到财务中心，根据审核通过的采购入库单信息创建一个采购结算单，此时整体的业务状态就是等待财务付款给供应商了，所以采购入库单、采购单的状态这里也联动着同步流转为待结算状态，如下图所示：
最后财务这边会审核采购结算单信息，看下采购了哪些商品需要付多少钱，确认无误后，会按月或者按季度审批后给供应商打款，采购结算单、采购入库单以及采购单的状态此时都会同时联动流转为已完成状态，至此整个采购链路的业务算是完成了，如下图所示：
采购流程梳理与解决方案 第3篇
对采购业务中存在的接口幂等性问题分析，就结合上图标好的接口执行二十三个步骤一步步分析：
步骤1：创建采购单，这里一般不需要考虑幂等性问题，因为这里创建采购单是人为的在创建，并发量很低，并且就算重复创建采购单，后续审核的人也会及时发现。
步骤2~步骤4：这些操作都只是更新一下采购单的状态，只涉及到一个状态字段的更新，更新多次和更新一次的效果都是一样的，按照这样的思路，以上图中只要涉及到更新的操作，都不需要考虑接口幂等性的问题了。
步骤5：这里是在内存中基于采购单创建采购入库单，可以忽略。
步骤6：这里就会把在调度中心中，基于内存创建好的采购入库单给保存到WMS中的数据库中，这里就涉及到了数据库的新增操作，如果不加以控制，接口重复调用就会创建多个采购入库单，导致一个采购单对应多个采购入库单，这样是不合理的。
步骤7~ 步骤12：这些操作和2~4一样，只是简单的状态更新可以不用考虑，其中步骤8主要是线下操作。
步骤13、步骤14、步骤15：这三步操作都会更新库存的数量，这里的库存数量更新涉及到库存的计算，并不是简单像步骤2~步骤4和步骤7~步骤12一样只是简单更新一个字段。不管是库存中心、调度中心还是WMS，每次进来一批货物，对应的库存数量都会被累加的。
步骤16：审核采购入库单时，同时也会触发调用财务中心接口生成采购结算单，这里也存在着和第6步一样的数据库层面重复新增的问题，创建采购结算单接口重复被调用，可能就会导致一个采购入库单对应多个采购结算单，所以这里同样也有接口幂等性问题。
步骤 17~步骤23：这些操作也只涉及一个状态字段的更新，接口被重复调用也没关系，无需考虑幂等性问题。
另外我们可以发现，往往是审核操作容易触发后续一系列的问题，比如图中采购单审核可能导致重复创建采购入库单问题、采购入库单审核可能导致库存信息重复累计的更新问题，所以我们可以尝试在审核操作做接口幂等性的保障，这样可以在源头上保证后续的操作不会重复执行。
最后采购业务流程需要做接口幂等性保障的点如下图所示：