记录一次从redis获取值为null的过程

业务逻辑：
有三个接口，
（1）发送短信，redis保存验证码
（2）checkMember（需要获取redis值），
（3）dynamicLogin （需要获取redis值；验证成功，删除redis值）
（4）tenantLogin（需要获取redis值；验证成功，删除redis值）

逻辑上是（1）先发送短信验证码
（2）->（3） 或者（2）->(4)
表象：（2）的时候，获取验证码为null。

分析过程：
（1）考虑前端传的值缺少国家码，造成在存取时键不一致。–》排除，因为只有部分用户出现这种情况
（2）考虑redis存取使用的RedisTemplate 不一样。 --》排除，因为一直使用的是StringRedisTemplate，近两天才出现这个问题。叫上几个同事，一起帮忙排查，也没能找出原因。头疼
（3）考虑使用的redis集群有丢数据可能 。–》 查看日志，第一步存和第二步取直接相隔12秒，并且设置的过期时间也成功了，根据key直接查，没有这个key。排查redis策略设置，内存设置等等，使用的库中是否也有别人使用了同样的key，还是一无所获。
（4）更换redis服务器，发现还是有部分用户获取验证码为null。–》 确定不是redis问题。心焦了个周末。

好了，不是redis问题，redis刚存值的时候，键也存在，那么为什么再过了不到20秒的时间，就找不到对应的值了呢？

加日志，各个步骤，能加则加。终于在梦中给了提示，周一早上，像打了鸡血一样，精神倍加，继续看日志，发现这个报错的问题有点蹊跷，根据日志排查，用户走了（2）->（3）->（2）,为什么又走了一次(2）呢？
此时获取redis值为null的问题找到了，因为走了（3）或（4），已经把redis中的值删掉了。
那么为什么又走了一遍（2）呢，前端同事排查代码，也没有发现有再走一次（2）的逻辑。怎么回事？

忽然前端同事灵机一动，重复点击。果真，在测试环境复现了，确实那个报错也是在第二次点击走到（2）的时候，报错的。晕，一个小问题搞了2天。

前端修改，完美解决。
写文章记之

真相总是存在我们身边，只有我们坚持追着不放，早晚会解决。