情況：收不到郵件。
郵件傳送系統並沒有問題。
排查思路:
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記憶體空間爆滿的時候,並不會造成資料踢下去嗎?還是加不進去呢?這樣的程式碼邏輯要改一改才行了。
不會丟擲異常的。平時要監控好才行。