• Twitter架构是单IDC设计，从它递增的tweet id就可以看出，后来当面向@nk提问也得到了证实。
• 中美网络环境差异，单IDC和多IDC有很多设计上的不同
• 大部分参会人员未必能对英文演讲有深入理解及感悟，中文的演讲可以讲一些细节解释更透彻。
• Twitter对故障的容忍度大，国内公司对服务故障通常更敏感。因此国内架构师会考虑设计方案尽量简单可靠，服务需要更稳定。国外开发团队更倾向追求在工作中应用技术创新，因此会导致架构设计理念的不少差异。

演讲的slide如下，登录slideshare之后可以下载。

这里再补充在qcon演讲未来得及考虑成熟的一个方面，用户规模影响设计，具体是指用户数每上一个数量级，许多设计需要重新考虑。

10万用户级别

• 单服务器，前端、后端、cache、db在一起。

百万级

• db和cache单独部署服务器，db或按业务进行拆分(sharding)
• cache或使用一致性hash扩展。
• 前端后端还是在一起，但是根据业务拆分，每个业务可分配不同数量的服务器

千万级

• 开始重视架构设计，有专门技术架构师
• 需跨机房部署，前端在远程增加反向代理加速，数据库在异地机房使用slave数据库副本
• 后端拆分出来，系统内部需要远程调用，内部需远程调用协议。

亿级

• 架构更细分，或增加数据架构师，cache架构师，分布式架构师
• 数据库sharding碰到烦恼，开始考虑分布式数据服务
• 数据访问需要根据业务特点细分。
• 开发、运维、测量、调优具备有自己的专有工具。
• 所有服务需要地理多机房分布，具备IDC容灾设计。
• 服务可降级

上面的数字仅供理解“用户规模影响设计”，数字本身并无具体指导价值。

另外在slide中也提到了，目前新浪微博团队急需人才，对上面相关技术领域感兴趣的架构师及各层次开发人员(熟悉PHP，Java, C或数据架构任意一种)可随时跟我联系，工作地点为北京，联系方式见博客首页。

• Twitter架构图(cache篇)
• QCon Beijing qconbeijing全部演讲资料下载
• Twitter停用Cassandra原因分析
• Web 2.0技术沙龙设想
• 陈杰谈网游服务器的后端技术

由于农场游戏风靡全球，最近highscalability.com网站采访了美版开心农场FarmVille的Luke Rajlich，他介绍了FarmVille的部分架构资料(1)。

所有模块都是一个可降级的服务

For any web application, high latency kills your app and highly variable latency eventually kills your app.

由于大型的网络应用需要依赖各种底层及内部服务，但是服务调用的高延迟是各种应用的最大问题，在竞争激烈的SNS app领域更是如此。解决此问题的方法是将所有的模块设计成一种可降级的服务，包括Memcache, Database, REST API等。将所有可能会发生大延迟的服务进行隔离。这可以通过控制调用超时时间来控制，另外还可以通过应用中的一些开关来关闭某些某些功能避免服务降级造成的影响。

上面这点我也有一些教训，曾碰到过由于依赖的一些模块阻塞造成服务不稳定的现象。

1. 某Socket Server使用了ThreadPool来处理所有核心业务。
2. 不少业务需要访问内网的一个远程的User Service(RPC)来获取用户信息。
3. User Service需要访问数据库。
4. 数据库有时候会变慢，一些大查询需要10秒以上才能完成。

结果4造成3很多调用很久才能执行完，3造成2的RPC调用阻塞，2造成1的ThreadPool堵塞，ThreadPool不断有新任务加入，但是老的任务迟迟不能完成。因此对于最终用户的表现是很多请求没有响应。部分用户认为是网络原因会手工重复提交请求，这样会造成状况并进一步恶化。上面的问题根本是没有意识到远程服务可能会超时或失败，把远程服务RPC调用当成一个本地调用来执行。

解决思路一：RPC增加Timeout
解决思路二：将RPC改成异步调用。

