外部系统对接下单幂等性校验逻辑及事务提交锁表的处理
1、如果下单时，已经存在订单，希望能返回外部订单号和本系统订单号，做幂等处理。
2、希望一个外部订单号，只能对应一个有效的本系统订单号 根据请求参数签名来判断是否是同一请求，根据外部订单号来查询。 如果请求参数签名不同，但是外部订单号已经生成订单，则先做取消操作，再重新下单。 如果相同，则返回当前订单号和订单状态。 下单成功之后，同时返回外部订单号和本系统订单号。 3、取消时，需要同时校验外部订单号和本系统订单号，强一致验证 取消的时候可以记录取消来源，如果是外部取消，可以记录外部取消原因，从而决定是否外部取消是否还需要异步通知取消的结果。 4、如果订单被取消，再次创建，无法创建，期望能够创建。关键原因是：订单数据保存在es中，如果取消到重新下单，然后从es中检查数据，会存在数据的延时性。 1.场景1：如果取消/变更订单事务未提交，而微服务是根据MQ消息来处理，需要延迟3秒再查询（否则数据查不到，比如：取消原因，或查询的上一次的变更记录）。逻辑上而已：正常是接口处理完，事务已提交，然后发送MQ事件。 2.场景2：A系统 >B系统下单，B下单接口未返回的时候，已经收到B系统MQ消息。这样A系统在下单接口（事务未提交）同时又收到MQ消息事件处理（修改表记录），可能存在操作同一张表的情况，这样就会存在锁表。 可以在A系统接收MQ消息前，先查询一下该记录是否存在，如果A系统下单事务未提交（该记录不存在），这样如果不存在，就不处理MQ消息。 存在MQ消息丢失的情况，如果是重要的消息，可以通过反馈机制重新发送。否则不重要的消息，可以在下次推送MQ消息的时候再处理(比如状态推送的消息，多个状态会推送多次的情况)
5、涉及敏感字段可以使用AES加密，接口按字段排序（比如升序）来排序 KEY做md5签名来传输
