企业实战之微服务下的幂等设计

五、token机制

token方式的流程，上一张图，比较清晰

六、token机制缺点

小伙伴们有没有发现，业务请求每次请求，都会有额外的请求（一次获取token请求、判断token是否存在的业务）。其实真实的生产环境中，1万请求也许只会存在10个左右的请求会发生重试，为了这10个请求，我们让9990个请求都发生了额外的请求。（当然redis性能很好，耗时不会太明显）

七、乐观锁机制

关于乐观锁老顾之前也讲过，大家可以去查阅。乐观锁这里解决了计算赋值型的修改场景。我们对之前的sql语句进行修改。

update user set point = point + 20, version = version + 1where userid=1 and version=1

加上了版本号后，就让此计算赋值型业务，具备了幂等性。

八、乐观锁机制缺点

就是在操作业务前，需要先查询出当前的version版本

九、唯一主键机制

这个机制是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键，之前老顾的文章也介绍过分布式唯一主键ID的生成，可自行查阅。

如果是分库分表场景下，路由规则要保证相同请求下，落地在同一个数据库和同一表中，要不然数据库主键约束就不起效果了，因为是不同的数据库和表主键不相关。

因为对主键有一定的要求，这个方案就跟业务有点耦合了，无法用自增主键了。

十、去重表机制

这个方案业务中要有唯一主键，这个去重表中只要一个字段就行，设置唯一主键约束，当然根据业务自行添加其他字段。主要流程上图

上面的主要流程就是把唯一主键插入去重表，再进行业务操作，且他们在同一个事务中。这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。

这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。

这个方案也是比较常用的，去重表是跟业务无关的，很多业务可以共用同一个去重表，只要规划好唯一主键就行了。

十一、总结

上面介绍了一些幂等方案，小伙伴们根据自身的业务进行选择，尽量不要让系统变的复杂，所以推荐唯一主键和乐观锁方式，因为实现比较简单。好了，今天就介绍到这里，谢谢大家！！！