另一分布式大牛James Hamilton谈到(2)上面这种做法就是他论文Designing and Deploying Internet-Scale Services中的graceful degradation mode(优雅降级)。

FarmVille其他数据

• FarmVille基于LAMP架构，运行在EC2上。
• 读写比例是3:1。
• 使用开源工具来做运维监控，如nagios报警，munin监控，puppet配置。另外还开发了很多内部的程序来监控Facebook DB, Memcache等。
• 到Facebook接口的流量峰值达到3Gb/s，同时内部的cache还承担了1.5Gb/s。
• 另外可动态调整到Facebook与Cache之间的流量，Facebook接口变慢时，可以利用cache数据直接返回，终极目的是不管发生了那个环节的故障，能够让用户继续游戏。

小结

尽管FarmVille公布了上面一些技术资料，凭借上面这些资料无法全部了解FarmVille的架构。但是所有模块都是一个可降级服务的概念值得设计大规模应用的同行参考。

Resource

1. How FarmVille Scales to Harvest 75 Million Players a Month
2. Scaling FarmVille

• Facebook平台设计(一)
• Twitter“鲸鱼”故障技术剖析
• Facebook平台设计(二)
• 构建可扩展的微博架构(qcon beijing 2010演讲)
• Twitter架构图(cache篇)

编程语言

首先要能跳出语言之争及语言偏见，架构师需要在中立的角度选择最合适团队的语言，避免在技术决策中加入过多个人喜好。在系统语言层面，主要可关注以下几种
Erlang, 会继续在小圈子内流行，业界应用Erlang技术最大的障碍不是Erlang技术本身，而在于缺乏这方面专业人才。
Scala, 和Erlang不同，Scala有成熟JVM及丰富的周边library，在异构系统中集成也很容易，新项目使用Scala风险很小，所以Scala在新语言中应该有较大的提升优势。
Go, 由于刚开始推出，不适合正式项目使用，2010年会稳步上升，可适当关注。
其他语言基本保持现状。

架构

LAMP中的Linux, Apache, MySQL会受到云计算中的App Engine模式的冲击，因为App Engine在分布式处理，可扩展性，稳定性方面都有很大的优势。 在App Engine模式中，MySQL作用会降低，退化成一种存储服务。而且App Engine的存储服务含义会更广泛，传统架构中的MySQL, Memcached, 及key value store在App Engine框架下都会以底层的服务方式提供。存储不再是软件，而是一种可靠服务，因此也会带来分布式存储相关技术的繁荣。

Web 2.0的设计中，Cache会成为一个中心元素。传统的web应用cache只是一个可选的锦上添花层，即使去掉，PHP + MySQL这种模式也可正常运行。但随着未来应用social化及realtime的趋势，从facebook及twitter的设计来看，cache已经从可选层成为核心层。cache设计的好坏直接决定架构的成败。

由于web发展的趋势会使应用更realtime化，体现到技术层面是HTML5(websockets)及类似技术具有更高的价值。但由于阻碍生产力的IE存在，HTML5无法一步到位。建议关注能解决HTML5及旧ajax自适应的框架。

网络模型方面，由于多核的硬件环境，轻量级的进程模型值得采用。如传统的C++ boost的asio, 各公司自己实现的coroutine, Erlang的process, go的goroutines, Java/Scala的Netty/Mina框架等。但C++框架的代码优雅性可维护性欠佳，性能也没有突出的优势，可关注后面几种方案。

分布式方面，Dynamo及Chubby的思想会逐渐在国内的项目等到更广泛的应用，架构师会逐步丢弃双写，双机心跳等山寨式的容错设计思想，可靠的分布式设计思想会更普及。

存储

2009是key value/nosql产品百花齐放的年代。到2010年，它们之中优秀的会脱颖而出逐步主流化，主流化的产品周边的工具会更丰富，运维相关经验也会更成熟。目前阻碍很多key value产品推广很大一个障碍是运维的顾虑，而不是它们本身的性能。究竟会是Memcachedb/Tokyo Cabinet/Redis这样的小巧软件走向主流，还是Cassandra这样的巨无霸更受欢迎，我们拭目以待。

