需求分析
一、站在被攻击者的角度而言，首先要保证的是：其手机号短时间内不收到多条短信（假定为每分钟最多收到1条），而若攻击者以分钟为单位调用接口，对被攻击者而言也难以接受，故同样要保证的是：被攻击者在同一天内不收到多条短信（假定为5条）。
二、站在服务提供者的角度而言，平台不希望发出大量无用短信，从而增加系统压力与短信费用，但不能以简单的限制每日发送短信总数量来做处理，因为当攻击者恶意调用多次接口导致系统不再提供服务后，将影响用户的正常注册。同时，在业务增长期，注册人数难以用固定的数值来衡量，对于平台而言，识别出可疑的异常调用者是最好的解决方案。
三、站在普通用户的角度而言，在能够保证正常注册以外，注册的体验也较为关键，比如：未收到短信时点击重新发送的时间不宜过长、验证码不宜太过复杂等。
四、系统压力与处理速度上，若这一套防刷机制过于复杂，在调用时要进行多种检验、判断，会对系统造成压力，同时用户收到短信的速度也会减慢。
在各类场景如：
1.同一ip对同一手机号的大量发送
2.同一ip下对不同手机号的大量发送
3.更换ip对同一手机号大量发送
4.场景1、2、3下两次请求之间间隔一段时间进行调用
5.不同ip短时间内对不同手机号的大量发送
优先级最高需要保证的是：
正常注册功能不受影响
单一用户不遭到“轰炸”式骚扰
其次要做到的是：
尽量少发出无用短信
正常用户注册体验较好
拟用以下策略解决以下情况：
1.优化流程：如先让用户输入要注册的账号密码后再进入短信验证环节，先验证手机号是否合法后再 做其他判断等。
2.保证某一用户不遭到“轰炸”式骚扰：前端添加定时按钮，如一分钟后才可以重新点击发送
若该按钮被绕过，则说明调用者并非正常用户，策略3中会解决这一情况；
3.保证某一用户同一天内不收到过多短信：为每个号码记录其当日发送量，限制为5条，若1中前端被 绕过，则也可以保证该用户不会收到过多短信；
4.某一用户不想再接到平台短信：保留退订功能，记录所以退订用户为禁止发送对象
5.同一ip对不同手机号大量发送：为每个ip记录其当日发送量，同样有条数限制；
6.对于更换ip给不同手机号发送大量信息这一情况，在保证用户能够正常注册的情况下，必然不能关闭发送服务，考虑的方案是当当日发送量到达一定量时，需要输入验证码进行后续操作，另外可以再根据这一发送量，调整验证码难度，在不影响正常服务的情况下，逐渐增加攻击者攻击成本。
按照上述策略，拟完成的任务有：
1.完成对号码、IP地址当日发送数量的限制
2.完成号码退订功能
3.完成对手机号是否合法的验证
4.完成验证码功能及开启验证码使用功能
5.全局异常处理、日志、规范化接口等公共要求
6.集群化处理
方案设计
对需求分析中给出的六点拟定完成任务的方案设想：
1.完成对号码、IP地址当日发送数量的限制
2.完成号码退订功能
3.完成对手机号是否合法的验证
4.完成验证码功能及开启验证码使用功能
5.全局异常处理、日志、规范化接口公共要求
6.集群化处理
对号码、IP地址发送数量限制
通过Redis的过期时间完成，存储号码/IP地址为key，次数为value的字符串，每次判断是否到达限制，若未找到则写入string，若达到限制则拒绝服务，若正常发送则令次数+1
号码退订功能
使用Redis的set集合完成，其查询复杂度为O(1)，每次发送流程中优先判断是否处于黑名单
手机号是否合法
使用正则表达式完成
验证码方案
当今日成功发送量大于给定值时，后续需要用户输入验证码才能服务
计数器方案：每日重置的线程安全的计数器，每次成功发送即+1，但考虑到服务器重启后就会重新计数，所以还是需要持久化
实现：使用Kaptcha——一个google开源的验证码jar包生成验证码。具体流程为：
1.前端请求后端
2.后端使用Kaptcha生成一个验证码captcha
3.后端为这个验证码生成一个token，以token为key，captcha为value存在redis中
4.后端将token和验证图片一起传给前端（图片使用base64，与token打成一个map）
5.前端将这个token以及用户所输入的验证码传入后端，后端根据token到redis中取值，验证是否一致
可以提前生成一批验证码防止访问高峰时验证码绘制占用性能过高的情况
集群化处理
设想将该业务实现为一个短信发送服务，即服务提供者，在不同的场景下如用户注册、忘记密码、绑定手机等需要发送短信时，由不同消费者调用该服务。使用Dubbo、ZooKeeper完成。
最终结构（provider）：
代码之后会上传至github