情况：收不到邮件。
邮件发送系统并没有问题。
排查思路:
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内存空间爆满的时候,并不会造成数据踢下去吗?还是加不进去呢?这样的代码逻辑要改一改才行了。
不会抛出异常的。平时要监控好才行。
