服务幂等性设计

为何须要幂等性？

• 想想当转帐的时候，由于网络缘由暂时没收到响应，再次进行转帐，如何防止重复性的转帐。这就须要幂等设计。
• 当去自动化安装软件的时候，对于已经安装的软件，再次发出安装软件的命令，是重复安装软件，仍是看软件已经安装就返回安装好的结果。

若是从开发角度考虑：

• 请求执行屡次与执行一次的最终结果都是一致的
• 在业务上，同一用户不能重复下单，商品不超买，不会发生重复转帐

请求层面幂等

若是要作幂等，首先对请求进行分类，通常分为读请求和写请求，读请求通常不须要作幂等，读数据自己不会改变数据，所以无需作幂等，而写请求可能对数据形成改变，全部部分写请求须要进行幂等。

从架构层次上，看看那些层会对数据发生改变。

• 网关，业务逻辑通常不会修改数据

• 数据访问层可能修改数据，咱们只须要对数据访问层进行幂等性设计

对于数据访问层CRUD：

• 新增数据的时候，经过主键或者某个惟一标识如token，限制某条记录只能插入一次。

• 更新数据的时候，部分幂等。部分不幂等

  • update user set name='aihe' where id=1; 幂等的
  • update user set age++ where id=1; 非幂等的

• 删除数据的时候，部分幂等，部分非幂等，在实际删除的时候不要经过相对值来删除，通常在删除以前首先进行一次查询，而后进行绝对删除

  • delete from user where id=1; 幂等的
  • delete from user where uid in bottom 10; 非幂等的

真正须要处理的是update操做。如何处理呢？

• 方式一：相对值修改转换为绝对值修改。 update user set age=19 where id=1 and age=18; 可是在体量很是大的时候，不是一种好的方式
• 方式二：部分业务有状态流转，好比说已转帐，已收货。每次操做进行状态的修改，知足须要的状态才更新。状态流转比较复杂的时候，通常要引入分布式事务的问题

业务层面幂等

业务层次的幂等如何解决呢？

好比下了一个订单，可是冗余部署了多个进程，这个时候存在并发消费的可能性。对此咱们能够尝试将并行操做转换为串行操做，采用分布式锁。

共享资源经过锁来保证。

常见保证幂等性手段

通常在分布式系统中，全部请求都会携带一个惟一的请求流水号，requestNo，在进行操做以前判断这个requestNo是否已经入库了，若是在库中已经存在，表明已经处理过，若是不存在则继续处理。

通常一次操做对应的是一个请求流水号，若是请求流水号不一样，表明的是两次操做。