作者文章: Fenng

《软件随想录》(More Joel on Software)

前一段时间提前读了几章 Joel Spolsky 的《软件随想录》（More Joel on Software）。这是一本能带来新思维、能改变技术官僚思维惯性的图书。

这本书的内容覆盖了一个 IT 人将要面临的方方面面，不管是否认可书中的观点，不可否认的是 Joel 的见解的确是颇为独到的，有些话语堪称一针见血，这家伙的写作风格也是从不隔靴搔痒。我觉得在这本书中传递给我们的是一种理念–如何把技术效能发挥出来，如何把技术的价值最大化。而 Joel 本人也用自己的亲身经历来证明他所说的并非是做不到的事情，实际上，他创建的 Fog Creek Software 就是一家很酷而且颇为成功的公司。

《软件随想录》不是一本讲技术的图书，但是我相信如果认真读过之后会发现对自己的技术提升会最大。另外，有必要强调的是Joel 对人才的论述，如果要招聘真正牛的技术人员，那么自认为理解技术人员的管理者都应该读一下这本书，某些章节场景或许会让你觉得脸红，哦，原来以前自己所谓的一些招聘手段是多么的低级而低效，我们有太多的理念需要转变。

今天晚上还给 Yupoo 的刘平阳推荐了这本书。个人觉得，无论是一线技术人员还是 IT 公司的的管理者，或是创业团队的成员，都应该读一下这本书，相信能给你很多启迪。

八卦一下：Joel Spolsky 给自己起了一个中文名字：周思博，不知道他知道在中国有这么多粉丝不?

好久没有读到这么有趣的书了，也要感谢译者阮一峰的辛苦工作，他也是个有趣的家伙。

–EOF–

数据分片(Sharding)设计问题一例

Question：假设一家 C2C 网站，数据库中某表存储买卖双方交易的数据信息，对于一条交易来说，买卖双方数据具有一定程度的耦合性，比如卖家的状态更新对应买家的状态也会更新，对于一个中大规模的电子商务网站，架构师在设计中如何考虑数据分片的问题（假定该表随着数据的膨胀必须拆分)?

Answer：对于一个中大规模的电子商务网站，随着网站的不断发展，其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于 C2C 类型的网站，由于交易记录不容易进行水平的数据分割，因此对于这样的应用处理要再进行细分：

买卖双方交易的信息，具备较高的时效性，即交易全部完成后就不会再有更新，因此这部分数据可以与正在交易中的数据区分开来，并可以单独分表，定时归纳。具体的做法可以采用水平分割的数据分片技术，比如可以根据用户号码段范围进行切片，把不同的群体划分到不同的 DB 上，这样可以很好的进行横向水平扩展（Scale Out）。它可以很好的突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
对于正在交易中的数据，主要根据时间进行分表。如果分的更细，则可以分三个表，但是这样在事务保证方面则要复杂很多，不建议这样做。

这个问答是《程序员》杂志架构师接龙栏目的第一期的内容。提问者是我，回答者是腾讯研发总监王速瑜先生。其实我抛出问题后当时还真不知道接龙的是哪位，只是知道会是百度或是腾讯的朋友来回答，当然我也对这两家的数据处理方式都是比较感兴趣的。最后刊登的内容或许让很多人觉得不过瘾 — 如果能更详细一点就好了(毕竟还有其他问题呢)。不过能够引发思考就好，这也是这个栏目的初衷吧。

对这个问题或许可以补充的是，切分或许还算是容易的事情，但是切分后用户对数据的查询多少是有点麻烦。一旦要查询历史交易信息，则必须考虑跨多个数据分片获取数据并排序的问题。交易中的数据与交易完成的数据是否做切分，是有必要根据自己的实际情况仔细衡量。要注意如对交易中的活动数据单独存放的一个表中，则还是不可避免的要产生 I/O 热点问题，而且，这个表实际上变成了一个数据队列(新的瓶颈)–新生成的交易进来，完成的交易删除或归档。这样产生的双重 I/O 压力不容忽视。

当然，这个问题的前提限制了回答的发挥，其实在设计初期也可以考虑买家信息与卖家信息分别放入不同的表中，然后对这两种属性的表再进行切分，这也是可选的途径，这样的开销是每笔交易会重复存储一条记录，而记录的变化也要在两个表中更新。对数据的一致性维护有一定的挑战。这似乎是个只带来额外开销的办法？其实也有益处–索引的设计起码会更简单一些，而用户对交易记录的定制查询也会更加方便。

