解剖 Facebook [5]说到 Facebook 的技术，很多人摇头
Facebook CEO，扎克伯格（Mark Zuckerberg），这几天低调访华。今天（2010/12/20）去位于北京上地的百度总部，拜会百度 CEO 李彦宏，并共进午餐。
说到 Facebook 的技术，很多人摇头，认为 Facebook 技术无亮点。
图一。Facebook CEO 拜会百度老总李彦宏，2010/12/20。
技术有无亮点，关键在于评价标准。Google, Yahoo, Microsoft 等等高科技企业，强调学术与产业零距离。这些企业的员工发表过很多学术论文，不仅数量多，而且水平高，确实为人称道 [1,2,3]。更不要说 IBM, Intel, Sun Microsystems 等等老牌高科技公司，所著更丰，汗牛充栋。
能不能用学术论文来评价企业的技术含量，这个问题值得商榷。虽然 Facebook 不以学术论文著称，但是它的技术仍然可圈可点。
想了解计算机领域的学术前沿，一个捷径是选修计算机专业的博士生课程，尤其是听名校名教授的课。美国名校的博士课程，大多以 “高等（Advanced）” 为前缀，很容易识别。例如，想了解系统架构设计的学术前沿，不妨听听 “高等操作系统” 课程。
美国名校的 “高等” 课程，往往没有课本。教授在上第一节课的时候，给博士生们一个清单，清单上有 20 多篇论文，每篇论文涉及一两个热门的前沿的学术问题。在上课前，博士生们预先阅读指定的论文，上课时学生们相互讨论。教授往往与学生们围坐在一起，倾听， 并发现对同一个问题的不同观点，引导辩论，间或略加点拨。
同一门课，不同大学不同教授选择的论文，往往不一样。论文的选择，在一定程度上反应了教授的学术视野的高下。做名教授的学生的好处，在于领袖挥手我前进，少走弯路，早出成果，出大成果。
如果能够被名校录取，亲耳聆听名教授的点拨，当然三生有幸。即便没有被名校录取，照样可以获得名校的教育。美国各大名校强调开门办学，几乎所有 “高等” 博士生课程所选用的论文，都公布在大学网站上。不管你在世界的哪一个角落，都可以与名校的博士生们阅读相同的论文。
图二。2010 年美国计算机专业前 10 名校 [4]。
在系统架构设计领域，我个人比较喜欢读 Eric Brewer 教授推荐的论文。Brewer 是 UC Berkeley 的计算机系教授。2010 年，UC Berkeley 与 CMU，MIT 和 Stanford，四所大学并列美国计算机专业第一，见图二。
UC Berkeley 的终身教授，是很多人梦想终身的荣誉。Eric Brewer 年仅 32 岁就拿到了 UC Berkeley 的终身教授，即便不是史无前例，也算得上凤毛麟角。不久以后，他又被选为美国工程院院士 [5]。
Brewer 不仅学术精湛，同时还创办企业，1996 年他与自己的学生创办 Inktomi 公司，一度辉煌。不过，Inktomi 过份注重技术，而拙于经营，最后频临破产，被 Yahoo! 收购[6]。虽然 Inktomi 经营失败，但是 Brewer 教授在实践 “学术与产业零距离” 方面，身体力行，堪称楷模。
Brewer 教授推荐的论文，不仅学术先进，而且贴近产业现实，对于实际工作有直接的指导意义。
几周前，有幸与国内某大型电子商务网站的技术负责人交流。他提及他们正在用云计算技术，改造整个后台系统。我问，你们用什么办法网站，去记录海量的实时买卖 交易？他答，用开源项目 Hadoop 中的 HBase 分布式数据库 [7]。我又问，电子商务作为在线服务，对于数据读写的速度要求很高，通常在几百毫秒以内。HBase 能不能满足这种实时限制？答，系统正在开发中，速度目前不详，有待测试。我建议他去读一篇论文，重新考虑 HBase 是不是合适的方案。
2009 年秋，Brewer 教授开设 “高等计算机系统” 课程，课程必读论文中，有一篇的题目是，“Dynamo: Amazon’s Highly Available Key-Value Store” [8]。不仅 Brewer 选择了这篇论文，CMU 和 Stanford 的 “高等操作系统” 课程，也不约而同地选用了这篇论文 [9,10]。
我推荐的论文，就是这一篇。从事网站系统架构设计的同行，或许都应该读一读这篇论文 [11]。不仅可以启迪思路，而且有助于少走弯路。
Dynamo 这篇论文的作者之一，是 Amazon 的 CTO，Werner Vogels。本文谈的是 Facebook 的技术，为什么走题去谈 Amazon 的技术呢？
Facebook 开发了一个分布式数据库软件，叫 Cassandra，并开源 [12]。Cassandra 的设计原理，源于 Amazon 的 Dynamo 和 Google 的 Bigtable [13]。虽说 Cassandra 没有太多技术原创，但是 Facebook 正在开发前沿技术，这一点毋庸置疑。
发表论文，分享思想，固然值得尊崇。开源软件，分享成果，更加直接造福人类。Facebook 不仅开源了 Cassandra，而且还开源了 Thrift 等等其它技术先进的软件。Facebook 的技术，很有亮点。
Reference,
[1] Publications by Googlers.
http://research.google.com/pubs/papers.html
[2] Publications by Yahoo!
http://research.yahoo.com/publication
[3] Publications by Microsoft research.
http://research.microsoft.com/apps/dp/pu/publications.aspx
[4] Top Computer Science Schools, Ranked by US News & World Report, 2010.
http://grad-schools.usnews.rankingsandreviews.com/best-graduate-schools/top-computer-science-schools/rankings
[5] Eric Brewer, CS Professor of UC Berkeley.
http://en.wikipedia.org/wiki/Eric_Brewer_%28computer_scientist%29
[6] Introduction to Inktomi Corp.
http://en.wikipedia.org/wiki/Inktomi_Corporation
[7] HBase is an open-source, distributed, versioned, column-oriented store modeled after Google’ Bigtable.
http://hbase.apache.org/
[8] Advanced Topics in Computer Systems, UC Berkeley CS course syllabus.
http://www.cs.berkeley.edu/~brewer/cs262/
[9] Advanced and Distributed Operating System. CMU CS course syllabus.
http://www.cs.cmu.edu/~15712/syllabus.html
[10] Advanced Readings on Distributed System, Stanford CS course syllabus.
http://www.stanford.edu/class/cs244b/
[11] Dynamo: Amazon’s Highly Available Key-value Store.
http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf
[12] The Apache Cassandra Project brings together Dynamo’s fully distributed design and Bigtable’s ColumnFamily-based data model.
http://cassandra.apache.org/
[13] Cassandra: Open Source Bigtable + Dynamo
http://www.slideshare.net/jbellis/cassandra-open-source-bigtable-dynamo
图一：Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/Cloud/Zuckerberg-1.png
图二：Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/Cloud/TopCSSchools2010.png
Redis新的存储模式diskstore
Redis作者antirez是一个非常勤奋的开发者，在Redis性能已经非常惊人的情况下持续不断开发新的特性，比如从新的cluster源代码看到，作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化，在Web 2.0时代，Memcached已经非常不够用，技术人员需要考虑做很多额外工作才能让Memcached适应新的变化和需求。
antirez在1月5日Google Groups发表了一篇Redis diskstore文章，对Redis VM方式进行了反省，思考是否有更好的方式来大数据的Redis访问。
a few months after VM started to work my feeling about it started to be not very good… that VM was not the way to go for the future of Redis
适合Web 2.0数据访问最佳的方式就是完全基于内存，比如用Memcached或者Redis snapshot方式。但是更多的业务场景是数据规模会超过RAM容量，因此有几种不同的设计模式。
1. VM方式。将数据分页存放，由应用(如Redis)或者操作系统(如Varnish)将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中。应用实现VM缺点是代码逻辑复杂，如果业务上冷热数据边界并不分明，则换入换出代价太高，系统整体性能低。不少抢鲜的网友在微博上也反馈过使用VM种种不稳定情况。操作系统实现VM的缺点前文Redis几个认识误区已经有介绍。
2. 磁盘方式，所有的数据读写访问都是基于磁盘，由操作系统来只能的缓存访问的数据。由于现代操作系统都非常聪明，会将频繁访问的数据加入到内存中，因此应用并不需要过多特殊逻辑。MongoDB就是这种设计方式。这种方式也有一些已知的缺点，比如操作MMap写入磁盘由操作系统控制，操作系统先写哪里后写哪里应用并不知情，如果写入过程中发生了crash则数据一致性会存在问题。这个也是MongoDB饱受争议的单机Durability问题，
MongoDB is not designed around single-server durability, but rather multi-server durability.
不过MongoDB自己并不觉得这是一个问题，他们的意见是，在目前时代有必要考虑单机完全可靠吗？有必要吗？
3. 硬盘存储 + cache方式。实际原理和mysql+memcache方式类似，只不过将两者功能合二为一到一个底层服务中，简化了调用。
在上面几种方式中，除去VM，antirez觉得MongoDB方式也不太适合，因此选择了disktore方式来实现新的磁盘存储，具体细节是
1) 读操作，使用read through以及LRU方式。内存中不存在的数据从磁盘拉取并放入内存，内存中放不下的数据采用LRU淘汰。
2) 写操作，采用另外spawn一个线程单独处理，写线程通常是异步的，当然也可以把cache-flush-delay配置设成0，Redis尽量保证即时写入。但是在很多场合延迟写会有更好的性能，比如一些计数器用Redis存储，在短时间如果某个计数反复被修改，Redis只需要将最终的结果写入磁盘。这种做法作者叫per key persistence。由于写入会按key合并，因此和snapshot还是有差异，disk store并不能保证时间一致性。
由于写操作是单线程，即使cache-flush-delay设成0，多个client同时写则需要排队等待，如果队列容量超过cache-max-memory Redis设计会进入等待状态，造成调用方卡住。
Google Group上有热心网友迅速完成了压力测试，当内存用完之后，set每秒处理速度从25k下降到10k再到后来几乎卡住。 虽然通过增加cache-flush-delay可以提高相同key重复写入性能；通过增加cache-max-memory可以应对临时峰值写入。但是diskstore写入瓶颈最终还是在IO。
3) rdb 和新 diskstore 格式关系
rdb是传统Redis内存方式的存储格式，diskstore是另外一种格式，那两者关系如何？
- 通过BGSAVE可以随时将diskstore格式另存为rdb格式，而且rdb格式还用于Redis复制以及不同存储方式之间的中间格式。
- 通过工具可以将rdb格式转换成diskstore格式。
当然，diskstore原理很美好，但是目前还处于alpha版本，也只是一个简单demo，diskstore.c加上注释只有300行，实现的方法就是将每个value作为一个独立文件保存，文件名是key的hash值。因此diskstore需要将来有一个更高效稳定的实现才能用于生产环境。但由于有清晰的接口设计，diskstore.c也很容易换成一种B-Tree的实现。很多开发者也在积极探讨使用bdb或者innodb来替换默认diskstore.c的可行性。
在Redis几个认识误区中也介绍过，Redis优势是丰富的内存数据结构，这个特性和数据持久保存天生是矛盾的，如用diskstore保存大list/set(如排行榜)性能会很差，每修改一个list元素则需要将整个大list重新保存，开销比使用传统RDBMS高很多。
用MongoDB的一句设计哲学结尾
Databases are specializing – the “one size fits all” approach no longer applies.
................................................................
