一般电商或供应链系统都有下单和支付环节，用户下单后锁定资源，付款给平台，平台调用供应商接口出票。但现实情况是因为网络抖动的原因，可能会出现供应商出票成功，但是反馈给平台失败的情况。这个时候再次调用出票接口，或者运营人员换其他渠道出票都是会导致重复出票的可能。
image.png
为了解决这个问题，我们在票务系统在设计的时候，需要对每个供应商的出票接口做区分。
1.出票支持重复调用，供应商对同一个订单号不会重复出票
2.不支持重复调用，可能会出现重复出票的问题
分布式锁防重复调用
对于情况2,出票程序需要做并发控制，同一个订单只能调用一次出票接口，不管成功失败，可以通过redis分布式锁，或者zk的方式实现。
image.png
出票详情接口
业界追踪出票状态的通用做法是，由供应商提供一个出票详情接口，让调用方传入订单号来查询此订单的出票状态
1.出票中
2.已出票（票号）
3.未出票
有了这个接口，可以解决两个问题：
1.定期去轮询出票详情，一旦出票成功，即可拿到票号返回给用户。
2.需要人工出票的时候，让票务系统让运营人员使用，如果返回未出票的时候，再换另外的渠道出票。
人工协商
供应商的系统因不能提供出票详情接口。
平台因为服务保证需要在一定时间给用户出票，这种就必须事前走商务层面和供应商约定，因为这个问题导致重复出票，第二天人工确认后是否可以退票，不然运营中必然会出现互相扯皮的问题。
