1. 自從點擊追蹤系統(tǒng)是用redis連接池后,幾乎沒有出過什么問題了——即使在點擊量增長到兩千萬每天的時候。
2. 然而奇怪的是,UI的后臺和渠道的后臺,最早就在用連接池,并且并發(fā)量很低,卻動不動就redis連接報錯,返回null對象。
之前實在是沒想過代碼是不是有問題。一直通過腳本重啟項目。
3. 然后就有人抱怨你們這個系統(tǒng)有問題,要把redis改了!
4. 我簡單和UI后臺那邊說了兩句,點擊追蹤系統(tǒng)如此大的量都從未報錯,UI使用頻率夠低了,為何頻繁報錯?你是不是有代碼沒有關(guān)閉連接池啊?
5. 人家檢查了下項目后指出來有一個地方當(dāng)時是沒有關(guān)閉的。修改完線上版本后,我感覺必須確認是否還有別的地方了。
6. 于是想起了 grep 遞歸目錄查找文件內(nèi)容了。于是有了下面的方式:
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:39:36]
2009 $ grep -r "MCRedisInstance.getInstance" * > closejedis.txt
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:40:25]
2010 $ vi closejedis.txt
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:40:34]
2011 $ grep -r "jedis.close()" * > closejedis_close.txt
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:40:56]
2012 $ vimdiff closejedis.txt closejedis_close.txt
7. 同樣,在/home/arch/mc_project_v7執(zhí)行上述命令,
一目了然看到只有 closejedis.txt 里有下面的代碼,卻沒有關(guān)閉連接池。
8. 最后發(fā)現(xiàn)兩個項目里都是與報表相關(guān)的部分沒有關(guān)閉連接池。報表又是使用頻率最高的部分,難怪項目一直不穩(wěn)定了!
9. 趕緊使用最新版項目修改問題,趕緊上線吧!