防重放案例集分析
- 1. 防重放是什么？
- 2. 前端防重放
- 3. 后端防重放
- 4. 如何模拟网速慢的情况
- 2.1 解决思路 按钮不可点击、置灰 - 3. 后端防重放
- 3.1 解决思路1 幂等
- 3.2 解决思路2 悲观锁
- 3.2 解决思路2 乐观锁 - 4. 如何模拟网速慢的情况
本文地址：https://www.cnblogs.com/hchengmx/p/16532865.html
1. 防重放是什么？
防重放就是 防止一个按钮重复点击，重复点击的话，点击事件会连续触发多次，引起一些意想不到的bug。
2. 前端防重放
- 主要有两部分，防重复点击
前端的防重放的点主要在于 对于提交类的按钮，前端要确保一次提交后，无法在同个页面再次提交。
这类问题可能出现的原因有
- 前端提交后没有立即自动刷新/跳转到别的页面；
- 后端处理慢：前端还没接收到后台服务器返回前，一直停留在待提交页面，用户以为还没有点提交，可能再点一次“提交”；
- 其他
- 前进/后退操作；
- 用历史记录重复访问；
2.1 解决思路 按钮不可点击、置灰
比如某个提交按钮，点了一次以后，该按钮就立即置灰。这样就无法第二次点击。
3. 后端防重放
原因：
- 调用接口超时，RPC等自动触发重试机制；
- 前端没控住，比如打开多了浏览器同时提交等；
3.1 解决思路1 幂等
做根据某个唯一值做幂等。每次请求提交都生成全局唯一的业务流水号。
比如本行就可以以 sysSeqNo 来判断是不是重复。
后端就可以把全局流水号存进缓存里面，设置个超时时间，下次提交先判断缓存里面是否有该值，来判断要不要拒绝重复请求 / 进一步业务处理。
以唯一一个字段来区分是不是可以重复，虽然是方便，但是会有个问题，假如前端还是没控住，第二次提交该字段就真的不一样呢。
这里就需要业务系统以其他的业务字段来做幂等。
特别注意：要是做幂等拒绝的话，业务系统要特别注意，本来期望成功的提交操作，有可能会失败，需要注意业务重试。
3.2 解决思路2 悲观锁
悲观锁在操作数据时比较悲观，认为别人会同时修改数据。. 因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。
3.2 解决思路2 乐观锁
每次前端申请的时候，都默认带一个版本号version给后端。每次提交的时候，版本号+1。
要是前端手快点了两次，那前端两次申请的version是一样的，第一次提交后，后端的版本号已经+1，第二次提交的时候，后端目前的版本号 > 前端现在的版本号，就会拒绝掉第二次请求。
需要模拟该场景可以打开多个浏览器窗口进行操作。
4. 如何模拟网速慢的情况
通过chrome自带的network工具，可以模拟不同网速的情况。
具体参考：How to perform Network Throttling in Chrome | BrowserStack
