程序员探案之 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更快。

声明:本文为作者投稿,版权归作者个人所有。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180722A0QD5T00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券