分布式那些事儿
分布式那些事儿
分布式那些事儿
你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。
关于幂等性问题
关于幂等性问题，不一定是只有分布式项目才存在，其实普通的单体应用也会存在，有时候前端或者移动端 对同一接口进行重复点击（参数完全一致），对于数据库增删改情况会出现幂等性问题，查询功能不会存在。
幂等性：多次操作与第一次操作是完全一致。
其实并不一定所有的接口都需要保证幂等性，例如 对结果没有什么影响这种情况下，不保证幂等也没关系，如点赞数等，但是有的接口必须要保证幂等性，如支付接口等。对于统一操作必须要保证幂等性，否则会出现重复消费等问题。
注意：有一点儿需要注意一下：幂等性不一定只是同一接口多次访问，例如订单支付功能，一笔订单只允许支付一次，不可以执行多次。不管时间间隔多久。这也是保证支付的幂等性。
幂等性与接口重复提交问题
对于幂等性与接口重复提交，这两个概念属于剪不断理还乱的。
大部分重复调用接口问题不大，做一下更新前判断即可，例如注册用户这个接口，如果用户重复提交，在后台进行处理的时候先对数据库进行查询操作，如果已经存在就给他返回错误信息。因为前一个操作已经执行，这个不会产生什么影响。删除接口这个其实不处理也无所谓，都是进行更改状态值，或者真删除。关于更新接口，这一块儿根据业务逻辑进行考虑是否需要增加幂等性判断，如果只是更改为某个值，这个无所谓，但是如果加1或者减1等操作，这个就需要进行考虑一下是否需要处理幂等性，该解决方法也比较简单，可以在该操作的时候，让前端或者后台给生成一个类似于订单号的值一样，后台可将该值保存在redis中，一执行就将该值删除，等下次请求，如果redis中无该值，就提示多次操作失效。可有效防止接口重复提交。之所以不在新增/删除上添加该逻辑，因为该逻辑其实无形之中也增加了业务处理代码，首先得考虑是前端还是后台生成该次请求的唯一标识，同时还要处理失效等问题，反而不如直接查库来的方便。（当然一般情况下 新增/删除操作也不多）