程序員探案之 Python和Redis 的「第三者」

作者 | 周小毛

責編| 郭芮

在《程序員探案之"被吃掉"的數據》一文中，本探長英明神武地解決了嵌入式開發過程中串口數據「走丟」的問題。這不，最近探長又破了個棘手的案子。咳咳，探長要開始還原案件始終了，請耐心看下文。

直擊案發現場

現場圖片可見，在放入Redis數據時停頓了近25秒。這是什麼情況？正常情況應該是下面這樣的才對。

仔細理理現場

這是用Python和Redis實現的一個簡單消息隊列，通過Redis-PY的驅動用Rpush和Lpop命令來實現消息的入隊和出隊。還有一個特徵是，這是一個新的嵌入式開發平台。

案情分析

一號疑犯"Redis-Server"

Redis-Server作為主要的服務提供商，自然嫌疑最大。

但排查完Redis-Server的各項配置，發現連接數、阻塞數等等指標也一切正常，沒有任何直接證據指向它。

另外，同樣的代碼在另一個開發平台上遠程連接"案發"現場平台的Redis-Server也很正常，這也旁證Redis-Server是清白的，暫時解除嫌疑。

二號疑犯"Redis-py"

Redis-py作為服務的中間商，承上啟下，嫌疑也不小。Redis-py作為第三方庫，查看版本，安裝路徑，都正常。檢索Github的Issue和相關案例，也未發現類似「犯罪記錄」。另外，它也有旁證：相同代碼在其他環境一切正常，案發環境連接遠程的Redis-Server也正常。

這樣，Redis-py的嫌疑也解除了。

重大嫌疑人陸續被排除嫌疑，頓時又變得撲朔迷離，再次陷於僵局。

摸底排查，揪出元兇

靜一靜，重新捋一捋手頭的所有線索，功夫不負有心人，我又發現了些蛛絲馬跡。在Redis-py源碼中，創建Socket連接時，發現Getaddrinfo調用。

打點定位，發現就是在這裡阻塞耗時。這下，"真兇"水落石出。

但疑團還沒有消散，為什麼其他環境正常呢？這個是Socket內置模塊，正常不會有這麼明顯的漏洞，那就是說......還有"幕後大佬"。

先了解一下Getaddrinfo的作用和機制：

Getaddrinfo 的作用是將主機名和服務名轉化為套接字地址結構的，通常情況下會優化讀取/etc/hosts中的內容，再通過DNS域名服務進行通信。

再通過一個簡單的測試，具體看看：

到此，「元兇」現身，/etc/hosts文件內容缺失。

結案總結

"案件"成功告破當然少不了程序員探長的英明神武，不過也暴露出程序員的一些問題，自己的坑還得自己填。

記錄幾點，以供參考：

對於新開發環境，特別是嵌入式環境，系統鏡像里一定要保證好相關配置文件的完整性（這裡就是缺少/etc/hosts）。

/etc/nsswitch這個文件也會影響域名的解析，默認配置 hosts: files dns,這樣會先讀取/etc/hosts中的數據。

對於本地服務的能不用localhost就不用，用127.0.0.1更快。

聲明：本文為作者投稿，版權歸作者個人所有。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！