作者文章: Fenng

Facebook 的 Memcached 扩展经验

周末的时候看到这篇 Scaling memcached at Facebook，感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。

相比之前介绍过的数据( 5TB数据/400台服务器).，现在 Facebook 在 Memcached 上的内容已经超过 28TB，总服务器数量超过 800 台。可见硬件降价真是够快的，内存的确便宜得很。

Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器，总体节省的内存资源是惊人的。

第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响，这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句，网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。

最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。

四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力，延迟只有 173 微秒。

Facebook 的技术还是挺开放的。这一点上比 Google 强多了。

–EOF–

手机之家网站架构–对话高春辉

这次去北京参加 CSDN SD 2.0 ，没发现高春辉的身影，原来是忙着做手机之家的架构升级呢。

从老高的近期工作总结中看到：

目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。

对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )

1) 历史情况

Fenng: 原来大约是用什么? 框架用的什么？
高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。
Fenng: 单说现在用的框架，大约投入了多少个人/天 ?
高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 :)
Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?
高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。后面第二期准备拿 Java 来写 Server 端。

2) 遭遇 PHP Bug

Fenng: 你提到的 502 错误不会是 PHP Fastcgi 内存爆了的原因吧？
高春辉: 不是，是 PHP 和 APC Bug 的问题。换新版就好了，你可以看 PHP 5.2.7 的 Buglist。里面列了一个在 Fastcgi 下父进程不能执行 shutdown module 方法的问题。主要是这个原因。APC 也有问题，它的Lock在大并发下非常容易挂掉。换上还没发布的测试版就好了。现在挺稳定的。一台机器跑了700万次请求了。
Fenng: 你遇到的是这个问题吧? Bug 45423
高春辉: Yes Here is the APC bug link : http://pecl.php.net/bugs/bug.php?id=5280 还附带这个问题。当时发现原因之后，非常郁闷，呵呵。
Fenng: 现在用 5.2.8 了?
高春辉: 嗯。5.2.7/5.2.8 反正没啥区别，就修正了一个bug。

3) DB 压力

Fenng: “原有的两台数据库平均总和超过 2000QPS 的查询次数，目前仅有 150+150+250= 550QPS 左右了” 这个 150+150+250 怎么来得？三台？
高春辉: 现在变成三台机器了 :)
Fenng: 哈
高春辉: 是原来的 1/4 吧。
Fenng: 你 Blog 中提到 “由于新系统未经大规模流量实际验证，即使再有信心”, 前面有没有做过压力测试?
高春辉: 做过，但是那个问题不是马上就暴露的。而是要运行一段时间才会出。所以我强调的是实际验证。

4) 过程挑战

Fenng: 问个比较俗的事儿,最近一段时间给你压力最大的事儿是啥？招聘？项目发布？
高春辉: 人!
Fenng: 人员协调？还是人力招聘？
高春辉: 人永远是问题，好的人不够用，差一点的人不想用，呵呵。
Fenng: 国内 PHP 好手还是太少吧？
高春辉: 嗯。太多人缺乏对大规模的研究和实践了。而且这次有些思路的转变是对 Java 的引入。之前是考虑 99% PHP 实现。现在考虑 PHP 只做前端。JAVA 做服务器后端。这样混合编程才算是比较发挥各自的优势。
Fenng: 你们有很多事务的东西？
高春辉: 不是事务多，而是 PHP 本身就不适合做服务器端的内容。包括性能也很慢。比如开始发给你的链接(Fenng 注：之前发给我一个 Session 信息统计的地址)，那个 Session Server 就是拿 Java 做的。之前 PHP 的版本，一次请求要两位数(ms)以上，现在一次只要1.5ms，差距很大。

5) 再说网站架构

Fenng:提供给我一份网站架构拓扑图吧 ?
高春辉:这是实际的，包括 IP 了,供参考吧:

Fenng: 你们网站规模都这么大了!
高春辉: (笑)

Fenng: 考虑到安全问题，我只把缩略图放到网站上吧。估计没人能看清楚 :)
高春辉: 好。我们目前还是做了一些感觉比较不错的小东西的。比如 Data accessor、Session server、YUI compress server 等等吧。
Fenng: YUI compress server 应该是借鉴了 Yahoo YUI, 然后针对静态文件进行压缩的吧？
高春辉: 就是用 YUI Compressor 做的，只是做成了一个 Daemon 服务，而不是命令行的方式来处理。
Fenng: Data accessor 或者其他组件是否准备开源?
高春辉: 关键是只有到规模才需要它。恐怕大部分网站还是觉得麻烦得多吧。
Fenng: 统计分析和监控也是自己写程序？
高春辉: 那倒还没来得及下大功夫，只是做了一些简单的脚本。

