程序员探案之|程序员探案之 Python 和 Redis 的“第三者” 程序员探案之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更快。

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

“ 征稿啦”
CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。
如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。

————— 推荐阅读 —————