• Web 2.0技术沙龙设想
• 2010年技术实践计划
• 分布式key/value store演讲草稿(一)
• Twitter架构图(cache篇)
• 构建可扩展的微博架构(qcon beijing 2010演讲)

• Cache分Page cache, fragment cache, row cache, vector Cache, cache命中率见图。
• Fragment cache存放了API各种请求格式的数据，包括XML, JSON, RSS, ATOM。
• 发表Tweets是先放入Kestrel, 再异步处理，Kestrel用的也是memcached协议。
• API requests: 550 r/s。
• POST tweets: 峰值：平时 80tweets/s, 奥巴马就任时达到 350tweets/s。
• Aggregator模块需要访问memcached multi get  数百个/s。
• Ruby on Rails前面还用了Varnish作前端反向代理。

参考资料：

• QCon London 2009: Upgrading Twitter without service disruptions
• Improving Running Components at Twitter (PDF slide)

• Twitter“鲸鱼”故障技术剖析
• MemcacheDB, Tokyo Tyrant, Redis performance test
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务
• Twitter系统运维经验
• Twitter停用Cassandra原因分析

场景
假定一个有状态的服务，可以理解成web或者socket服务器，每个用户在这个服务上登录后是有状态的，我们把它的状态连同其他加载到内存的用户数据统称用户session。由于session数据实时会变化，加上程序访问session频率大，几乎所有的操作都跟session数据相关，因此不适合放在远程memcached中

第一阶段
考虑到单服务器不能承载，因此使用了分布式架构，最初的算法为 hash() mod n, hash()通常取用户ID，n为节点数。此方法容易实现且能够满足运营要求。缺点是当单点发生故障时，系统无法自动恢复。

第二阶段
为了解决单点故障，使用 hash() mod (n/2), 这样任意一个用户都有2个服务器备选，可由client随机选取。由于不同服务器之间的用户需要彼此交互，所以所有的服务器需要确切的知道用户所在的位置。因此用户位置被保存到memcached中。

当一台发生故障，client可以自动切换到对应backup，由于切换前另外1台没有用户的session，因此需要client自行重新登录。

这个阶段的设计存在以下问题

• 负载不均衡，尤其是单台发生故障后剩下一台会压力过大。
• 不能动态增删节点
• 节点发生故障时需要client重新登录

第三阶段
打算去掉硬编码的hash() mod n 算法，改用一致性哈希(consistent hashing)分布
假如采用Dynamo中的strategy 1(可参看Dynamo: Amazon’s Highly Available Key-value Store, PDF, P216)
我们把每台server分成v个虚拟节点，再把所有虚拟节点(n*v)随机分配到一致性哈希的圆环上，这样所有的用户从自己圆环上的位置顺时针往下取到第一个vnode就是自己所属节点。当此节点存在故障时，再顺时针取下一个作为替代节点。

优点：发生单点故障时负载会均衡分散到其他所有节点，程序实现也比较优雅。

应用一致性哈希分布后若干问题
1.如何解决单点故障时候的session迁移？是否所有session都像Dynamo那样写入到多个节点(或双写)？如果双写所有的服务器需要消耗2倍的内存及更多CPU资源，所以优先不考虑双写方案。

2.如果不双写，则发生故障切换时，即使服务器内部自动帮用户切换节点不重新登录，都需要牵涉到大量session重建，会引起集群震荡。当然这里可以稍微优化，比如session按需建立，IDLE的用户可以先不重建。

