http_幂等性

幂等性

1.定义：

• 幂等的
  • 若是(路经，请求方式，参数都相同)方法调用一次和调用多次得到的结果是一样的，则称为方法是幂等的。
  • 注：若是参数不相同则没有可比性；
• http幂等性
  • 资源请求一次，或者多次产生的副作用是相同的。
  • eg： 我们发送1次get请求，获取一个ok，与发送100次请求，获取这个ok，效果是一样的，都是得到一个ok，中间没有给服务器带来任何压力，也没有修改数据库，因此我们称这个get请求是幂等的。
• http请求是不是幂等的呢

  • GET获取请求， 是幂等的。

    • 请求一次，与请求多次，不会对后端造成任何影响。

  • DELECT删除请求， 是幂等的。

    • 删除一次，与删除多次，结果都是被删除了。

  • POST请求创建资源，不是幂等的。

    • 两次创建操作，会对在后台创建两个不同的资源，因此不是幂等的。

  • PUT请求更新资源， 是幂等的。

    • 更新一次，与更新多次（数据相同）， 得到的结果都是被更新后的。

2.影响幂等性现象

• 1：因为网络波动，引起重复请求。

  • 案例：例如收藏（取消收藏）请求，我们请求了一次，因为网络原因，我们一直没有返回响应，用户由于没有看到被收藏了，结果再次点击收藏，而两次点击收藏导致我们后端仍处于未收藏状态，影响了幂等性。

• 2： 用户重复操作，导致重复扣款，重复下单等问题。

  • 例如： 双十一，用户下单请求，提交一次后，由于网络堵塞，用户点击了刷新，导致相同订单重复请求，则会导致数据库中存在两个订单。

• 3： 页面刷新， 回退按钮，导致重复提交表单。

  • 例如：学校网站问卷调查统计，再提交时，由于网络延时，或者后端反应过慢，导致用户重新刷新，重新提交表单，则导致问卷多出一份。

3.数据库幂等性设计

• 幂等性设计的地点：由于都是对于数据库数据进行操作，才设计幂等性，因此我们要在访问数据库之前做幂等性设计。

• 读请求，显然不需要设计幂等性。

• 写请求，增删改需要设计幂等性。

2.1：增加操作：

• insert操作： 例如： insert into student(id, name, age, sex);

  • 如果是自增主键，则会出现幂等性问题，因为两次都可以插入。

  • 如果给 name, age, sex,设置唯一索引，则不会出现幂等性问题， 因为数据库会报错。

2.2：删除操作：

• delect 操作：

  • 相对删除：删除前20条数据， 会出现幂等问题。

  • 绝对删除：删除id是1的数据， 不会出现幂等问题。

2.3：更新操作：

• 相对更新：将id为1的价格增加100， 此时不是幂等的。

• 绝对更新：将id为1的价格修改成100， 此时是幂等的。

4.前端解决幂等性

1：按钮设置成只能操作一次， 防止用户重复提交。

• 例如提交按钮，点击后，前端变成灰色，不能再次点击了。

2: Post/Redirect/Get（PRG）模式：

• 例如： 前端当用户提交后，立刻发出一个请求，请求发送成功的页面。这样避免用户刷新页面导致重复提交，也不会出现浏览器提示重复提交的警告，而且也消除了因为前进和后退导致重复提交的问题。