接口幂等性和并发安全性设计

什么是接口幂等

就是一个接口，被重复调用多次，却能够保证对系统内部产生的影响是一致的，也就是调用多次和调用一次，数据的变化是一样的，是相同的，不会因为调用多次而出现任何数据问题，大体上又分为服务层接口幂等和数据层接口幂等。
比如下订单操作，多次下单所返回的订单都应该一致，并发不高的系统，可以接到下单请求时去数据库查询，如果已经有订单了直接返回当前订单。

什么是接口并发安全

就是一个接口有多个线程访问，落到数据库的操作必须加锁保证同时只能有一个线程修改，否则会出现超卖现象。

数据层接口幂等性和安全性设计

所有的数据层接口都可以分为insert、delete、update、select四种。
1.select天然幂等，多次查询和一次查询都是一样的。
2.delete天然幂等，多次删除也没用，因为已经删过了。
3.update天然幂等，多次更新要更新的值，始终是那一个更新的结果。
4.针对insert，可以把关键业务的某个字段设为唯一索引，这样，第二次插入就会失败，大多数业务都有唯一字段，比如用户的邮箱。
5.针对安全性，通过乐观锁，update table1 set f1 = v1 where f1 = v0 （v0 是初始值），这样第二次修改时会失败。

服务层接口幂等性安全性设计

1.新增接口，我们要保证同一个用户多次请求接口时，只请求一次。
通过token防重复提交解决，也就是用户第一次请求时服务器生成随机数token放在session中，并发送给客户端，第一次验证通过后会更新session的token，用户第二次请求时带上token，会发现和服务器session的token不一样了，就不能重复提交了。
使用token还能保证订单唯一性，因为有的用户就是想下两次同样的订单。
将token处理结果放到缓存中即可，在网关层调用处理结果，判断是否放行请求。
2.接口安全性，还是使用乐观锁。
可以建立一个状态机，可以是一张表或者什么的，保存业务的状态status，判断是否可以更新。

消费方消息幂等设计

消息重复发送的原因：
被动方应用接收到消息，业务处理完成后应用出问题，消息中间件不知道消息处理结果，会重新投递消息。
被动方应用接收到消息，业务处理完成后网络出问题，消息中间件收不到消息处理结果，会重新投递消息。
被动方应用接收到消息，业务处理时间过长，消息中间件因消息超时未确认，会再次投递消息。
被动方应用接收到消息，业务处理完成，消息中间件问题导致收不到消息处理结果，消息会重新投递。
被动方应用接收到消息，业务处理完成，消息中间件收到了消息处理结果，但由于消息存储故障导致消息没能成功确认，消息会再次投递。

总之就是各种情况下，消息队列认为消息没有被消费，而再次发送了消息，消息如果已经被消费过了，就会导致重复消费的幂等性问题。
怎么实现幂等：
1.业务实现，靠上面的数据接口层和业务层的幂等性设计。
2.增加消息表来实现幂等。
消息处理成功后，将消息ID和消息处理成功通过事务的形式写入消息表。
第二次消费时，判断消息表，如果没有消费成功，则消费，如果消费成功了，就不消费了。
3.多接口的安全性，可以用分布式锁，redis或者zk或者数据库+多线程，只有能成功插入的才算获得了锁，才可以进行线程安全的操作。