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. 趕緊使用最新版項目修改問題，趕緊上線吧！