3.当故障节点恢复时候如何处理？Dynamo的策略是故障期间所有的数据都属于hinted handoff, 就是备用机起业务代理作用，一旦故障机恢复就立即把所有临时数据从备用机拉回去，然后整个集群恢复正常流程。但由于本场景session数据比较笨重，而且牵涉到复制时存在并发变更，如果直接借鉴Dynamo的话则感觉切换成本过高，大部分开发人员倾向于继续用备用机处理该用户业务。如果恢复正常后不切换，则存在用户位置的不确定性，使用一致性哈希算出来的结果和用户实际所在的节点不同。需要顺着圆环往下找用户,效率很低。因此就有提议把所有用户所在的当前节点位置写入memcached。

5. 假如需要将位置写入memcached,那似乎一致性哈希算法又成了花瓶，完全可以由client在create session时候随机选取一个没有故障的节点, 然后把位置写入memcached, 某个节点发生故障时，client再另外选一个随机的，并把新的位置写入memcached, 所有用户所在节点的位置都通过memcached来存储，服务器之间实时的通讯也通过查询memcached来寻址。从实用的角度来看，这样似乎程序更简单。

因此，一致性哈希分布对于这个场景来说是无用的？

• MemcacheDB, Tokyo Tyrant, Redis performance test
• 多IDC的数据分布设计(一)
• Dynamo一个缺陷的架构设计(译)
• Paxos在大型系统中常见的应用场景
• 多IDC的数据分布设计(二)

Yahoo!的PNUTS是一个分布式的数据存储平台，它是Yahoo!云计算平台重要的一部分。它的上层产品通常也称为Sherpa。按照官方的描述，”PNUTS, a massively parallel and geographically distributed database system for Yahoo!’s web applications.” PNUTS显然就深谙CAP之道，考虑到大部分web应用对一致性并不要求非常严格，在设计上放弃了对强一致性的追求。代替的是追求更高的availability，容错，更快速的响应调用请求等。

1. PNUTS简介及特点

• 地理分布式，分布在全球多个数据中心。由于大部分Web应用都对响应时间要求高，因此最好服务器部署在离用户最近的本地机房。
• 可扩展，记录数可支持从几万条到几亿条。数据容量增加不会影响性能。
• schema-free，即非固定表结构。实际使用key/value存储的，一条记录的多个字段实际是用json方式合并存在value中。因此delete和update必须指定primary key。但也支持批量查询。
• 高可用性及容错。从单个存储节点到整个数据中心不可用都不会影响前端Web访问。
• 适合存相对小型的记录，不适合存储大文件，流媒体等。
• 弱一致性保证。

传统的数据库提供强一致性保证, 通常称为“serialization transaction”，保证调用时序的一致性。但在web应用中不是必须，比如用户A修改了自己的资料或上传了图片，他的好友B短时间不能立即看到并不是大的问题，通常的Web应用都可以接受。PNUTS像大部分分布式key/value系统类似，提供的是弱一致性的支持，也就是支持“最终一致性(eventually consistent)”。用户B最终会看到用户A的修改信息。

未够！但最终一致性并非可以适应所有场合，比如用户A修改了相册的访问权限，设置用户C不能访问，然后用户A又上传了新的图片，如果用户C处于另外一个IDC访问，如果图片数据先同步成功，而权限记录后同步的话，C实际上违反了A设置的权限而看到图片了。因此对于部分场合最终一致性是不够的。

2. PNUTS实现

2.1 Record-level mastering 记录级别主节点

每一条记录都有一个主记录。比如一个印度的用户保存的记录master在印度机房，通常修改都会调用印度。其他地方如美国用户看这个用户的资料调用的是美国数据中心的资料，有可能取到的是旧版的数据。非master机房也可对记录进行修改，但需要master来统一管理。每行数据都有自己的版本控制，如下图所示。

2.2 PNUTS的结构

每个数据中心的PNUTS结构由四部分构成

Storage Units (SU) 存储单元

物理的存储服务器，每个存储服务器上面含有多个tablets，tablets是PNUTS上的基本存储单元。一个tablets是一个yahoo内部格式的hash table的文件(hash table)或是一个MySQL innodb表(ordered table)。一个Tablet通常为几百M。一个SU上通常会存在几百个tablets。

