我的想法是 前台传入手机号。后台收到手机号后调用第三方接口发送短信。 如果调用成功。把用户手机号和验证码以及发送时间存入缓存。 但是想到一个问题，如果发送短信后，存入缓存出错了怎么办？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2855 days ago, the information mentioned may be changed or developed.
 |
1
Mysqto Aug 3, 2018
能容忍的话直接给前台返回失败，让用点重新发送 或者直接不给前台返回，给个倒计时，时间一到 让用户直接重新发送
|
 |
2
sarices Aug 3, 2018
一般都是存到 session 的，真的保存不到的情况，应该直接报错，还有现在的短信验证都有验证接口的，根本无需本地保存
|
 |
3
WuwuGin Aug 3, 2018
所以不都是有个 60s 重新发送吗？
|
 |
4
ytmsdy Aug 3, 2018
所以需要把手机号码和验证码做持久化！
|
 |
5
T110E5 Aug 3, 2018
颠倒一下咋样？先存缓存，存失败直接返回 或者异常捕获重试，发送失败清理刚才的缓存
|
 |
6
chocotan Aug 3, 2018
我们是直接存到 session，不过 session 是放 redis 里的
|
 |
7
cyssxt Aug 3, 2018
前台做一个限制吧，就拿我用 redis 做缓存来说，这个缓存失败的概率是微乎其微的
|
 |
8
dorothyREN Aug 3, 2018
缓存成功的话再去调用短信接口。话说楼主要不要考虑我们家的短信接口。
|
 |
9
aniskin Aug 3, 2018
写入缓存失败的概率应该比调用第三方短信接口的失败概率还低。
我们的做法是直接返回成功，然后异步调用第三方短信接口，如果失败则 retry，再失败就不管了。 最后加一个预警，如果单位时间失败次数过高会通知开发 |
 |
10
jianpanxia Aug 3, 2018
我是先放 redis，ok 了发短信。
如果用户再次发送，会先生成一个新的覆盖 redis 再发送。 |
 |
11
vjnjc Aug 3, 2018
我觉得调接口发短信失败几率更大点，所以跟你一样先存再发
|
 |
12
laball Aug 3, 2018
短信验证码，不一定能保证完全发送到的，可以考虑 60 倒计时，没有收到，允许用户重新发起；同时，后台，也可以适当重试，比如，如果失败，则重试 3 次，一般都是调用第三方的短信接口，不一定能保证没底调用都没有问题；
交互上，需要产品稍微设计一下； |
 |
13
Light3 Aug 3, 2018
先存再发 检查时间 没过 60 秒 就还用这个发
别发送成功 再存 感觉很蠢。。 还有记得加 验证什么的 要不然被刷了 好惨 |
Select Language