维基百科的高性能架构设计分析

Wikipedia 网站整体架构

维基百科的高性能架构设计分析_第1张图片
Wikepedia 架构图
  1. GeoDNS:基于开源域名服务器软件 BIND(Berkeley Internet Name Domain)的增强版本,可将域名解析到离用户最近的服务器。

  2. LVS:基于 Linux 的开源负载均衡服务器。

  3. Squid:基于 Linux 的开源反向代理服务器。

  4. Lighttpd:开源的应用服务器,较主流的 Apache 服务器更轻量、更快速。实践中,有许多网站使用 Lighttpd 作为图片服务器。

  5. PHP:免费的 Web 应用程序开发语言,最流行的网站建设语言。

  6. Memcached:无中心高性能的开源分布式缓存系统,稳定、可靠、历久弥新,是网站分布式缓存服务必备的。

  7. Lucene:由 Apache 出品,Java 开发的开源全文搜索引擎。

  8. MySQL:开源的关系数据库管理系统。

Wikipedia 前端性能优化

所谓网站前端是指应用服务器(也就是 PHP 服务器)之前的部分,包括 DNS 服务、CDN 服务、反向代理服务、静态资源服务等。对 Wikipedia 而言,80% 以上的用户请求可以通过前端服务返回,请求根本不会达到应用服务器,这也就使得网站最复杂、最有挑战的应用服务端和存储端压力骤减。

维基百科的高性能架构设计分析_第2张图片
Wikipedia 前端架构

Wikipedia 前端架构的核心是反向代理服务器 Squid 集群,大约部署有数十台服务器,请求通过 LVS 负载均衡地分发到每台 Squid 服务器,热点词条缓存在这里,大量请求可直接返回响应,请求无需发送到 Apache 服务器,减轻应用负载压力。Squid 缓存不能命中的请求再通过 LVS 发送到 Apache 应用服务器集群,如果有词条信息更新,应用服务器使用 Invalidation Notification 服务通知 Squid 缓存失效,重新访问应用服务器更新词条。

而在反向代理 Squid 之前,则是被 Wikipedia 技术团队称为"圣杯"的 CDN 服务,CDN服务对于 Wikipedia 性能优化居功至伟。因为用户查询的词条大部分集中在比重很小的热点词条上,将这些词条内容页面缓存在 CDN 返回,响应速度非常快,这些请求甚至根本不会到达 Wikipedia 数据中心的 Squid 服务器,服务器压力减小,节省的资源可以更快地处理其他未被 CDN 缓存的请求。

Wikipedia CDN 缓存的几条准则为:

  • 内容页面不包含动态信息,以免页面内容缓存失效或者包含过时信息。

  • 每个内容页面有唯一的 REST 风格的 URL,以便 CDN 快速查找并避免重复缓存。

  • 在 HTML 响应头写入缓存控制信息,通过应用控制内容是否缓存及缓存有效期等。

Wikipedia 服务端性能优化

服务端主要是 PHP 服务器,这里是网站业务逻辑的核心部分,运行的模块都比较复杂笨重,需要消耗较多的资源,Wikipedia 将最好的服务器部署在这里(和数据库配置一样的服务器),从硬件上改善性能。

除了硬件改善,Wikipedia 还使用许多其他开源组件对应层进行如下优化。

  • 使用 APC,这是一个 PHP 字节码缓存模块,可以加速代码执行减少资源消耗。

  • 使用 Imagemagick 进行图片处理和转化。

  • 使用 Tex 进行文本格式化,特别是将科学公式内容转化成图片格式。

  • 替换 PHP 的字符串查找函数 strtr(),使用更优化的算法重构。

Wikipedia 后端性能优化

包括缓存、存储、数据库等被应用服务器依赖的服务都可以归类为后端服务。后端服务通常是一些有状态的服务,即需要提供数据存储服务,这些服务大多建立在网络通信和磁盘操作基础上,是性能的瓶颈,也是性能优化的重灾区。

后端优化最主要的手段是使用缓存,将热点数据缓存在分布式缓存系统的内存中,加速应用服务器的数据读操作速度,减轻存储和数据库服务器的负载。Wikipedia 的缓存使用策略如下:

  • 热点特别集中的数据直接缓存到应用服务器的本地内存中,因为要占用应用服务器的内存且每台服务器都需要重复缓存这些数据,因此这些数据量很小,但是读取频率极高。

  • 缓存数据的内容尽量是应用服务器可以直接使用的格式,比如 HTML 格式,以减少应用服务器从缓存中获取数据后解析构造数据的代价。

  • 使用缓存服务器存储 session 对象。

  • 相比数据库,Memcached 的持久化连接非常廉价,如有需要就创建一个 Memcached 连接。

作为存储核心资产的 MySQL 数据库,Wikipedia 也做了如下优化:

  • 使用较大的服务器内存。在 Wikipedia 应用场景中,增加内存比增加其他资源更能改善 MySQL 性能。

  • 使用 RAID0 磁盘阵列以加速磁盘访问,RAID0 虽然加速磁盘访问,但是却降低了数据库持久可靠性(一块盘坏了,整个数据库的数据都不完整了)。显然 Wikipedia 认为性能问题迫在眉睫,而数据可靠性问题可以通过其他手段解决(如 MySQL 主从复制,数据一步备份等)。

  • 将数据库事务一致性设置在较低水平,加快系统恢复速度。

  • 如果 Master 数据库死机,立即将应用切换到 Slave 数据库,同时关闭数据写服务,这意味着关闭词条编辑功能。Wikipedia 通过约束业务获得更大的技术方案选择余地,很多时候业务后退一小步,技术就可以前进一大步。

你可能感兴趣的:(维基百科的高性能架构设计分析)