防止表单重复提交的思路和方法

作为一个软件开发者，绝不能奢望你的用户会规规矩矩地使用你的软件，他们一般都是缺乏耐心，“胡作非为”的。比如当他点击提交表单时，服务器处理比较慢， 页面上没有任何反应，他会迫不及待地再点击几次，这样就会产生重复数据或者报错，或者他会刷新一下再次提交。所以，你必须保证你的软件足够地健壮，尽可能地考虑各种用例，增加限制，抵御使用者的摧残。

对于如何处理重复提交，一般教科书上都有点明，不外乎是在js代码中增加限制或者通过session来处理。关于js代码限制，就是当用户第一次提交后，将提交按钮设置为“disable”状态，或者直接不提交重复请求，这只能处理用户重复连续点击的情况，如果用户刷新页面后再次提交，这种方法就无济于事了，因此我们更多的是通过session处理，就是在访问表单提交页时，服务器端生成一个随机序列，存储在session中，并传递到客户端，用户提交时，连同这个序列一起传递到服务器，后端程序会判断这两个序列是否一致，如果一致，表明是第一次提交，否则就是重复提交。

但是在多服务器多用户的场景下，以上方法也都会失效，在多服务器场景下，session存在于每台服务器中，请求是通过负载均衡机制分配到各台服务器上的，要通过session防止重复提交，必须有一套定向分派请求或者session共享的机制，就算你实现了，如何处理多用户请求的情况呢，比如在一个母帐号下，有多个子帐号，每个子帐号都有权限操作某一块业务，当多人同时登录操作这一块业务时，一定会出现类似于多线程并发访问共享资源的问题，那该如何解决呢？

世界上很多道理都是相通的，古人常将齐家治国联系在一起，你在齐家过程中得出的一些经验一定程度上可以用于治国领域，同样，处理多线程问题的一些思路方法也可以给多服务器多用户访问设计提供借鉴，处理并发问题最常用的一个方法就是加锁，当一个请求发出，服务器正在处理时，待处理的资源就处于锁定状态，后续的相关请求被抛弃或者进入阻塞队列等待，待处理完毕资源解锁。基本思路是这样，那我们通过什么具体方法，中间件实现这一设计呢，我们可以使用redis缓存，相比于session，它并不仅仅针对于特定用户会话，也就是说它可以处理多个用户同时提交同一类请求的情况。

每个请求都将带有表示某块资源的唯一标识KEY_NAME，当第一次请求时，redis 会执行INCR KEY_NAME命令，这是个原子递增操作，值变为1，于是后续同类请求会将它依次递增为2，3，4........，当值大于1时，表示资源已在处理中，后续请求被抛弃或处于等待状态，待处理完毕，将值重新设为0，表示资源已解锁可用。这是借助redis缓存实现的类加锁机制，解决多服务器多用户场景下请求重复提交的情况。