idea's blog

我收集到一些文章和视频, 可以带你窥探 Facebook 的架构. Facebook 承载了几十亿的用户, 它的架构(包括思想和实现)是非常值得参考的. 当然, 你要小心不要照搬 Facebook 的每一字一句, 因为任何思想和实现都是有自己的应用场景的.

• 文章: BigPipe: Pipelining web pages for high performance
• 文章: Needle in a haystack: efficient storage of billions of photos
• 文章: http://www.facebook.com/note.php?note_id=10150148835363920
• 文章: The Underlying Technology of Messages
• 文章: Facebook Chat
• 文章: Building Efficient Data Centers with the Open Compute Project
• 文章: Scaling Facebook to 500 Million Users and Beyond
• 文章: Making Facebook 2x Faster
• 文章: Hacking Conventional Computing Infrastructure
• 视频: The Underlying Technology of Messages Tech Talk (12/7/10)
• 视频: Typeahead Search Tech Talk (6/15/2010)
• PPT: Hpca2012 Facebook Keynote
• PPT: Facebook的架构

最近做了一次MySQL所谓的"海量数据"查询性能分析.

表结构

说明, MyISAM引擎, dt表示时间字段使用datetime类型, it表示时间字段使用int类型.

初始数据

首先生成100K个UNIX时间戳(int), 然后随机选取10M次, 每一次往6个表里插入一条记录(当time字段是datetime类型时, 做类型转换). 所以每一个表都有10M条记录. ext1和ext2字段会用随机的字符串填充.

Continue reading »

今天, 和部门的同事一起分享了Web服务器的核心内幕, 把PPT奉上, 大家喜欢可以下载. 本PPT的出发点和许多所谓的XX源码分析非常不同.

最近在设计一种网络服务器架构, 最重要的一点是把耗时操作委托给工作进程(或者线程)来做, 所以考察一下 fastcgi. 大概看了下 lighttpd 的 mod_fastcgi 的源码, 没想到立即被卡住了. 根据我的想法, PHP 等 fastcgi 程序(php-cgi 进程)监听网络, 然后 mod_fastcgi 只需要 connect 这些进程即可, 奇怪的是, 我竟然看到了 listen! -

fcgi_spawn_connection() 函数:

fcgi_fd = socket(socket_type, SOCK_STREAM, 0);

if (-1 == connect(fcgi_fd, fcgi_addr, servlen)) {
    close(fcgi_fd);
    fcgi_fd = socket(socket_type, SOCK_STREAM, 0);
    /* create socket */
    bind(fcgi_fd, fcgi_addr, servlen);
    listen(fcgi_fd, 1024);

    switch ((child = fork())) {
    case 0: {
        // child process
        if(fcgi_fd != FCGI_LISTENSOCK_FILENO) {
            close(FCGI_LISTENSOCK_FILENO);
            dup2(fcgi_fd, FCGI_LISTENSOCK_FILENO);
            close(fcgi_fd);
        }
        /* exec the cgi */
        execve(arg.ptr[0], arg.ptr, env.ptr);
        exit(errno);
    }
}

我很奇怪, mod_fastcgi 为什么要监听网络连接? 谁会连接它? 问了同事, 同事说可能是 fastcgi 进程要连接它, 可问题是 fastcgi 进程怎么知道连接什么地方, 更不用说, fastcgi 协议里没有提到要 fastcgi 进程主动连接 Web Server 一说.

Continue reading »

不同于Windows平台的高效的线程机制, Linux/Unix系统早期通过多进程来解决Web大规模并发访问量的问题. 而随着Linux内核的改进, 单纯增加进程数量的方式也慢慢被弃用, 转而使用单进程异步IO接口, 比如epoll(Linux), kqueue(BSD).

单进程异步IO接口可以简单理解为, 进程把大量的socket连接交给内核管理, 一旦连接中有数据需要处理, 则激活进程进行处理. 这样, 一个进程同时打开的socket(也即文件描述符)就有成千上万个.

Linux系统默认的单个进程所能打开的最大文件描述符一般是1024(可通过ulimit -n命令查询), 这就导致了文件描述符被用完的情况出现. 所以, 要开发能处理高并发请求的Web系统, 必须修改操作系统的最大文件描述符.

即使使用的是Apache这样的多进程Web服务器, 也有可能被最大文件描述符限制给绊倒, 因为后端可能使用的是fastcgi, memcached这些应用. 比如memcached, 一般使用的就是单进程异步IO接口, fastcgi的PHP脚本与其连接时, 将保持TCP长连接, 也是会消耗大量的文件描述符.

所以, 运行在Linux之上的高性能Web系统, 一定要扩大进程的最大文件描述符限制, 这是有很惨痛经验教训的.

大规模Web应用系统, 几乎都会遇到数据库瓶颈问题. 在早期, 通过数据库配置优化, 表优化, 索引优化等软件方法, 可以解决一些问题. 马上, 数据库瓶颈迫使不得不把MySQL和Apache单独部署到不同的机器, 形成Web服务器(Web Server)和数据库服务器(DB Server)的物理分离, 这样就能解决大部分的问题. 但是, 在继续发展时, 一台Web服务器和一台数据库服务器也不能满足高并发的访问量了.

这时, 问题首先是计算能力的问题, 也就是硬件不够用的问题. 所以, 需要上多台Web服务器和多台数据库服务器.

有时候, 网站可以纵向切分, 这样, 任何两台服务器(一台Web Server + 一台DB Server)单独配置, 便能运行一个应用. 比如某两台运行着论坛程序, 某两台运行着新闻程序.

很多情况下, 并不能纵向切分, 每一台的Web Server的角色和功能都是一样的, 没有差别, DB Server也是一样. 理想的情况下, 同种压力的SQL语句平均分布到每一台DB Server, 那就能解决高并发数据库请求问题了

dbproxy的作用便是如此: 合理地分配数据库请求给所有的DB Server, 使得在请求的数量等于或者小于所有DB Server的计算能力总和时, 服务能够正常运行.
Continue reading »