幂等设计

1.请求的幂等(请求重试）

定义：一个请求执行一次，读请求不需要做幂等，写请求需要，因为写请求可能对数据发生改变，原则：谁对数据发生改变就需要做幂等。

如：一个写请求网关层发到业务逻辑层1上进行写数据，但由于写操作比较慢，返回网关状态是写超时，但实际上是写入成功的。由于网关得到的是写超时，会将该写请求重先转发给业务逻辑层2上进行再次写操作，这时就会发生重复写，会造成数据的错乱，所以这种场景就需要写请求的幂等。

1.1.请求幂等范围

从读写请求层面：只有写请求会对数据改变。

从架构层面看，哪些层（App ->Nginx->网关层->业务逻辑层->数据访问层->db/Cache），主要看哪些层对数据造成改变，可以看出主要是在数据访问层会对数据进行改变。

1.2.数据访问层：主要就是CRUD

1.2.1. create/insert

尽量不使用自增主键，自增主键会造成二次查找（index找到自增主键，自增主键再查找数据），自增主键不好做幂等。（一般禁止使用自增主键，都使用业务主键，业务主键在插入时就会自动幂等）

1.2.2.update:

   update user set age=18 where uid=58 // 绝对值是幂等

   update user set age++ where uid =58  // 相对值是不幂等的

1.2.3. Delete

   Delete from user where uid = 58 // 幂等

  Delete user where unid in bottom 10; // 不幂等

最终是分布式事务解决

2.业务层的幂等

场景：1）、同一用户不重复下单(对同一类商品进行一次下单)

           2）、端口不超卖(不超过库存) 如：发送方发了多次请求到MQ

           3）、MQ消费端去重

2.1.冗余部署多个进程

         存在并发消费的可能 性，并发转变成串行消费

本质：分布式锁问题 如对发送到mq中的订单消息，可以根据订单号进行分布式锁控制幂等