场景问题解决方案

一、分布式服务的接口幂等性设计

（一）概述

所谓幂等：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析:

请求方式	说明
GET	查询操作，天然幂等
POST	新增操作，请求一次与请求多次造成的结果不同，不是幂等的
PUT	更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，则不是幂等的
DELETE	根据唯一值删除，则是幂等的；如果是根据条件删除，则不一定幂等。例如每次删除某字段最大的记录

（二）需要幂等的场景

1. 网络波动：因网络波动，可能会引起重复请求。
2. MQ 消息重复：生产者已把消息发送给 MQ，在 MQ 给生产者返回 ack 的时候网络中断，生产者未收到确定消息，认为消息未发送成功。但实际情况是，MQ 已成功接收到消息，在网络重连后，生产者会重新发送刚才的消息，造成 MQ 接收了重复的消息。
3. 用户重复点击：用户在使用产品时，可能会误操作而触发多笔交易，或因为长时间没有响应，而有意触发多笔交易。
4. 应用使用失败或超时重试机制：为考虑系统业务稳定性，开发人员一般设计系统时，会考虑失败了如何进行下一步操作或等待一定时间继续前端的动作。

（三）后端解决方案

1. 方案一：数据库唯一索引
   • 使用数据库提供的唯一索引来保证数据重复插入，避免脏数据产生。
   • 解决场景：新增。
2. 方案二：token + redis
   
   • 第一次请求：在后端生成一个唯一的 token（比如：key:userid, value:UUID），将 token 存储到 redis 中，将 token 返回前端。
   • 第二次请求：在真正处理业务的时候需要携带过来之前的 token，到 redis 中查询 token 是否存在。如果存在，则正常处理业务，同时删除 redis 中的 token；如果不存在，则操作失败。
   • 解决场景：新增、删除、修改。
3. 方案三：分布式锁
   • 在分布式锁使用的时候，要注意粒度。在操作数据时，先添加一个分布式锁，当操作完成后再释放掉这把锁。同时在操作过程中，如果有人来抢锁，应当抛出异常，即:

   	if (!lock) {
        
   	        log.info("操作作者信息获取锁失败，operator: 
   	{
        }",request.getOperator());