85 lines
4.3 KiB
Markdown
Executable File
85 lines
4.3 KiB
Markdown
Executable File
|
||
接口幂等性实现起来非常的简单，不打算带着大家手写代码
|
||
|
||
（1）数据库唯一索引
|
||
（2）基于Redis实现一套幂等性防重框架
|
||
|
||
|
||
|
||
对于插入类的操作，一般都是建议大家要在数据库表中设计一些唯一索引
|
||
|
||
|
||
你如果有一个订单被支付了，此时就要通知wms创建一个对应发货单，也是数据库里的一个表，仓库里的人会看到这个发货单，此时他就会根据发货单的信息从仓库里进行拣货，打包，封装，交给物流公司
|
||
|
||
|
||
|
||
发货单
|
||
|
||
id order_id 订单金额 发货地址 xxxx
|
||
|
||
对order_id就可以建立一个唯一索引，你插入发货单的时候，同一个order_id最多只能对应一个发货单，不可能说同样的一个order_id对应了多个发货单
|
||
|
||
|
||
订单服务 -> wms服务，出现了重试，导致第二次请求再次让人家创建这个订单的发货单，create语句，order_id触发了唯一索引约束
|
||
|
||
|
||
|
||
|
||
|
||
扣减库存、累加积分，更新，很难通过数据库唯一索引来保证
|
||
|
||
|
||
基于Redis实现一套接口的防重框架
|
||
|
||
你得做一个类似spring mvc里的拦截器这样的东西，在这个拦截器里，他会拦截所有的请求，对所有的请求都会提取请求对应的参数，GET请求、POST请求、PUT请求，有些参数是跟在URL地址里的，?xx=xx&xx=xx
|
||
|
||
POST、PUT，可能是请求体里的，可能是一个JSON格式
|
||
|
||
把参数拼接在一起，作为key去redis中判断一下，是否存在这个key，之前附加这些参数的请求是否发起过，如果没有的话，此时就可以把这些参数+接口名称，作为一个key，存储到redis中去
|
||
|
||
然后呢，把请求放行，去执行这个请求
|
||
|
||
如果说人家重试再次发起一个这个请求，此时就可以判断出来，参数组成的key在redis中已经存在了，此时就不让执行这个请求了，认为是重复调用了
|
||
|
||
|
||
|
||
|
||
|
||
考虑很多问题，幂等不幂等，通用框架，需要一个公司所有的接口都按照指定的参数来传递，还有很多业务语义的问题
|
||
|
||
第一次发起一个请求，直接把请求key放入redis，但是他执行的过程中失败了，而且还阻塞了一段时间，此时人家再次重试发起第二次请求，这个时候按照上述的框架逻辑，就会把请求拦截下来了
|
||
|
||
|
||
到底是不是要对所有接口都开启这么一个东西呢？
|
||
|
||
|
||
每个接口如果执行成功了之后，我可以设置一个每个接口调用的时候执行成功之后，做一个后拦截器，如果成功了，就把请求对应的参数拼接为key放入redis中
|
||
|
||
有没有可能是第一次请求发送过来，在执行过程中，时间长了，比如需要1.3秒才执行完毕；此时人家发现超过1s了，直接重试，第二次请求过来了，也在正常的执行
|
||
|
||
第一次请求1.3秒之后执行成功了，第二次请求也执行成功了
|
||
|
||
只要一个服务希望对自己的接口开启幂等性防重功能，就把你开发好的拦截器对应的jar包，通过maven引入一个依赖就可以了
|
||
|
||
|
||
|
||
中大型互联网公司里也没做一个统一的防重幂等框架，其实一般都是各个服务对自己核心的接口，如果要保证幂等性的话，每个服务根据自己的业务逻辑来实现，而且仅仅是对少数核心接口做幂等性保障
|
||
|
||
|
||
核心接口，库存服务，扣减库存接口
|
||
|
||
定制化的去针对接口开发幂等性的机制，比如说一旦库存扣减成功之后，就立马要写一条数据到redis里去，order_id_11356_stock_deduct，写入redis中，如果写入成功，就说明之前这个订单的库存扣减，没人执行过
|
||
|
||
但是如果此时有一些重试的请求过来了，调用了你的库存扣减接口，他同时也进行了库存的扣减，但是他用同样的一个key，order_id_11356_stock_deduct，写入redis中，此时会发现已经有人写过key，key已经存在了
|
||
|
||
此时你就应该直接对刚才的库存扣减逻辑做一个反向的回滚逻辑，update product_stock set stock = stock - 100，update product_stock set stock = stock + 100，反向逻辑，回滚掉，自己避免说重复扣减库存
|
||
|
||
|
||
|
||
|
||
|
||
|
||
核心接口，幂等性都是自己保证的，人家可能会重试调用你的接口，对于create类的操作，用唯一索引来保证；对update类的操作，建议在核心接口里基于自己的业务逻辑，配合上redis，来保证幂等性
|
||
|
||
|