情况：收不到邮件。

 

邮件发送系统并没有问题。

排查思路:

1、发送一次,先去数据库看看是否验证码是不是重新生成一次了

select * from uc_verify_code where uid=21306555

目的是确保已经生成到数据库,因为只有这样子才会加入到数据库去的。

2、去看看redis队列任务的长度

加入到数据库后,才会加入到redis队列中去。

使用如下命令查看:

LLEN task_send_email

看看是不是为0。

 

目前发现是0。说明任务队列完全没有加入到redis中过去。去一下redis的空间。最后发现是redis爆满了，加不进去，其实加入的代码也有问题。没有进行判断。

 

要判断失败还是成功。这样会好点。


3、手动执行一下发送邮件的任务队列脚本:

这个任务带有锁的,同时刻只能一个脚本在执行,其他脚本是不能执行了

缓存锁是在redis里面存储了一个key,执行脚本的时候就存储进去。

 

key的值为:send_email_queue_lock

如果提示:is starting,就表示已经有其他进程在执行了。

要删除掉这个key:send_email_queue_lock



列出key的大小:

http://segmentfault.com/q/1010000000625993






以后要做一些工具。可以操作redis的工具,这样可以自己列出来看看。

其实搭建一个redis界面工具就能解决这个问题。

 

后续排查:redis的空间爆满，占据了20多g。怎么那么快。把那个占据内存最多的key:update_reside_ctiy，这是一个list数据结构。竟然有上亿条记录在里面了。

删除掉后，过了一天还是一样内存暴涨。最后去排查update_reside_ctiy这个key到底是什么原因涨得这么快。

 

被刷数据了




type key的值:

返回值：
    none (key不存在)
    string (字符串)
    list (列表)
    set (集合)
    zset (有序集)
    hash (哈希表)




列出key的大小:

http://segmentfault.com/q/1010000000625993


思考:当redis内存空间爆满的时候,并不会造成数据踢下去吗?还是加不进去呢?这样的代码逻辑要改一改才行了。
不会抛出异常的。平时要监控好才行。