深入了解扩展的 5 个阶段

Christopher Smith 在上月举行的 Scale11x 上进行了题为“扩展的五个阶段”的演讲，演讲中他分享了自己对实现Web 应用扩展和解决扩展中的问题的见解。Christopher 举了在各阶段实现扩展的例子，同时他还对通过添加或优化良好定义的组件来改善Web 应用整体扩展做了讲解。他从负载均衡讲到UDP 协议的优化使用，带领听众经历了一段集知识性和娱乐性于一体的旅程。

最重要的基础扩展架构应具有在负载均衡器后面添加Web 应用服务器的能力。负载均衡器能够通过在应用服务器间划分请求和会话的方式进行web 应用的线性扩展。该技术相当于通过增加应用服务器进行线性扩展，然而这只不过是延缓了不可避免的 C10K 问题，因为这种方式没有增加单个请求的响应能力。

Christopher 介绍了 web 应用前置的缓存系统如何通过处理读取操作来支持扩展：联合使用多重缓存系统使扩展最大化。Memcache 服务器（或类似的服务器）可以在内存中存储数据从而使应用服务器能够快速检索。还可以在负责均衡器之前放置反向代理为缓存的资源提供服务。最后，可以使用内容分发网络（CDN）使缓存的资源更靠近终端用户。不过缓存在写数据方面有它自身的限制。

优化的持久性框架能够将扩展写入的能力带到扩展中的新阶段。Christopher 认为，对大部分人来说，能够成功运用这一阶段和之前提到的内容就足够了。选择合适的 SQL 或 NoSQL 数据库来匹配应用数据结构将显著地增强扩展性。并发读 / 写能力将提高写操作的吞吐量和响应能力。最后如果你能够“在 ACID（特别是 C 和 D）上耍点手腕儿”，你就可以将更多的写操作提速。

这些扩展技术的基础是使 web 应用读 / 写数据的延迟最小化。Christopher 分享了计算机上不同操作的延迟时间：

• L1 缓存引用 - 0.5 ns
• 分支预测失败 – 5 ns
• L2 缓存引用 – 7 ns
• 互斥锁 / 解锁 – 25 ns
• 主内存引用 – 100 ns
• 使用 Zippy 压缩 1KB – 3,000 ns
• 在 1Gbps 网络上发送 1KB – 10,000 ns（0.01 ms）
• 从 SSD 随机读取 4KB – 150,000 ns（0.15 ms）
• 从内存中顺序读取 1MB – 250,000 ns（0.25 ms）
• 同一个数据中心内部往返 – 500,000 ns （0.5 ms）
• 从 SSD 连续读取 1MB – 1,000,000 ns （1 ms）
• 硬盘寻道 – 10,000,000 ns （10 ms）

Christopher 演讲的其他部分涵盖了扩展的高级阶段，包括：

• 使用商用服务器传递代码而不是数据： Map/Reduce (Hadoop) ，DHT（Cassandra、HBase 和 Riak）
• 通过数据分区路由数据： ESP/CEP 、Eigen、Storm、Esper、StreamBase 和 0mq 等
• 使用 UDP 而不是 TCP

那些管理超大规模 web 应用的公司使用了最先进的技术，例如 Facebook 使用 UDP 和 Memcached 每秒能执行成千上万次请求。

查看英文原文**： Insight into the Phases of Scaling **

感谢孙镜涛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。