Routers

每个tablets在哪个SU上是通过查询router获得。一个数据中心内router通常可由两台双机备份的单元提供。

Tablet Controller

router的位置只是个内存快照，实际的位置由Tablet Controller单元决定。

Message Broker

与远程数据的同步是由YMB提供，它是一个pub/sub的异步消息订阅系统。

2.3 Tablets寻址与切分

存储分hash和ordered data store。

以hash为例介绍，先对所有的tablets按hash值分片，比如1-10,000属于tablets 1, 10,000到20,000属于tablets 2，依此类推分配完所有的hash范围。一个大型的IDC通常会存在100万以下的tablets, 1,000台左右的SU。tablets属于哪个SU由routers全部加载到内存里面，因此router访问速度极快，通常不会成为瓶颈。按照官方的说法，系统的瓶颈只存在磁盘文件hash file访问上。

当某个SU访问量过大，则可将SU中部分tablets移到相对空闲的SU，并修改tablet controller的偏移记录。router定位tablet失效之后会自动通过tablet controller重新加载到内存。所以切分也相对容易实现。

Tim也曾经用MySQL实现过类似大规模存储的系统，当时的做法是把每条记录的key属于哪个SU的信息保存到一个字典里面，好处是切分可以获得更大的灵活性，可以动态增加新的tablets,而不需要切分旧的tablets。但缺点就是字典没法像router这样，可以高效的全部加载到内存中。所以比较而言，在实际的应用中，按段分片会更简单，且已经足够使用。

2.4 API访问

支持多种级别的数据访问API:

• Read-any 读取的版本有可能是旧的，返回本地IDC的数据，不检查最新版本，性能最好。
• Read-critical(required_version) 读取指定版本，用户修改资料之后调用返回比当前版本更新的版本，以保证当前用户看到的不是修改前的记录。
• Read-latest 强制读取最新，可能需要执行远程IDC调用。比如上面例子介绍的读取权限列表的调用。
• Write 比如更新用户资料
• Test-and-set-write(required version) 只有当记录属于指定的版本才执行write，比如更新用户积分等业务，这个调用有点类似以前介绍的atom操作。

Write调用示意图

3. PNUTS疑问

记录级别master的问题，比如master选取如何达到效率最佳，如何面对2个修改合并冲突?合并冲突据说是需要client自行来处理，

这篇Details on Yahoo’s distributed database提到的平均调用latency 100ms的问题。web应用通常对每次数据的访问最好在10ms之内完成，因为每个web页面实际上不止一个数据访问的调用，经常调用10次以上db的访问的页面并不少见，因此如果平均latency在100ms以上那势必影响页面加载速度。不过yahoo!的开发人员回复paper中的数据实际是一个老版本的测试，目前的版本，在实际生产环境的pnuts的latency会在10ms以下。

另外PNUTS为什么要用消息系统代替replication/undo log？有何优点？

4. PNUTS感悟

Web应用使用通用的存储服务是大势所趋，类似BigTable, Amazon Dynamo/SimpleDB这样的方案，但是目前除非使用Amazon提供的商用SimpleDB之外几乎没有通用的解决方案，每个公司甚至每个项目需要面对及考虑数据规模增大的问题。比如初步统计下国内研究可扩展数据存储及访问的项目就有

• 手机之家的数据访问层封装DAL 2.0
• 盛大陈思儒写的开源项目Amoeba，类似MySQL proxy
• 国内的Erlang geek @litaocheng 曾经对Dynamo paper深有研究，正在开发开源的erlang Dynamo实现e2dynoma
• 豆瓣的doubanDB，也是类Dynamo实现

当然上面几个只是冰山一角，大部分互联网公司都有自己的数据层分布及访问实现，只不过没有对外公开而已。架构师、DBA、程序员具备这方面的实践经验及技能当然是好事，但是如果业界能够有通用稳定的解决方案来解决大家的重复工作则对整个业界更佳。PNUTS虽然声称会开源，但是一直没有进一步消息。而且即使开源是是开放核心代码还是全部可用于部署的程序(比如YMB等)这也是一个问题。

