幂等性
以相同的请求调用这个接口一次和调用这个接口多次（重试机制），对系统产生的影响是相同的；
查询接口基本都是幂等；
方案(前端)
1.提交按钮置灰
2.前端在下单页面生成token(可以前端生成,或者后端提供)
3.前端保存一个未确认订单的订单内部表。
方案(后端)
1.保存幂等ID和对于的参数(redis或者去重表(主键去重,唯一索引))
2.状态机判断当前状态和下一步状态的边界范围(需要再次校验幂等ID对应的参数，是否和服务端保存的参数一直,避免被利用检测漏洞)
3.乐观锁判断(很有局限性，无法事务性的更新原子操作多张表,比如积分表和对应的状态机表)
4.主动扫描重复订单，反向通知前端
幂等判断 在哪一层
第一层：APP、H5、PC
第二层：负载均衡设备(Nginx)
第三层：网关层(GateWay)
第四层：业务层(Service)
第五层：持久层(ORM)
第六层：数据库层(DB)
建议在第四层，或者第二层
kafka消息的幂等
TODO。。。
参考
https://juejin.cn/post/6954979098569637896
https://www.cnblogs.com/yaochunhui/p/13993175.html
https://www.cnblogs.com/54chensongxia/p/12598944.html