幂等性

• 什么是幂等性

• 就是对资源的操作，无论操作一次还是多次，其资源本身不发生变化。

  • 幂等性设计其实是分布式中十分重要的概念

  比如表单重复提交是一个典型的需要进行幂等性设计的一个问题。

  • 需要幂等的场景

  1. 网络波动：
     因网络波动，可能会引起重复请求
  2. 分布式消息消费：
     任务发布后，使用分布式消息服务来进行消费。
  3. 用户重复操作：
     用户在使用产品时，可能会误操作而触发多笔交易，或者因为长时间没有响应，而有意触发多笔交易。
  4. 未关闭的重试机制：
     技术人员人为的错误，因开发人员、测试人员或运维人员没有检查出来，而开启的重试机制（如Nginx重试、RPC通信重试或业务层重试等）

  • 如何进行幂等设计

  对于get、detele、put请求，具有天然的幂等性，因此只需讨论post请求：
  1.设置全局ID
  根据业务的操作和内容生成一个全局ID。例如，在提交表单前，进入表单页面时，先向服务器端请求生成全局ID的接口，服务器将这个值存于内存中，待用户提交表单时，将这个全局ID附带上，服务器端校验是否存在这个值（一般用删除delete方法，通过返回值判断。采用select+delete容易出现并发问题）,如果存在则运行请求接口。【方案可以，只是实现由点小麻烦】
  2. 添加去重表
  这种方法适合于业务中有唯一标识的插入场景中，如对某订单进行支付，订单号即可以作为唯一标识。通过创建一张去重表。这个表将支付的订单号设为唯一索引，第一次请求将支付订单记录插入表中并设置为未支付同时返回给支付系统完成实际支付操作，后续重复请求就会因为唯一索引导致插入失败而不会再走后续的实际支付操作。
  3.采用锁机制（如悲观锁和乐观锁）
  悲观锁，就是悲观的认为数据会被改变，在数据修改的过程中始终是加锁的。其他线程无论是读还是写都无法拿到数据。通过for update来进行锁表。
  乐观锁，相对悲观锁来讲更为广泛一些，因为乐观锁不依赖数据库，只会在update的一瞬间加锁，其余处理过程中并不加锁。通过版本号来实现。乐观锁每次只会有一个线程执行成功，其他线程因为条件发生了改变，而执行失败，这样就避免了数据覆盖的可能性。
  4. 分布式锁
  可以用redis或zookeeper实现分布式锁。

  • HTTP协议的安全性和幂等性

  1.安全性
  GET、HEAD和OPTIONS这三个HTTP方法旨在发送请求以或者所需的信息,是安全的方法。
  POST、PUT、PATCH和DELETE），它们旨在针对目标资源作添加、修改和删除操作，它们会导致服务端资源的变化，所以被认为是不安全的方法。
  2. 幂等性
  上述3种安全的HTTP方法（GET、HEAD和OPTIONS）均是幂等方法。由于DELETE现有的某个资源，所以它们是幂等方法。对于PUT请求，只有在对应资源不存在的情况下服务器才会进行添加操作，否则只作修改操作，所以它也是幂等方法。
  PATCH提供的实体则需要根据程序或其它协议的定义，解析后在服务器上执行，以此来修改服务器上的资源。换句话说，PATCH请求是会执行某个程序的，如果重复提交，程序可能执行多次，对服务器上的资源就可能造成额外的影响，这就可以解释它为什么是非幂等的了。（修改次数）
  至于最后一种POST，由于它总是进行添加操作，如果服务器接收到两次相同的POST操作，将导致两个相同的资源被创建，所以这是一个非幂等的方法。

  • 带着幂等性的原则设计API

  1.查询类的
  查询不应该影响资源的变化，所以我们选择get类型的操作，而不选择非幂等性的post。
  2.更新类的
  如果是全部更新，更新多次资源还是不变，我们则使用put,如果更新资源部分数据发生变化（这个变化一般是由程序控制的，比如最后修改时间，最后修改次数等），这个是有建议使用patch。
  3.创建类的
  创建资源属于非幂等操作，建议采用post。
  4.删除类的
  毋庸置疑，delete。