当然，我不是第一个也不是最后一个考虑这个问题的，比如2006年Greg Linden就说I want a big, virtual database

What I want is a robust, high performance virtual relational database that runs transparently over a cluster, nodes dropping in an out of service at will, read-write replication and data migration all done automatically.

I want to be able to install a database on a server cloud and use it like it was all running on one machine.

参考资料

• [1] [Paper/PDF] PNUTS: Yahoo!’s Hosted Data Serving Platform
  
• [2] [PPT] PNUTS: Yahoo!’s Hosted Data Serving Platform

• 多IDC的数据分布设计(二)
• 多IDC的数据分布设计(一)
• 某分布式应用实践一致性哈希的一些问题
• Friendfeed的MySQL key/value存储
• Twitter架构图(cache篇)

由于这些组合技术含量并不是特别高，而且也无大的新技术来替代，所以大部分网站架构设计师的工作和10年前没什么区别，而且更糟糕的是，这些重复工作无法避免。新的一个应用，由于数据库表设计改了，所以所有的工作又得重来一次。因此是改变现状的时候了。

最近，Google的Luiz André Barroso and Urs Hölzle写了一个paper, The Datacenter as a Computer – An Introduction to the Design of Warehouse-Scale Machines (PDF) 提出可以将一个Datacenter视为一台计算机。

目前的操作系统在管理单机资源方面已经做到了相当完善，但还没有简单易用的软件体系将一Datacenter中的资源合理分配及利用，WSC也许是一个方向。Paper中比较了在WSC中，使用各种资源Latency, Bandwidth, Capacity的区别。

因此，将来的程序可能会是这样，由几个简单的PHP组成, 运行在一个Datacenter上，使用的内存可大可小，可以从1M到100G；使用的存储可以无限，使用的数据库无需关心切分逻辑。程序员需要做的工 作，只需把PHP写好。其他的工作，通过一个Datacenter OS来完成。与Google AppEngine的区别是，这个OS是Open的。

作者在上述paper中呼吁计算机科学家应该加强WSC这一新兴领域的研究，因此如果把LAMP这一记组合拳及相关经验理解为网站架构设计的话，或许不久的几年之后，这一定义将重新改写。我的Google Reader里面有上百篇加星的有关LAMP架构经验的文章，那时，它们对于大部分架构设计师不再具有借鉴意义。

Google的paper最早是从The datacenter is the new mainframe和The Datacenter as a computer看到的。

• 陈杰谈网游服务器的后端技术
• 做卓有成效的程序员
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务
• 从技术角度看Google Wave
• Twitter系统运维经验

I. Background

我们为什么需要一个独立的通讯层

对于服务器内部的通讯功能，已经有TCP提供可靠传输，已经有类似Apache MINA这样的框架来提供上层的封装，业务逻辑代码完全可以直接基于socket或MINA这样的框架来直接传送数据，我们为什么还需要包装一个独立的通讯层？

目前考虑到的原因有

• Connection pool作用。为了节点间更高的throughput, 通常两节点之间会使用n个固定连接来传输。n可设为CPU内核数大小。
• 多节点互相连接的处理。一个节点需要连接n个节点发送信息。如果这部分逻辑放在业务调用层来实现，业务层会变得臃肿。
• 处理自动重连逻辑，单个节点可以停用并重新启用。将这部分逻辑封装到通讯层，上层调用会更优雅。
• 服务器之间通讯很短时间内不稳定(比如10s左右的中断)的处理。如果IDC内部或IDC之间通讯不稳定会造成这种现象。我们希望这种短暂的中断，不要引起业务逻辑重新选择节点，造成大量数据迁移及cache重构带来的内部振荡。
• 海量数据传输最优化，大部分时间单个节点单向传输会>10k个数据包/s，独立的通讯层容易测试观察该环节是否存在瓶颈。

