∞

前段时间因为生产上连接数的问题，手机被告警信息一波一波地袭击。问题的现象是，项目中每个进程都有一个全局的连接对象，一个对象对应一个socket连接。从输出日志可以看出这个对象有正常的建立连接和断开连接过程。但奇怪的是，通过netstat查看连接数，却超过了进程数，说明进程的连接对象并不是进程内全局唯一的。 于是给日志加上了线程id，再次运行发现，同一个线程（该项目使用的是多进程单线程）中对该连接对象进行了两次初始化，并且这两次初始化的对象id（通过内置的id()方法得出）不同。说明该连接对象并非进程内全局唯一的。 可是这是为什么呢？？？ 这个连接对象是作为模块内全局对象定义的，并且被同一

要是最初我知道会如此深入你，那一开始，我估计还是会那样漫不经心。 上个月呀，信誓旦旦的要看uwsgi代码。于是某日，真的沐浴更衣，准备潜心阅读。但一看到它长长的一下子拉不到底的uwsgi_sever结构，嗯，我怂了。为了不误入歧途，索性准备换一下，潜心看uwsgi官方文档。 所以看代码这种事，果然不能说得那么随意轻巧。为了舒适有效正确地阅读源代码，没有点对工具应用里里外外的了解，真的容易走火入魔。 于是做了个决定，今年内要把uwsgi中文版弄出来，当做是送给自己的跨2017礼物之一。这样一来，觉得uwsgi那一两百页文档，也可爱起来了。虽然进展缓慢，但是拌着文档看代码，似乎代码也没那么多

说明：当前使用的版本为uwsgi 2.0 目前在网络上能够找到的uwsgi源码相关的文档少之又少（当然，也不排除是官方文档大家觉得已经足够，或者是如我一般愚笨的人少之又少╮(╯_╰)╭）。在这个背景下，作为uwsgi小白的我，由于种种原因，决定自食其力。因此，准备开一个uwsgi源码阅读系列，结合官网，整理自己阅读uwsgi源码过程中的所思所想所得，作为不备之需。本系列没有deadline，不定时更新。 免责声明：由于本文作者（也就是我）目前尚未全面掌握uwsgi，C代码勉强能读懂，因此假若本文有错误的地方，请不要犹豫，不要客气，尽情在评论中提出！ 好了，废话说完了，进入正题︿(￣︶￣)

因为罗胖子的推荐，加之碰巧能拿到实体书，因此这个月有幸看了吴军老师的智能时代。机器学习和数据科学在python weekly总是占有不少的分量。这在侧面也看出了机器学习和数据科学（也可以说是书中提到的智能）在当下确实不容小觑。好吧，我不知道我会不会是书里的那2%，也许有一天时代的发展使得西乔漫画中的那只cat成为可能，那个时候，除了写代码，我还能做什么呢？或许在这之前，把自己的尾巴拖得尽可能长点，会是另一种自救之道？ 这个月最大的成就，应该是看完了Docker源码分析这本书了。书写得很浅显，作者考虑到了我这种go零基础的受众，算得上手把手的教你看代码了。我没用过docker，嗯，但是，此书之

简单的背景介绍 1. pika是AMQP 0-9-1协议的一个纯Python实现。本文使用的pika版本为0.10.0 2. AMQP 0-9-1提供了心跳机制，来确保应用服务层及时发现已崩溃的连接（以及完全无响应的对端）。心跳机制也能保证进程不被某些网络设备杀掉。 3. RabbitMQ的心跳机制（搬运自官网） * 使用心跳超时间隔(heartbeat timeout interval)。该值定义了经过多长时间，RabbitMQ和客户端库应该认为对端的TCP连接已经失活(dead)。该值是在客户端和RabbitMQ服务器在连接的时候协商决定的。必须配置客户端请求心跳。在RabbitMQ

先写写下个月的TO-DO吧： * Docker（目测是Docker源码分析，但可能会中途弃，who knows~） + Go。 * 继续看第一行代码和七周七语言 * 整理完DjangoCon US 2016 / PyCon Australia 2016 / PyCon 2016的Video List。 八月初的某一天晚上，心里异常的平静。于是淡定的打开了Android Studio。开始了Android的学习之旅。那天，我知道这个与之前无数次打开Android教程不同，是真的已经到了那个point，正如去年沉下心来看web一样。 我觉得学习这种事情，培训班是一种方式，视频教程是一种

由于这个月大部分时间都在查日志，查日志，查日志，因此大致扫了一眼sed，又扫了一眼awk，酷壳的简明教程真真是个好东西！ 幸运的是，之前虽然花了大力气在部署自动化上，花了老长老长的时间学用ansible，但关键时候，就显现出它的好来。磨刀不误砍柴工，古训不欺我。 这个月的增进甚微，而且磨磨蹭蹭才整理两篇代码阅读笔记。实在惭愧。不过好歹写出来了，写的过程中又去翻了一遍代码，温故知新。pssh也是最近用的频率top 10的工具之一，相较于ansible，它更加小但轻。有时间的话，可以好好写写。 这个月过得着实有点累。地铁时光只想发呆，连拿kindle出来的意愿都没有。但人在高压下，要么死掉，

基于Ansible 1.9.6。Github 概述 ansible-playbook是ansible用于执行playbook的命令行工具。而ansible-playbook位于ansible/bin/下。 好戏开始了 主流程：main(args) 1. 创建CLI选项的解析器，对选项进行解析 * ansible-playbook比ansible少的几个选项 * -o/--one-line：精简输出 * -t/--tree：将输出保存到该目录中，默认值：None * -P/--poll：如果使用-B选项，则用该选项设置poll间隔，默认值：由constant

基于Ansible 1.9.6。Github 概述 ansible是ansible用于实现ad-hoc的命令行工具。而ansible位于ansible/bin/下。 开箱了 主流程：__mian__ 1. 新建Cli()实例， 命名为cli 2. 调用cli.parse()解析命令行参数及其值 3. 调用cli.run进行某项操作。←_←这个是核心 4. 解析并展示结果。对返回结果中的results['contacted']的每一项，若有failed值或者，rc键值不为0，表示该操作失败；若results['dark']不为空，则表示执行该操作的主机有问题，死掉之类的。 一窥Cl

最近从无到有研究自动化上线。 流程大致有了，却在实现上发散思维收不过来。有时隐约感觉就差一点点便要融会贯通，但是总有某处似乎被封印了，死活打不通任督二脉得以精进。 后来一日，决定静心从头开始看入门书，看实现代码。那些说不清道不明的东西，就在攻略书中得以解答。 故总结，沉下心很重要，一本好书很重要。代码是最好的文档诚不我欺。 作为回馈整理，应该会写一写关于ansible等工具的代码阅读整理。还可以写写walle的实现分析。这里记一下。 某天下班回家，突然有点感慨。当年在HW的时候，几乎事事有计划，事事有流程，你不用想太多，跟着大伙的步骤，跟着既定的框架走便是。凡事有先例，有人可问，有人带