编程的碎碎念

nginx 中, sites-available 是放所有vhosts的配置文件, 而sites-enable 则是放你想要开启能够被访问的 vhost 文件, 一般是建立一个sites-available 对应的文件的symlink(软链接). 这样子做的好处是, 想关闭此 vhost 的访问时, 可以删除软连接即可, 恢复时重新创建, 可以避免把文件移来移去或者作备份等.

用 strace debug。 当一个程序在跑时，也许进入了死锁的状态，你无法得知。 这时可以用 strace 来看这个二进制程序在 linux 上的系统调用，确认他是否有在运行。 而我 debug 时，通过这个确认了一个程序停留在 futex 的调用，futex 是 linux 进程资源冲突的一个间接层。 以前都进程争夺资源，都需要从用户态（用户态就是普通程序正常运行的地方）转到内核态（内核态才能 调用内核的 API，保证了内核的稳定性，用户程序的崩溃不影响内核），而每次由用户态转到内核态，上下文切换是一个耗费资源的操作。 于是就在用户态做了一个简单的锁，发现冲突时才转到内核态处理。

哈希表的业界常用做法： 发生冲突时，链表开放法（z 这个数据结构书常说），另外一个是 先根据数据量给 hash 得到的 key 预分配桶（其实就是一个定序的数组），这个桶就存冲突的值，桶满了的话，就全部放到 一个大数组中。 链表开放法优点是空间少，但冲突变多时，会退化成一个 Om 的算法（m 是链表的大小）因为要遍历这个链表。 而预分配桶的做法是空间换时间。 因为预先有桶存，遍历的时间可以预计是 O1 （因为数组数量是固定的），预估的好，也很难全部退化到一个大数组中寻找

ubuntu 默认会把 coredump 转发到 apport 这个胶水层，而它又默认把 apport 关掉的。。 所以docker 镜像选择 ubuntu 做系统时，要注意把 appportr 打开 https://wiki.ubuntu.com/Apport

跟 合作的公司 对接文档，踩了无数个坑。总结一下经验：

1. 不要相信任何人的文档。。如果有代码示例，文档做背景，用代码来理解，一切按代码来。
2. 失败时，搭环境跑他们的代码
3. 涉及到 json encode， 一定要注意不同语言的 encode 方法（key-word 的顺序）是不一样的，问清楚如何排序（我遇到的是没有任何说明，而 node 跟 PHP 的刚好是排序一样）
4. http 协议类型， www-url-encode, json 还有 text。。。往往也是不写的，要问清楚。。。。。
5. 写单元测试。这次我已经很聪明的按照文档的例子写了几个确认 签名，加密，解密正确性的例子了，对我帮助很大。。起码跑一下测试就可以，不用再模拟一些数据

关于虚拟机的网络，有三种网络模式可选：

1. NAT 模式
2. 此模式会将宿主机作为网关，虚拟机出口跟进口的网络包都要经过虚拟机管理软件做 NAT 转换；因为宿主机很多时候并不会开放太多端口，所以需要注意宿主机的端口有没有开放，iptables 可以查看。
3. 桥接模式
4. 此模式将虚拟机当做是一台独立的主机，有自己的内网 ip 跟外网 ip，与宿主机彻底分开。我推荐使用此模式，可以减少很多麻烦。
5. 主机模式
6. 此模式限定虚拟机尽可以与宿主机通信，两者组成一个局域网。

mongo 3.4 的 objectid 生成方式改了:

• 从 4 byte unix 秒, 3 byte 机器标识, 2 byte 的 process id, 3 byte 的累积计数器 改成
• 4 byte unix 秒, 5 byte 的随机数, 3 byte 的累积计数器

可能之前3 byte 机器标识跟2 byte 的 process id 标识范围不够大，不如来个5byte 的随机值

http://119.29.78.110/

遇到一个小问题，让我对 objectid 印象深刻。 我抓的杂志，默认用 objectid 排序应该是没问题的，但是刚刚发现，新抓取的几本杂志顺序不符合预期. 比较下来有些迷糊了, 最后才发现, 原来我抓取的时候是从最新的杂志抓到1995年, mongo默认从小到大排序, 因此一切符合预期. 而当我一个月后, 抓取到最新的杂志时, 他们的 objectid 就是最大的.. 所以抓取的逻辑要从最旧到最新抓取, 才是对的.