通讯层不做什么

• 序列化/反序列化，这个通常使用其他的框架或技术来做，比如protocol buffers, json等
• RPC, 我们不做rpc的事情，已有的各种RPC技术已经做得足够好了，如果有RPC需求，我们会使用其他现有的技术。

II. Code Review过程

逻辑介绍

首先由主程介绍了目前的数据流程，架构图及核心代码片断。比较核心的重发机制图示意如下

(Figure 1: 重发的流程)

过程说明：

• 每个数据包有个TTL值，TTL>0之前会一直重试发给同一节点。这主要避免短期网络中断带来集群内振荡。
• 如果正常的节点投递失败，则继续投递到backup节点。Backup节点由调用方在投递时候指定。类似在邮政寄快递，需要填写如果投递不到收件人怎么处理。通讯层只是根据投递地址表(list)来进行二次投递。
• 如果backup也失败，则返回调用方的callback FailureHandler。这点有点类似Erlang里面失败处理的思路。

听众提出的问题

• 重发那一段流程是否必要，因为TCP本身已经有重发逻辑。应用层再加上一层重发处理，原理上可以应付短暂的网络中断，但是实际运行过程中能否真正有很大效果。(目前运行的情况也没有很明确的数据来支持这一点)
• 目前一个节点需要连接的多个节点是静态配置的，即由程序启动时候决定，没有做自动发现及删除。目标节点是否可用由发送方自行判断。因此提出一个问题，backup节点选择由调用方来指定是否最佳？可否让通讯层自动协商，内部选择另一个同一类型的节点来做替代节点？但实现通讯层节点自动协商机制会增加程序复杂度。毕竟我们不是P2P程序，节点故障发生的情况很少。因此需要综合来权衡。
• 目前的结构处理几十到上百个节点的集群问题不大，如果要用在上千个节点的场合，有哪些环节需要调整？

其他提出的一些问题是针对具体代码写法的，由于不具有广泛借鉴意义，就不一一赘述。

• 某分布式应用实践一致性哈希的一些问题
• 多IDC的数据分布设计(一)
• 参加Erlang开发者大会一些记录
• Java垃圾回收调优
• Lua coroutine vs Java wait/notify

搜狐小纸条及聊天室是搜狐公司 ChinaRenTeam 自主研发的Web即时聊天工具它服务于所有搜狐用户, 并不断努力为更多网友提供便捷快速的聊天体验！
它直接在网页登录, 页面打开，直接聊天. 无需下载任何客户端和插件
请记住我们的网址：http://me.sohu.com
请记住我们的名字：搜狐小纸条!

这个系统由ChinaRen网站总监邹丹主导开发，它的系统核心架构在邹丹的网站描述如下

OnlineServer:
ChinaRen/SOHU小纸条系统核心

核心为3个小server系统：online2(在线系统业务逻辑)，userv(用户资料系统)，cserv(LRU缓存) 这三个子系统都是UDP+线程池结构，单进程+多线程。配备java接口，apache_mod的json和xml接口。 online2包括了大部分业务逻辑，包括，上线，好友系统，纸条系统。 userv包括设置用户各种属性，信息。 cserv是个大的lru缓存，用于减小磁盘IO。可以放各种信息块，包括用户信息，好友，留言等。 目前配备4台服务器（DL380，xeon:3G*2，SCSI:146G raid，Ram:2G），用户分布到4台服务器上，相互交互。服务器可以由1台到2台，到4台，到8台。 底层存储为文件存储（无数据库），用reiserfs。 配套系统： mod_online，两个版本，apache和lighttpd版本，用于页面上显示蜡烛人。请求量巨大，目前用lighttpd版本的mod_online。 放在sohu的squid前端机器上，运行在8080，大概8台，每台请求量大概500-800个每秒。蜡烛人在所有ChinaRen页面有ID的地方 显示用户是否在线。 目前这套在线系统，作为SOHUIM的内核原型。准备开发WEBIM系统，用户所有SOHU矩阵用户的联络。

