Tag Archives: MySQL

Twitter 的架构扩展: 100 倍性能提升

Twitter 是我最近一段时间用的最多的网络服务之一.还记得刚开始有段时间发消息速度那叫一个慢. 难得的是 Twitter 的开发者在用户激增的情况下性能提升的不错, 据说,相比当初有 100 倍的性能提升, 那我们就来看看他们都做了什么.(发现我这个 Blog 快成了 High Scalability 的中文镜像站了.)

是否真的是 100 倍性能提升, 大可不必较真, 但 Twitter 的一些经验是足以借鉴的.

Ruby on rails

似乎 Twitter 是用 RoR 开发的流量最大的站点(有待于求证). 开始使用DRb (“Distributed Ruby”.), 该库可以通过 TCP/IP 从远程 Ruby 对象发送接收消息, 其缺点是不那么好用,并且没有冗余, 于是转向 Rinda , Rinda 基于 DRb 开发, 使用简单. Twitter 也证明了 Ror 应用同样可以支撑比较繁忙的站点, 工具没有对于错,关键是否能运用好.

图片来源. (这里面我非常疑惑的一点是据说只有两台DB(Master/Slave),可要支撑这么大的并发更新似乎有些难度.)

ETag

Twitter 对于Etag 的态度让不少人疑惑. 这恰恰是因技术制宜的一个体现, 因为 Etag 不是万能药. 另外一点比较重要的原因是 Twitter 有超过 90% 的流量来自 API, 而多数 API 客户端不支持 Etag.

数据库方面的经验

尽可能的索引(Fenng补充:不要过度索引). 因为 RoR 应用的特殊性, 索引是在代码中向 DB 提交的. 另外一个值得议题的是, 反范式. 严格遵守范式是要吃苦头的.建立可行的测试方法,明确的知道你的SQL都在用什么方式运行.(另外,我有个疑问是 rails 不支持 2 阶段提交的吧?)

避免资源过度被占用

哪个站点都不避免的有“水葫芦用户”,对于这样的 Spam 类型用户, 肯定会影响原有的应用处理资源. 该处理就要处理掉. 另一个方面,对于间歇性占用系统资源过多的进程用 Monit 处理.

另外一个很重要的环节是 Cache, 不废话了,没有好的Cache机制怕这样的站点不会成功的. (建议阅读车东辛苦翻译的这篇面向站长和网站管理员的Web缓存加速指南[翻译]). Twitter 运营的一个可取之处是能够积极听取社区的意见并改进, 同时社区上也有很多用户给他们提供了不少技术支持. 这也是开放而带来的好处吧.

–EOF–

WikiPedia 技术架构学习分享

维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。

来点直接的数据：

峰值每秒钟3万个 HTTP 请求
每秒钟 3Gbit 流量, 近乎375MB
350 台 PC 服务器

(数据来源)

架构示意图如下：
Copy @Mark Bergsma

GeoDNS

在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? “A 40-line patch for BIND to add geographical filters support to the existent views in BIND”, 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的–面向各个国家，各个地域。

负载均衡：LVS

WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.

图片服务器:Lighttpd

Lighttpd 现在成了准标准图片服务器配置了。不多说。

Wiki 软件: MediaWiki

对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。

Cache! Cache! Cache!

维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。

数据库: MySQL

MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。复制、读写分离……应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。

运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。

参考文档：

Wikimedia architecture （PDF)
Todd Hoff 的文章

–EOF–

Slashdot 网站架构补遗

Slashdot 前一段时间搞 10 周年庆典，公布了网站的架构信息(软件、硬件)情况。国内的克隆站点 Solidot 有朋友对此做了介绍。看了之后感觉剩下没有介绍的还有嚼头，也写一篇记录一下。

前面本站介绍 Digg 网站架构的时候说他们只有 100 台左右的机器，Digg 在 Alexa 上排名是 100 名左右，而 Slashdot 大约在 750 多，相比之下，服务器也少多了。Web 服务器有 16 台。操作系统都是 Red Hat 9(比较古老)。Apache 是 1.3 版本，模块包括 mod_perl 和 lingerd（用以提高内存效率). 这 16 台中有一台是面向 https 的。MaxClients 设置都很小，面向动态内容的设置 5-15 ，面向纯静态内容的只有 25。因为瓶颈不在 IO 而在 CPU 上。

Web 服务器 IO 压力不大是因为用了 Pound 作为反向代理与负载均衡服务器，Cache 了大部分 IO 。

Slashdot 比较奇怪的一个地方是 NFS 的利用方式。 Web 服务器都用同样的软件， NFS 服务器输出一个只读的目录，每台 Web Server Mount 该目录。NFS 服务器后台有任务定期写回。这个实现方式有点意思，看起来似乎 NFS 是个单点–写单点。

数据库有 7 台 MySQL，都运行在 CentOS 4 上。CentOS 是 RedHat Enterprise Server 的克隆版。一直以为是不登大雅之堂的。Slashdot 这次也披露了不少数据层的使用经验，感兴趣的朋友可以点击开头的链接仔细看看。

总的来说，Slashdot 毕竟算是个老网站了，和 Digg 这样的新贵来说，在架构上相对比较保守，但仍有许多东西值得借鉴。

–EOF–

Fotolog.com 的技术信息拾零

尽管是世界上最大的图片服务网站, Fotolog.com 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起 Flickr. 但实际上 Fotolog 也的确是很猛的, Alexa 上的排名一直在 Flickr 前面, 目前注册用户超过 1100 万. 而前不久也卖了一个好价钱, 9000 万美金. 算下来的话, 1 个注册用户大约 9 美金. Yupoo 的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.

在前不久的 MySQL Con 2007 上, Fotolog 的 DBA Farhan Mashraqi 披露了一些技术信息.（PPT下载)

与其他大多数 Web 2.0 公司普遍用 Linux 不同的是, Fotolog 的操作系统用的是 Solaris . Solaris X86 也是免费的, 估计是维护人员更熟悉 Solaris 的操作系统而作出的选择吧.

数据库当然是使用 MySQL. 有32 台之多, 最开始的存储引擎是 MyISAM ,后来转向 InnoDB. 对于 DB HA , 使用 DRBD (介绍)，在 Solaris 上用 MySQL ,有个优化技巧是关于 time(2) 系统调用的，通过调用比 gethrestime() 更快的 gethrtime(3C) 来提高性能。可以通过设置 LD_PRELOAD (32位的平台) 或 LD_PRELOAD_64 来做到。详细信息可以参考Sun 站点上的这篇 MySQL 优化文章，很有参考价值。

存储也是值得一说的，Fotolog 用的是 SAN，还是比较贵的 SAN: 3Par. 这个产品可能绝大多数 DBA 是比较陌生的，该产品原来主打金融市场，现在也有很多 Web 公司使用，一个比较典型的客户代表是 MySpace。3Par 的最大的特点就是 Thin Provisioning。Thin Provisioning 这个词有的人翻译为”自动精简配置”，在维基百科的定义：

Thin provisioningis a mechanism that applies to large-scale centralized computer disk storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.

说白了就是对空间分配能够做到”按需分配”。有些扯远了。

–EOF–