数据分片(或 Sharding) 现在几乎是每个网站架构师都必须要考虑的基础问题。多数情况下，分片的粒度和方式取决于业务，慢慢地快变成可意会不可言说的话题了，你有什么建议或意见不妨留言说说。

–EOF–

为了避免误导，对于数据量不大的站点，首选如何利用好 Cache 吧，分片只是手段，不是目的。

OpenDNS 的统计(Stats)服务的实现

对国内互联网用户来说，OpenDNS.com 这个服务在技术圈子里还是有些知名度的，当然这要归功于国内电信服务商对域名的无耻劫持行为。

OpenDNS 的员工 Richard Crowley 在 Velocity 2009 上和与会者分享了关于 OpenDNS Stats 服务的实现。当时的数据是每天有 140 亿次的 DNS 查询，而现在从公开的数据看，每天已经超过 180 亿次查询。这个 PPT 的内容就是讲 OpenDNS 是如何处理并统计这些查询记录的。

主要的策略分两步，第一步，根据网段切数据；第二步，聚合与存储。体现到 DB 层面是给每个网段单独分配一个表，尽可能的让表更小，让主键更小。

选择合适的方式存储域名。如果表使用 auto_increment 字段做主键是不太合适的做法–不同的引擎都有或多或少的锁问题，OpenDNS 采用域名的 SHA1 摘要值用来做域名的主键(SHA1 是20个字节，倒也不算浪费空间)。用了两台机器，每台 48GB 左右的存储空间，另外通过跨在 8 台机器上总共 28GB 的 Memcached 来避免对数据库的读操作。

对于聚合数据的进程会产生内存溢出的问题，采取的办法是清空内存，重启进程（而不是释放内存)的思路。利用了 supervise 这个小工具来做到。这地方其实值得商榷。

开始曾发现 80% 的 I/O 等待表的打开与关闭上。通过 Strace 发现存在大量的 open() 与 close() 调用。通过設置 ulimit -n 600000 解决(关于 ulimit 参数的意义参考。这意味着 OpenDNS 用了大约 60 万个表(网段)！(?) 这的确是比较极端的做法。

而在 DB 存储引擎的选择开始用了 MyISAM ，也是不合适的，通过迁移到 InnoDB 速度得到了很大提升。这似乎是缺乏评估与规划的表现，或许 OpenDNS 在这方面并非十分擅长。

(Copyright by Richard Crowley )

上图从右向左看，查询日志通过 rsync 同步到 Stage 1 的服务器上（位于旧金山)，根据查询到的域名把查询日志映射为中间文件，然后把数据文件同步到 Stage 2 的服务器，启动聚合进程把中间文件读入，修剪(Pruning)进程把拼装好的 SQL 语句写入 DB。整个步骤其实暗合 MapReduce 的思路。虽然不是严格的 MapReduce 实现。

听说国内提供类似服务的 DNSPod 因为上次的暴风长老事件受到了广泛瞩目，前不久成立了公司旨在专门提供智能 DNS 服务。不知道每天查询量有多大。[Updated: 见楼下 DNSPod 站长的回复 “DNSPod请求数每天20来个亿” ]

–EOF–

几句题外话：因为逐渐远离一线技术环境，为保持对技术的兴趣，每天多读一些 PPT 也是有乐趣的事情，或许一年没有敲多少条命令，但是看的 PPT 恐怕没有几个人比我多。看到一些还算有趣的 PPT 就做点笔记和大家分享。或许对人有用呢。

Updated：Google 开始提供 DNS 了。Google Public DNS

还可以参考一下这篇：OpenDNS MySQL abuses，另外，Richard Crowley 已经在2010 年2月份从 OpenDNS 离职…

再跟 Flickr 学习网站运维经验

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长：

24 TB 的 MySQL 数据
每秒钟 MySQL 有 3.2 万次写操作
每秒钟 MySQL 有 12万次读操作
图片容量 6 PB
每天要用掉 10TB 存储
超过 15000 个服务监控点

在 2004 年的时候，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手”裁”掉机器，也会省钱嘛…

Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：

使得机器自动构建 (Teach machines to build themselves)
使得机器自监控(Teach machines to watch themselves)
使得机器自修复(Teach machines to fix themselves)
通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 … “信息查找”，是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。

–EOF–