01_如何保证创建订单接口的幂等性？

几乎所有人都有过网购的经历，我们会打开电商网页，浏览商品，添加至购物车，接着选中几款本次需要购买的商品，提交订单。服务端接收到请求后，会为本次用户操作，创建一份独一无二的订单。

上述过程看起来非常美好，但实际上很可能出现各种问题。比如，用户在点击提交订单时，由于网络原因，导致请求没有正常的发送到服务端，在这个时候，用户通常会比较愤怒，接着反复的点击提交订单按钮，直到服务端响应结果。这就造成了多次调用了创建订单的接口。再比如，后端使用了网关服务，用户通过前端把请求发送至网关，由网关把请求转发到订单服务，在网络卡顿的情况下，由于执行报错或者超时等等，导致网关重复的调用了订单服务，这在分布式系统，尤其是使用spring cloud很常见。

这个问题如果没有处理好，要么是用户发现自己重复创建了多份订单，不知道应该支付谁。要么是用户本来就想下多份订单，如果你把它删除了，那用户岂不是付不了款，最终给公司带来损失。

那么该如何解决这个问题呢？无论是京东，还是淘宝，当用户在购物车内选择了商品后，都不能直接提交订单，而是要进入"订单结算页"，在这个页面内，可以根据当前的时间、用户的id、以及随机数，制作一个全局唯一的id，这个制作的过程可以由前端完成，也可以由后端完成。用户确认购买商品的无误后，在发起"提交订单"时，必须携带刚才生成的id，订单中心接收到请求后，对这个id进行去重，就可以保证创建订单接口的幂等性了。

也许你觉得问题到这里已经结束了，不不不，仍然问题存在。我们该怎样对id去重呢？

去重的做法有很多，比如创建去重表、业务表加唯一索引、状态机、版本号控制等等，如果直接依赖关系型数据库，很有可能导致数据库存不下这么多id吧？如果你选择使用Redis来做，也会有问题，因为这种纯内存的存储，一来是内存限制了存储大小，二来假如你单台Redis存的过多，然后你搞了Redis Cluster之类的集群模式，一旦做RDB的全量复制，网络流量会不堪重负。

所以还是得找一个支持集群，支持内存和磁盘文件混合使用的分布式存储组件。目前看来Tair和Mongodb都可以。