6) 图片处理问题

Fenng: 提一个小建议：我发现主题频道这里的图片仍然有拉伸，我个人觉得拉伸是网站必须要慎重对待的问题，用户体验非常不好。
高春辉: 应该是 Imagemagick 使用的问题。我还在继续修正，不过相信不是大问题。
Fenng: 这么说图片处理用了 Imagemagick ?
高春辉: 嗯。有图形处理后端 Server。

高春辉: 你可以看看手机之家论坛(http://bbs.imobile.com.cn/)的页面源代码…
Fenng: 现在(网站)的速度可真不是一般的快…YSlow 上的表现惊人, 差不多是国内网站我看到的最高分了。
高春辉: 其实全都都是动态请求，包括你看到的任何一个图片/JavaScript/CSS …
Fenng: 你们的图片都是如何处理的？我看到似乎是动态拿过来？在DB里？然后Cache到缓存里么？
高春辉: 全部放到数据库里。作为备份。你在前台看到的都是动态处理的，通过 ID 进行关联。前面有两级缓存。数据库的内容相当于备份。这么做的我认为的好处是不用备份上百万个小文件了。而只是备份几百个大文件就行了。速度会提高非常多；而且那种静态损坏的几率就没有了，因为数据库本身会做数据的校验，我们也都保留的验证数据。

Fenng: 这是个反潮流的做法啊,我的猜测是每天数据量变化不大？
高春辉: 目前一天顶多也就是几百兆的增加，应该是可以承受的。而且即使量大也没关系，我可以具体到一个表拆到一个机器上跑。
Fenng: 可这样的话 EXIF 信息就不用了？
高春辉: 所有的信息都可以有一个 Metainfo 表进行保存。而且可以从新生成，假设你的文件信息解析程序有更新的话。
Fenng: 这是我这几年来看到的第一例。不过合适就好。
高春辉: Metainfo表,当然也可以由各应用自己解析自己保存。目前 FileStorage 已经保存了 1.1TB 的文件数据了。当前拆成了 256 个小表，每个表4G左右大小。
Fenng: 文件层用什么文件系统？XFS?
高春辉: 数据库都是 CentOS 5.2 64 bit 的系统。文件系统用 Ext3。其实没你想像的那么大的 I/O 压力，只要两级缓存有了。根本到不了数据库这里。而且前端的两级缓存都是可以多台机器一起跑冗余的。
只要配置就行了。以后备份和故障恢复也很简单。
Fenng: 这一点很有趣。突破传统思维 :)
高春辉: 也是基于之前的教训而琢磨的方法，呵。

7) 对待 NFS 的态度

Fenng: 这次架构升级还有什么补充一下?
高春辉: 刚才还忘了说，我们这次以后坚决拒绝 NFS …
Fenng: 为何?
高春辉: 主要是太容易单点了。 IO对一个机器压力大。这本来就不是个分布式的解决方法。

最后帮老高做个广告，他那边还在招人，需要 PHP/Java 方面的好手，如果有兴趣请访问他的 Blog 并发邮件给他：[email protected] 。

–EOF–

网站运维之道之自动化管理

还是继续这个网站运维的话题吧。前面谈了知识管理与积累，这次谈一下运维过程中的自动化管理。

在进行这篇的扯淡之前，让我想起了《太平广记》里的一个《板桥三娘子》的故事，姓赵的客商窥探到客栈老板娘三娘子在小箱子中取出小孩玩具大小的木头牛，木头人，喷口水，木头人、牛开始犁地耕作，撒一粒荞麦种子，木头小人种下，不一会儿，荞麦长成开花结实，木头人收割，乃至磨成面粉。然后三娘子把木头牛、人收入箱中，用得来的面粉做了数张面饼。多么好的一个自动化场景呀。

自动化的目的

自动化管理是网站规模化之后必须要面对的问题。为什么要自动化?肯定不是为了炫技，针对一个发展中的网站来说，自动化的主要目的还是为了节省维护成本，提升运维成熟度能力。另外一个经常被忽略的收益是能让运维工作更有趣味性一些，不那么无聊，不无聊的有益副作用是减少人为出错的可能。

自动化针对的范围大致可以分为安装自动化、部署自动化、软件发布自动化、升级自动化、监控自动化等几个方面。优化自动化? 别，这个稍微”高级”并且不靠谱了一点。

自动化要解决的问题是 N 次循环的过程，如果 N 不具备延续性，那么自动化未必有必要。比如某个过程可能只是短时间内需要临时进行几次，是否有必要将其自动化就有待于商榷。如果计划和开发自动化过程的成本高于非自动化成本就没必要了。

开发自动化过程

