前两天，我在微博上推荐了一篇朝花夕拾的文章：The story of one latency spike，文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题，细细读来受益良多，不过我并不打算详细介绍那篇文章的细枝末节， 本文只摘录一个点：
When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet loss since the SYN packets are usually retransmitted at times 1s, 3s, 7s, 15, 31s.
为什么是 1 秒、3 秒、7 秒、15 秒、31 秒？说来惭愧，我以前从没有注意过 SYN 重建时的时间特征，知耻而后勇，正好借此机会来一探究竟。
最近使用 pip 的时候感觉速度太慢了，感觉有必要改成豆瓣的豆瓣的镜像，可我记不清 pip 的配置文件路径了，当然可以用搜索引擎查询一下，不过还有更快的方法：strace！
shell> strace -eopen pip 2>&1 | grep pip.conf
open("/etc/xdg/pip/pip.conf", O_RDONLY) = ...
open("/etc/pip.conf", O_RDONLY) = ...
open("/root/.pip/pip.conf", O_RDONLY) = ...
open("/root/.config/pip/pip.conf", O_RDONLY) = ...
如此一来，我们很容易就能看出配置文件的路径，甚至还能看出多个配置文件的加载顺序。此外，通过此技巧还能看到一些意想不到的信息，比如 nginx 的例子：
shell> strace -eopen /usr/local/nginx/sbin/nginx 2>&1 | grep conf
open("/usr/local/nginx/conf/nginx.conf", O_RDONLY) = ...
open("/usr/local/nginx/conf/mime.types", O_RDONLY) = ...
open("/etc/resolv.conf", O_RDONLY) = ...
open("/etc/nsswitch.conf", O_RDONLY) = ...
除了 nginx.conf 等常见的配置文件，我们还可以发现其加载了 nsswitch.conf 等不常见的配置文件，通过研究这些细节，可以让我们更透彻的理解问题。
如果想学会一门新语言，不仅要多读文档，还要多看别人写的代码，更要强迫自己用新语言多写代码。我在学习 Golang 之前，读过好几本相关的书籍，不过总感觉没真正学会，于是我决定动手用 Golang 写一个能用的工具试试，因为 Golang 最大的优势就是 goroutine 和 channel，所以我觉得实现一个简版的 ab（Web 压力测试工具）应该是一个不错的选择，用 Golang 磕磕绊绊总算实现了预想的功能，能够计算 Requests per second 和 Time per request 的值，不过总感觉写出来的代码不够漂亮，于是我又找来 hey 的代码前后读了几遍，然后结合自己的理解临摹了一遍，感觉总算是入门了。
系统写好了，能不能顺利上线？一般来说我们需要做一些压力测试来判断。比如系统预计每天一百万的接口访问量，并且访问时段主要集中在早八点到晚八点，那么平均下来 RPS 大约是 22 次左右，不过用户的访问量通常不会很平均，假设峰值流量是平均流量的 3 到 5 倍的话，那么我们可以推断出项目要想顺利上线，RPS 至少应该达到 66+ 次，110+ 次更好。由此可见上线前用压力测试工具测试 RPS 是一个很重要的环节。
本文说的排序并不是指「冒泡」之类的技术概念，而是一个业务相关的问题。
实际上，关于「如何抓取汽车之家的车型库」，我已经在「使用 Mitmproxy 分析接口」一文中给出了方法，不过那篇文章里讲的是利用 API 接口来抓取数据，一般来说，因为接口不会频繁改动，相对 WEB 页面而言更稳定，所以通常这是数据抓取的最佳选择，不过利用 API 接口来抓取数据有一些缺点，比如有的数据没有 API 接口，亦可能虽然有 API 接口，但是数据使用了加密格式，此时只能通过 WEB 页面来抓取数据。
虽然百度的口碑并不好，但是不可否认的是，它一直是中文搜索中的霸主，所以对大多数中小型商业公司而言，都对百度蜘蛛的抓取行为予以放行，不过还有很多非法的蜘蛛，它们会通过 User-Agent 把自己伪装成百度蜘蛛，此时如果单纯以 User-Agent 来判断是否是百度蜘蛛就不合适了。虽然网上能找到很多现成的百度蜘蛛 IP 段，但是并不能确认它们的准确性，所以我打算自己收集，进而甄别真假百度蜘蛛。
之所以要实现 Schemaless，主要是因为在线 DDL 有很多痛点，关于这一点，我在以前已经写过文章，没看过的不妨看看「史上最LOW的在线DDL解决方案」，不过那篇文章主要以介绍为主，并没有涉及具体的实现，所以我写了一个 Laravel 的例子。