【11期】分布式系统插口，如何防止表单的重复递交？

　　程序员的成长之路

　　互联网/程序员/技术/资料共享

　　阅读本文大约须要 2 分钟。

　　作者：季雨林

　　关于如何实现承载更多用户量的系统，一直是我重点关注的一个技术方向。改造构架提升承载力，通常来讲分为两个大方向，互相配合实现。

　　硬件构架改进，主要是使用阿里云这些多组件的云环境：通过负载均衡SLB，模版克隆的云服务器ECS，云数据库RDS，共享对象存储OSS等不同职责的云产品组合实现。

　　软件构架优化，主要是软件代码开发的规范：业务解耦合，架构微服务，单机无状态化，文件储存共享等

　　在分布式系统的学习途中也不断见识新的知识点，今天要说的就是软件开发时侯对于插口服务的“幂等性”实现！

　　幂等性

　　效果：系统对某插口的多次恳求，都应当返回同样的结果！（网络访问失败的场景除外）

　　目的：避免由于各类缘由，重复恳求造成的业务重复处理

　　重复恳求场景案例：

　　1，客户端第一次恳求后，网络异常造成收到恳求执行逻辑并且没有返回给客户端，客户端的重新发起恳求

　　2，客户端迅速点击按键递交，导致同一逻辑被多次发送到服务器

　　简单来界定，业务逻辑无非都可以归纳为增删改查！

　　对于查询，内部不收录其他操作，属于只读性质的那个业务必然符合幂等性要求的。

　　对于删掉，重复做删掉恳求起码不会导致数据零乱，不过也有些场景更希望重复点击提示的是删掉成功，而不是目标不存在的提示。

　　对于新增和更改，这里是明天要重点关注的部份：新增，需要防止重复插入；修改，避免进行无效的重复更改；

　　幂等性的实现方法

　　实现方式：客户端做某一恳求的时侯带上辨识参数标示，服务端对此标示进行辨识，重复恳求则重复返回第一次的结果即可。

　　举个栗子：比如添加恳求的表单里，在打开添加表单页面的时侯，就生成一个AddId标示，这个AddId跟随表单一起递交到后台插口。

　　后台插口按照这个AddId，服务端就可以进行缓存标记并进行过滤，缓存值可以是AddId作为缓存key，返回内容作为缓存Value，这样虽然添加按键被多次点下也可以辨识下来。

　　这个AddId什么时候更新呢？只有在保存成功而且清空表单以后，才变更这个AddId标示，从而实现新数据的表单递交。