我的想法是 前台传入手机号。后台收到手机号后调用第三方接口发送短信。 如果调用成功。把用户手机号和验证码以及发送时间存入缓存。 但是想到一个问题,如果发送短信后,存入缓存出错了怎么办?
1
Mysqto 2018-08-03 10:41:32 +08:00
能容忍的话直接给前台返回失败,让用点重新发送 或者直接不给前台返回,给个倒计时,时间一到 让用户直接重新发送
|
2
sarices 2018-08-03 10:44:07 +08:00
一般都是存到 session 的,真的保存不到的情况,应该直接报错,还有现在的短信验证都有验证接口的,根本无需本地保存
|
3
WuwuGin 2018-08-03 10:45:39 +08:00
所以不都是有个 60s 重新发送吗?
|
4
ytmsdy 2018-08-03 10:47:26 +08:00
所以需要把手机号码和验证码做持久化!
|
5
T110E5 2018-08-03 10:47:48 +08:00
颠倒一下咋样?先存缓存,存失败直接返回 或者异常捕获重试,发送失败清理刚才的缓存
|
6
chocotan 2018-08-03 10:50:19 +08:00
我们是直接存到 session,不过 session 是放 redis 里的
|
7
cyssxt 2018-08-03 10:51:34 +08:00
前台做一个限制吧,就拿我用 redis 做缓存来说,这个缓存失败的概率是微乎其微的
|
8
dorothyREN 2018-08-03 10:56:38 +08:00
缓存成功的话再去调用短信接口。话说楼主要不要考虑我们家的短信接口。
|
9
aniskin 2018-08-03 10:57:12 +08:00
写入缓存失败的概率应该比调用第三方短信接口的失败概率还低。
我们的做法是直接返回成功,然后异步调用第三方短信接口,如果失败则 retry,再失败就不管了。 最后加一个预警,如果单位时间失败次数过高会通知开发 |
10
jianpanxia 2018-08-03 11:10:26 +08:00
我是先放 redis,ok 了发短信。
如果用户再次发送,会先生成一个新的覆盖 redis 再发送。 |
11
vjnjc 2018-08-03 12:35:50 +08:00
我觉得调接口发短信失败几率更大点,所以跟你一样先存再发
|
12
laball 2018-08-03 13:03:23 +08:00
短信验证码,不一定能保证完全发送到的,可以考虑 60 倒计时,没有收到,允许用户重新发起;同时,后台,也可以适当重试,比如,如果失败,则重试 3 次,一般都是调用第三方的短信接口,不一定能保证没底调用都没有问题;
交互上,需要产品稍微设计一下; |
13
Light3 2018-08-03 13:49:36 +08:00
先存再发 检查时间 没过 60 秒 就还用这个发
别发送成功 再存 感觉很蠢。。 还有记得加 验证什么的 要不然被刷了 好惨 |