总结一下:
门户的核心服务，要求是高效率，高密度存取，海量数据，最好还是低成本。不要用数据库，不要用java，不要用mswin。用C，用内存，用文件，用linux就对了。

据未经证实的消息来源了解到，Sohu的整套IM架构使用了150台左右的服务器。其中接入服务器，Web服务器，后台服务器各占1/3左右。

另外从邹丹的网站了解到，他还是一位QQ黑客，从2000年开始就曾经开发过数版的QQ显IP插件，以及Linux下实现QQ协议的Gaim(Pidgin)插件，可惜去了ChinaRen之后就停止了这方面的研究。从他的网站依稀可以看到2000年左右国内流行的个人主页的风格。

• Facebook平台设计(二)
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务
• python web.py使用flup lighttpd优化过程
• Twitter系统运维经验
• Twitter停用Cassandra原因分析

QCon全球企业开发大会（QCon Enterprise Software Development Conference）2009

QCon 2009北京大会全部演讲资料下载 (包含pdf, ppt 等格式slide)

永久链接：http://timyang.net/?p=136

Update 2010/03/01: 目前Dropbox已经被封，请自行想办法解决。(点这里可申请Dropbox账号)
Update 2010/05/11: 注意本文是2009年的演讲稿，QCon beijing 2010 的演讲稿官方尚未全部公布，部分下载见这里 http://www.cnblogs.com/coderzh/archive/2010/04/28/qcon-beijing-2010-ppt-slideshare.html

http://dl.getdropbox.com/u/1080311/suncaoxipingqconbeijing-090423084840-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/augmentumshaorongqconbeijing-090423085848-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/vmwareliyanbingqconbeijing-090423084914-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/ebayrandyqconbeijing-090423080359-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/pmlvjianweiqconbeijing-090423081337-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/uelvweideqconbeijing-090423091515-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/alipaychengliqconbeijing-090423080430-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/sprinthenrikqconbeijing-090423081310-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/openwebdylanqconbeijing-090423091545-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/youkuqiudanqconbeijing-090423080809-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/azurewuyananqconbeijing-090423084537-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/outsoftingqconbeijing-090423081254-phpapp02.ppt 
http://dl.getdropbox.com/u/1080311/qcon2009intro-090412122012-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/youdaodengyiqconbeijing-090423072448-phpapp02.ppt 
http://dl.getdropbox.com/u/1080311/freewheeldianeqconbeijing-090423080513-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/reusearchpanjiayuqconbeijing-090423083708-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/collabortivecommercevisionwangqconbeijing-090423084739-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/tddmaitianzhiqconbeijing-090423083637-phpapp01.ppt 
http://dl.getdropbox.com/u/1080311/QCon_Summary_Chinese.pdf 
http://dl.getdropbox.com/u/1080311/flexmajianqconbeijing-090423090123-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/geowebmoxiezhangqconbeijing-090423090510-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/enterprisejavamaoxinshengqconbeijing-090423085404-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/doubanhongqiangningqconbeijing-090423080457-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/taobaoyuexuqiangqconbeijing-090423085411-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/aboutarchzhouaiminqconbeijing-090423080807-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/archqualitygaohuantangqconbeijing-090423080658-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/newinfoqchinaintro-090412122754-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/siemensliweiqconbeijing-090423080616-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/amazonjeffbarqconbeijing-090423083948-phpapp01.pdf 
http://dl.getdropbox.com/u/1080311/ppwithagileyannhamonqconbeijing-090423081417-phpapp02.pdf 
http://dl.getdropbox.com/u/1080311/jrubyluogudaoqconbeijing-090423085418-phpapp01.pdf 

• 第一期广州技术沙龙预告
• 构建可扩展的微博架构(qcon beijing 2010演讲)
• Twitter架构图(cache篇)
• 陈杰谈网游服务器的后端技术
• Memcache mutex设计模式