如果看过古龙的小说，他曾经描述过几个有趣的懒人，懒人造了一些木头人和机关来帮自己干一些不愿意做的事情。自动化多少就是”懒人”要做的事情，因为懒嘛，所以才会想办法节省时间和其他成本。一般来说，这个过程的开发者也是使用者，所以没必要一定要按照所谓的项目过程去走，但是开发者必须能够产出一份文档给同团队的伙伴(如果有的话)。

考虑到多数的网站运维可能都是在 Unix like 环境中的，而 Unix 的哲学思想之一就是”Write programs that do one thing and do it well”，每个过程只做一件事情就很关键，”功能单一的自动化模块”是有必要的，把不同的模块拼装起来再去完成更复杂的需求。

Unix 相比 Windows 来说，天生具备可自动化能力。如 Shell/BASH(自动化日常操作)、CronTab(自动化任务调度) 、Expect (自动化交互场景) 、rsync(数据远程同步)等啊都是一些需要注意的技术内容。

优化自动化过程

自动化过程一般要有个生命周期，定期升级、优化也是有必要的。面对不同的应用场景应该逐渐改进自动化的可用性。

示例：自动部署 Linux

对于批量的 Linux 安装，RedHat 提供有 Kickstart Installations 自动安装解决方案，不过该方案相对比较繁琐，前不久推出的 Cobbler 是让人眼前一亮的好工具(参见 hutuworm 的介绍文章)。我一直怀疑 Cobbler 是中国人命名的项目，因为 PXE 发音为”pixie”(皮鞋)，而 Cobbler 的中文意思是”补鞋匠”。

OS 安装完毕之后的软件安装、更新是个麻烦事。在一个 Linux 的环境中，SA 一定不要为软件相互依赖性浪费太多的时间。什么 YUM、APT、YAST 啊，能用就用上。别太迷信自己编译软件所能带来的优化收益，实际上犯错的几率更大。达到某个规模后，本地建立、维护一个软件资料库(repositories)也是有必要的。

Linux 软件安装进化之路：

手工预编译-->RPM-->APT 等工具

已经进化到更好的阶段了，没必要还走着老路在原地折腾。

其他参考：Flickr 运维曾经采用 System Image 来自动化 Linux 相关的的运维工作。或许也可以尝试一下。

在系统配置管理(别混淆到另一个配置管理上去)方面，其实 cfengine 就挺好用的。更多类似工具参考这个比较列表。

标准化，减少后续维护成本是节省人力资源的一大法门。

自动化的一些风险

必须要承认的是，自动化有的时候是容易带来一些风险的，比如”冲掉”原有配置文件信息，不恰当的自动化脚本给系统带来额外负载等，在运维过程中需要不断总结经验。(又落入俗套)

这方面值得推荐的一本书是《UNIX和Linux自动化管理》，借鉴一下其中的思路和方法。

对了，补充一下前面的《板桥三娘子》的故事发展，三娘子的面饼如果被客人吃下，则会变成驴…… 同样，自动化有的时候会把人陷进去的，运维人不要变成自动化的奴隶。

这个话题还需要继续下去么? 我再想想 …

程立在 SD2C 2008 上的演讲 PPT

这是支付宝首席架构师程立在 CSDN 软件开发 2.0 技术会议(SD2C 2008)上的技术演讲《大规模SOA系统中的分布事务处理》的 PPT 最后定稿。好几位朋友可能都等着着急了吧。

大规模SOA系统中的分布事务处理 (DTP By Alipay Cheng Li)

View SlideShare presentation or Upload your own. (Tags: Alipay SOA)

感谢程立的激情演讲与无私分享。原稿件大约有 8M ，我稍微转换了一下，放到了 SlideShare 上，便于更好的传播。如果要下载，点击上面的链接到 SlideShare 上即可。

关于程立

现任支付宝（中国）网络技术有限公司首席架构师，专注于电子支付系统的分布式服务架构与开放架构研究。 2004年程立开始参与淘宝网与支付宝系统的建设，2005年起进入支付宝后一直从事互联网电子支付系统的研发工作，是支付宝发展的见证人之一。

针对这次技术大会，程立说：

去讲这个主题的目的很简单，希望分享一下对大家可能有用的经验，说一些曾经困扰我们的问题，并给出我们的解决办法，不一定是最好的，不一定是正确的，但源自于亲身实践，并经过生产环境的严格验证。

延伸阅读：程立谈架构、敏捷和SOA实践

大家针对该 PPT 有任何问题，请留言或者发邮件给我，我将第一时间转给程立。

–EOF–

BTW: 支付宝架构组目前还在招聘架构师，有意者发邮件给: [email protected]

补充 :