问：Tom老师，请问短信验证码接口被狂刷，搞得服务都快要崩溃了，我该怎么办？
答：我想都到云时代了，我想这个问题不应该出现吧？现在，都有非常多的短信服务提供商，应该自带防火墙功能的。
问：不是，他这个所有的验证都是自己开发的，后台只调用了发送短信的接口，而且还导致短信费用瞬间飙升，（如图）后面把入口强行关闭才及时止损，你看看这个是后台的统计结果。
答：哦，针对于这种情况的话，给以下6点优化建议吧：
第1点是、限制发送短信的时间间隔，比如，规定每隔60秒后才能再次发送。
后台可以记录给每个手机号码发送短信的时间点，在发送短信之前校验一下看时间间隔是否大于60秒。如果小于60秒则直接拒绝响应，只有大于60秒才调用发送短信的接口。
当然，为了提高用户体验，可以在前端页面加一个60秒倒是的提示，没有达到间隔时间限制，将发送按钮置为禁用状态。这种处理方式虽然非常普遍，但技术稍微好点的程序员完全可以绕过这个限制的，还要继续加强防护措施。
所以，第2点，可以设置手机号码发送次数上限。比如，规定同一个手机号在24小时之内不能够超过5条。如果发送超过5条，可以提示用户第2天再操作，或者申请人工服务。当然，加上这条限制也只能够避免人工手动刷短信而已，对于批量使用不同手机号码来刷短信的机器来说，这种方法也是无可奈何的。
所以，第3点、还需要增加图形验证码校验。比如，同一个IP地址，或者同一个手机号码，连续发送3条以上，就需要输入图形验证码才能触发发送短信的动作。这样，又能拦截一大批恶意请求。但是，如果恶意刷短信的手机号码够多，代理IP也够多，还是有存在风险。
所以，为了继续加强保护，可以增加第4点、控制短信验证码接口的调用频次：比如，说30分钟之内，同一个IP，同一个手机号只发送同一个验证码。也就是说，将第一次请求短信接口的验证码结果缓存到服务器本地，只要是在30分钟之内再次请求，就直接返回缓存中的结果。当然，有些特殊业务场景是不能允许这样设计的，比如，银行转账的短信验证接口。
所以，还可以增加第5点、加上前后端请求唯一性校验，比如给每一次请求加上token参数校验。在前端页面请求发送短信的时候，同时，要携带一个由服务器生成的token参数，服务端对这个token参数进行校验，校验通过之后，再向请求发送短信的接口向用户手机发送短信。
最后，为了避免后台服务过多地处理无效请求，还可以再增加第6点、设置黑名单，比如，将频繁请求的IP地址和手机号码直接加入黑名单，禁止请求服务接口。当然，如果是系统误判，误入黑名单，也可以找人工解禁。
以上就是我针对于短信验证码接口被狂刷的解决方案，各位汤粉如果要有需要补充的，可以分享到评论区。
我是被编程耽误的文艺Tom，如果我的分享对你有帮助，请动动手指分享给更多的人。关注我，面试不再难！
我是被编程耽误的文艺Tom，关注我，面试不再难！
完整版面试资料和答案以及PDF文档 ：
