BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义：

• Basically Availble --基本可用
• Soft-state --软状态
• Eventual Consistency --最终一致性

"Soft state" (SS) 是与 "Hard state"(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的，这样就清晰多了。

最终一致性， 也是是 ACID 的最终目的。对于 eBay 这样的大架构，是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构，另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文：BASE: An ACID Alternative，注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年，BASE 将成为一个技术热词。ACID 当然没过时，只是各自需要合适的应用场景而已。随着互联网技术的开放性，更多的时候，一个架构师需要反复的衡量合适的应用场景。

BTW: "ACID" 英文里面有"酸"的意思，而 "BASE" 有"碱"的意思. 酸碱在一起才能中和啊，哈

--EOF--

好几个地方看到这个 Facebook - Needle in a Haystack: Efficient Storage of Billions of Photos，是 Facebook 的 Jason Sobel 做的一个 PPT，揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性】

图片规模

作为世界上最大的 SNS 站点之一，Facebook 图片有多少? 65 亿张原始图片，每张图片存为 4-5 个不同尺寸，这样总计图片文件有 300 亿左右，总容量 540T，天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ，每周上传 1 亿张图片。

图片存储

前一段时间说 Facebook 服务器超过 10000 台，现在打开不止了吧，Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的，采用 NFS 方式。

图片写入

尽管这么大的量，似乎图片写入并不是问题。如上图，是直接通过 NFS 写的。

图片读取

CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜，但基本上不承担多大的访问压力，否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%，普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。

图中的 Cachr 这个组件，应该是用来消息通知(基于调整过的 evhttp的嘛)，Memcached 作为后端存储。Web 图片服务器是 Lighttpd，用于 FHC (文件处理 Cache)，后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了，人家连 MYSQL 服务器还有两千台呢。

Haystacks --大海捞针

这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制，简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做，Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作，应该说，这倒也是个比较有趣的思路，如果感兴趣的话，看一下 GET / POST 请求的方法或许能给我们点启发。

总体来看，Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak，比如不影响图片质量的情况下减小图片尺寸。

--EOF--

什么是 Load ? 什么是 Load Average ?

Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章：UNIX® Load Average Part 1: How It Works】

下面是一个 uptime 命令输出：

$ uptime
 18:57:48 up 423 days,  3:55,  2 users,  load average: 1.16, 1.12, 1.20

尽管各种信息来源的定义都不太确定。能确定的一件事情是，你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟，这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:

 869        count -= ticks;
 870        if (unlikely(count < 0)) {
 871                active_tasks = count_active_tasks();
 872                do {
 873                        CALC_LOAD(avenrun[0], EXP_1, active_tasks); 
 874                        CALC_LOAD(avenrun[1], EXP_5, active_tasks);
 875                        CALC_LOAD(avenrun[2], EXP_15, active_tasks);
 876                        count += LOAD_FREQ;
 877                } while (count < 0);
 878        }
 879} 

如何判断系统是否已经 Over Load ?

对一般的系统来说，根据 CPU 数量去判断，如上面的例子， 如果平均负载始终在 1.2 以下，而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。

这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书，尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师 的必须书。】

这么说实际上带来另外两个疑问：

1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器，我的建议是看操作系统怎么识别的 CPU，根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数，建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。

2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。

多数情况下，Load 过高都未必和 CPU 有关。或许倒是有一个例外的，就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器，麻烦就来了

Load 与容量规划(Capacity Planning)

任何一个相对成熟的站点都会利用 Cacti（基于RRDTool） 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去，这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。

Load 与系统预警

很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话，意义就不大了。比如，数据库服务器有 4 颗 CPU，那么 Load 高于 4 就应该报警出来，设置比 4 高可能意义不大，因为接到报警还有个人为响应时间...

误解 一：系统 Load 高一定是性能有问题。

误解 二：系统 Load 高一定是 CPU 能力问题或数量不够。

真相：Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的，也可能是耗 I/O 乃至其它因素的。

误解 三：系统长期 Load 高，首选增加 CPU。

真相：Load 只是表象，不是实质。增加 CPU 个别时候会临时看到系统 Load 下降，但治标不治本。

小小一个 Load 讲究其实不少。英文信息其实比较全的，尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议，请指正或告知。

--EOF--

FAQ 1：数据库服务器突然 CPU 100% 繁忙，咋办?

A ：一般情况下，这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ，针对 I/O 开销比较大(重点看全表扫描）的 SQL 进行优化。根据经验值，每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作，尽管存储的吞吐可能还没那么大，也可能会把 CPU "塞满"。

谁来拯救大兵 Twitter ? 前几天看到新闻说他们请了 Pivotal 实验室来解决当前存在的问题。从这几天观察来看，好像并没有什么明显进展。也或许并非一时半刻就能完成吧。今年用的最多的 Web 2.0 服务就是 Twitter 了，没有了这东西还真的有些不习惯。

Twitter 的初期设计对消息采用了 Single Instance Storage (SIS)，这直接导致了消息持久化产生了数据库单点问题(?) . 每一种设计思路应该都有其理由。旁观者清也只是没介入到那个环境吧。接下来 Twitter 会做什么? Sharding ?

这个视频更像是 Twitter 不服气外界质疑而进行的宣传。其实 Twitter 的一些扩展性问题对 Web 2.0 站点来说是个绝佳的案例，有正面的成长参考，也有为错误买单的痛苦。或许这才是主要吸引我们关注它的地方。

--EOF--

InfoQ中文站: 在 Web 2.0的时代，海量数据对于越来越多的开发者来说，已经不再是一个遥不可及的话题了，可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量，那么对于这种网站，除了对数据库存储进行优化，除了缓存，然后还有那些策略？

Fenng: 我觉得可能主要是在存储方面会有一些大的挑战。比如存储的可靠性，像以前就有过 BSP服务商对客户的数据居然没有备份，导致了很多用户损失了一段时间之内的数据，这样总体来说对网站的声誉有很大影响、对用户的体验也很糟糕。

随着互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题。我们前面说了太多 Web 2.0相关的话题，【换个角度】比如说我所在的公司支付宝，也面临着这样的大数据量、海量数据的挑战。当前我们的一个策略，也是沿袭 SOA 的战略化思想，就是数据库相关的数据服务进行一定的 SOA 化处理。另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命周期已经完成后，会对相关的数据做一些归档化的处理，再进行二级存储或者分级存储。那么话说回来，对一些 Web 2.0 网站，我觉得也可以运用这样的思想机制: 对用户已经不大可能访问或者访问频率比较低的（数据），采用分级存储，或者额外做一些访问策略的制订，是很有必要的。

InfoQ中文站: 我们也听说过另外一种分片数据库机制，那么请你谈谈分片这种策略是怎么样一种策略？

Fenng: 分片总的来说，它不是一种比较新的技术， MySQL 在 5 .x 版本之后，有了分区功能。那么在这之前，MySQL 是没有分区功能的。当时如果需要处理一些比较大的数据量，比方说要对根据时间对数据进行历史化处理，就会比较麻烦。人们可能是因地制宜，就产生 Sharding 这样技术策略。

严格来说，数据分片其实在我们以前也有一些相关的实践，在其他(类型)的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型在线游戏中发展出来的。大部分用户会集中在某个区域。这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户 ID 范围，或者说不同的地区(来分片)。

如果建的是商务网站，可能根据产品的类型来做，我们会把不同产品类型的数据扔到不同的 DB上，这些 DB 之间的关联度是很小的。然后我们在 DB 之间，可能会有一个封装层，在这个封装层之上，对应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。

InfoQ中文站: 那分片这种策略有什么利弊吗？

Fenng: 首先，分片的好处还是很容易看到的。起码我们的 DB 能达到不依赖于某个单点，而这样能做到平滑的扩展，就像大家常说的 Scale Out (横向扩展)机制。它的弊端也是比较明显，对于事务高速处理这样的网站，它有它的自己的不足之处，事实上好多朋友也应该知道，一个事务如果跨数据库，这样对设计者，对编码人员来说，还是比较棘手的。那么如果一个事务如果跨两个甚至多个 DB，Sharding 复杂度就会很高。Sharding 在业界的应用场景基本上也就是这种读应用比较重的情况，而且对事务的安全性要求不高，这样的场景会非常适合。

【上个月写了篇 Sharding 的东西给《程序员》，还不知道什么时候发表出来】

InfoQ中文站: 目前在许多网站的架构设计中有绝大多数的项目在持久化方面就是采用数据关系映射（ORM）的方式。大家对于这种高负载的大规模网站应用来说，你觉得存在哪些应用呢？

Fenng: 首先一点，我想拿我们支付宝来说，ORM 大家觉得用得非常好。在一个相对比较大的开发环境，对开发团队来说，它的弊端可能就不大容易看出来。因为我们用的是 ORM，就很容易把中间 DB 这层完全隔离出来。然后把这一层的 SQL 处理交给专门的 DB 人员----我们这边还有专门的开发DBA，由他们来专门对这层进行集中的监控管理，乃至一些规划类的工作。这样开发工程师还有架构师这边，他们可以集中精力在其他方面做更多的投入，一个比较大的团队中我觉得像 ORM 这些还是很容易能看到好处的。

【ORM 还有个比较好的地方在于安全性，能有效减少 SQL 注入的隐患】

在另一方面，我们看一下它的弊端，因为像一些 Web 中小网站，可能相对人手也比较少，大家 用的(开发)工具(或框架)呢，可能像 PHP、 ROR 这些东西，也就是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些 ORM，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。

InfoQ中文站: 那你所做的支付宝，其实是企业级别的应用，在企业级别应用所采用的这种架构策略和一般 Web 2.0 网站所采用的这种架构策略会有什么异同？

Fenng: 事实上，很明显的一点，支付宝其实业务是非常复杂的【也有一部分人误解支付宝业务很简单】，这和我们很多的Web2.0公司不大一样，Web2.0它可能从一个点切入进去。在这一点上，我觉得做得比较透。支付宝呢，它可能有点像我们以前做的一些通用软件，他要考虑不同的行业、不同的用户、还有像买卖之间，与这么多银行之间的关系等等，这个复杂度还是很大的。

这实际上就从一定程度上决定了我们和 Web 2.0 公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站 SOA 化、组件化。在这个过程中，也考虑了一些像 Web 2.0 中的技术元素，但总体的思路呢，还是说向SOA 化，向面向服务这方面大步的跨进，然后就从 SOA 这一点，事实上很多 Web 2.0 公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。

另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像 FaceBook ，或者是说，像美国的 MySpace 这样的社交区、SNS 网络了有一些共通之处。

InfoQ中文站: 那目前在 Web 2.0 网站这个领域里面，网站的架构主要有哪些趋势，下边还将有怎么样一个走向呢？

Fenng: 其实作为一个技术人员，每当要谈到趋势，肯定要给大家笑。从中长期来看，国内的一些 Web 2.0 新服务逐渐涌现出来了，随着发展，我相信会有更多的商业化元素加进来。像以前是好多 Web 2.0 公司是完全使用开源的技术，伴随规模扩大化，一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作。商业化并不是个坏事情，一方面给我们提供更好的服务。另一方面，他们得到了足够的商业支持，反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进。我相信在未来的两到三年之内，会有一部分的商业公司涌到 Web 2.0 的发展生态圈里面。

然后从技术方面来讲，像前面几个月 MySQL 被 Sun 收购，起码是在 Web 2.0 这样的软件链条中的一个重要环节(MySQL),有些人可能会感觉出了一些问题。但现在像在数据库这一层呢，也不排除像 PostgresSQL 这些其它的数据库，趁这个机会被商业公司所拥抱，他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家，几家开源数据库形成一个僵局，Sun 在......这个有些扯远了，还是绕回来。像现在很多的 Web 2.0 公司，他们对 Web 服务器这方面也会采用一些比较新的，像 Nginx， 我觉得在起码在接下来的一段时间内会吸引绝大多数公司长期、大规模的去使用它、去拥抱它，甚至为它开发一些更激动人心的新特性。

【这段时间比较热炒的开放平台、云计算也或许能给我们带来一些思路：很多有技术积累的的公司都有自己打造一套底层的架构的意图，比如针对存储层面向应用的虚拟化等。】

InfoQ中文站: 那最后作为一个由 DBA (Administrator) 成长为DB Architect，同样都是A，但这个A已经有一个变化，那么你对后来者有哪些建议呢？

Fenng: 建议谈不上，跟大家谈谈自己在这个过程中的一些转变。首先从DBA(的角度说)，因为 DBA 做一些实际相关的维护工作，从这个过程转到架构师这边，是相对从这比较"实"的岗位转换到现在看起来相对好像稍稍"虚"了一些，但是在这个"虚"的过程中，又相当于我们且退一步，然后就能看得更远一些，能看到整个软件架构的网站发展，甚至是公司战略上的一些事情，这对个人成长是有好处的，我希望大家如果有这个意愿也可以稍微尝试一下，因为 DBA 只是我们整个软件开发行业中的一个环节，那么在这个环节前面和后面，其实都有很多可以做的事情。

其实每个人都不是不可替代的，那我们是否可以尝试一下是否能够去替代别人呢？谢谢大家。

--EOF--

以下是正文:

InfoQ中文站: 作为一名资深的 DBA，大辉却在自己的 BLOG 上边写了不少关于网站架构这方面的一些文章，能不能谈谈 DBA 跟网站架构这方面的关系呢?

Fenng: 好多朋友和我开玩笑，说我做一个DBA，却总去写一些架构相关的东西，"是不是这个厨子不看菜谱，看兵法了？" 其实这二者之间我觉得是有些关系的。像数据库的维护，甚至设计、架构相关的工作，做到一定程度上还是要向前再走几步：也就是说要把我们架构相关的一些事情融合进来。当然作为一个 DBA 没必要一定要像我们的相关架构师这样，去做一些编码之类的实际工作，不过一些和 DB 结合的比较紧密的东西是一定要关注一下的，这也是我在 BLOG 上写了不少与架构相关文章的一个主要原因。

InfoQ中文站: 一般来说要提升网站的性能，瓶颈主要都有哪些，如果要解决这些瓶颈，又都存在哪些最佳实践呢?

Fenng: 在以前，可能瓶颈多数会在数据库上，也即最后瓶颈会落在 IO 上面。但是现在随着一些 Web2.0 发展而涌现出相关的技术解决方案，当前一个网站真正能否应付大流量、高并发，主要的问题还在于 Cache 能够充分、灵活、正确使用上，这点十分重要。【补充，因为这个整个话题基本是面向 Web 2.0 方面的，所以这里说 Cache 会是主要问题，如你所知，电子商务站点的话，事务处理能力无疑是比较棘手的事情】

InfoQ中文站: 一个要经受住大规模、高并发、访问量考验的成功 Web2.0 网站在设计的架构中要注意哪些东西呢?

Fenng: 这个在前期的规划中肯定是需要做一些预防性的措施，比如说选择适合的技术架构。这是第一步应该必须要考虑的事情。另外还有在产品设计上也会有很多需要注意的地方，现在我们的很多 Web 2.0 网站，包括国内的这些新兴的一些 Web 2.0 网站，多多少少存在一些过度设计的现象。这些设计不经意之间可能会对后台带来灾难性的影响，这就会对开发人员、架构师，甚至维护人员都带来很大的压力。

另一方面呢，参考当前业界上一些已经相对比较成熟的技术 DIY 搭建架构还是很关键的。我们做一个网站就好比造汽车一样，不一定非要造得像奔驰这样顶级豪华的(那成本会非常高)，我们只需造一辆能跑起来，跑得很好的汽车，这可能就已经达到成功的一半了。

InfoQ中文站: 那刚才在网站性能和调优这方面，你刚才也提到了，缓存的作用是非常重要的，那么它到底处于怎么样一个重要的地位呢？如何对缓存进行优化从而提升性能?

Fenng: 就我以前的相关经验，基于 Oracle 环境的一些实践，一方面是在应用程序高并发的设计上有一些必须注意的事项，另外一个就是能否充分利用 Oracle 自己的内存，最后实质上看其是能否充分利用自己的 Cache 机制。对于 Web 2.0 网站，可能很少有使用 Oracle 数据库(多是 MySQL)，但在MySQL上，一方面 MySQL 有自己的 Cache 机制，应该说还做得不错，再一个，绝大多数网站都会考虑使用像 Memcached 这样的外部组件进来，然后在这个地方，其实我们最后考量的是命中率，衡量命中率的高低，这是大家必须要注意的扩展性、性能指标。

命中丢失的 I/O 实际上最后压到我们的数据库上，到数据库的 I/O 命中再丢失有可能会压到最下面的磁盘上，这样磁盘【或存储】一定要能支撑住我们当前的最低需求。举个最简单的例子，我们的应用 Memcached，可能前面的 I/O 命中率是 80%，那么有剩下的 20% 会压到后面的 DB 上，这个 DB 的命中率有可能达到95%，剩下的5%，乘以前面那个 20%，总体 I/O 量 x 20% x 5%，这个 I/O 量会打到最后端的硬盘【或存储】上。而硬盘【乃至存储】的整体响应能力又是有限的...我们或许是做 RAID，也甚至可能出现单块硬盘支撑应用这样的情况。从这个基础往前推，就能计算出我们当前的系统能承载 Cache 的瓶颈，进一步知道整体 I/O 的处理能力。在设计的时候，一定要考虑到这样的情况，否则当压力突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。

InfoQ中文站: 你刚才说到Cache命中率，那对于一个比较成功的这种网站，它Cache命中率一般会在多少呢?

拿 Oracle 来说，它本身的命中率做到 90% 甚至是 99.99 这样的情况，在MySQL的环境下可能做不到这样， Memcached 据我所知，可能70%～80%已经不错了【不同的应用表现差异很大，比如豆瓣的朋友告诉我他们命中率是 97% ! 】。当然命中率只是一个表面的现象，我们还要看实际真正的应用程序到底是怎样，可能不同的 Web 应用类型所能承载的访问频率也不大一样，所以并没有固定的比例，这里只能是凭一些经验。总体来说肯定是命中率越高，会越好一些。

第一部分先到这里。明天有时间修正剩下的部分。

• 视频页面：与冯大辉谈数据库架构 (另：新闻页面)

这是个人第一个成功发布的视频访谈。去年 Oracle Open World 的时候, IT168 非要作采访，结果牺牲了两个会议时间，折腾完后再也没看到关于那个视频的消息。

说实话，采访之前自己还是比较担心效果的。这次 InfoQ 的采访效果比我的预期要好多了，因为现场发挥的地方比较多，有口不择言的时候，还望读者朋友海涵。

赞一下 Infoq 的几位朋友(泰稳、Jason、X5)! 和他们合作很愉快。我身边的很多同事都认为 Infoq(中文站) 是国内最好的技术信息站点。接下来，还有对我另外一位同事的采访(比我更为重量级)即将发布，我在采访现场听了都很过瘾。敬请期待，绝对不忽悠 :)

--EOF--

现在技术问题成了 Twitter 进一步发展的极其严重的制约了，在所有的 Web 2.0 站点里这倒是比较少见的。尽管 Twitter 过去号称把性能提升了 100 多倍，看来还不够哇。 前一段时间，有小道消息说 Twitter 准备放弃 RoR ，倒是 Twitter 忙不迭的辟谣。

面对很恼火的用户，Twitter 也承认架构上的一些问题，"Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system" ，而最初的架构也是面向内容管理系统而不是消息系统的，这需要一个转变过程。一直让我比较奇怪的是 Twitter 似乎没有专门的 DBA ，而是开发工程师兼任，如果 MySQL 不是瓶颈倒没问题的(有很多 Web 2.0 大站就不用专门 DBA 的)，可如果 DB 是瓶颈，那就比较麻烦了。DB 如此，其它环节也是如此。

有意思的是，随着互联网应用的飞速发展，Performance Engineer / Scaling Engineer 这样的新职位需求都出来了。这是个有挑战的活儿，值得尝试一下。

实在无聊，这只是一篇随笔罢了。

--EOF--

延伸阅读：Twitter 在自救

过几天估计 infoQ 中文站就翻译这篇文章了，所以只记录一点自己的想法好了。在其中的 7 个实战经验中，每一条都值得写篇学习笔记，我比较关注面向 DB 的几条。

水平切分

对于 eBay 这样个头的大 Web 应用，如果数据不能分片，就无从谈及扩展。这个话题我之前描述过一点，文章中提及数据库层的切片要比应用层复杂许多，我想其中最大的一个难点就是不同用户之间的关联数据问题吧，否则就完全可以根据用户范围或者群体划分到不同的 DB 上。现实的应用总是如此复杂，让每个架构师都早生华发啊。

避免分布式事务

其中提到的前 Inktomi 工程师 Eric Brewer 提出的 CAP 定理： Consistency (C), Availability (A), Partition-tolerance (P) ，最多能同时选择两个。三个不能同时实现。对于 eBay ，选择的是 A 和 P，牺牲了一致性，而通过系统的其它手段(比如事件系统)来追回事务的完整程度。BTW: 这次倒是没有提及 BASE :)

虚拟化所有层次

这样做的目的是为了达到编程上的方便以及运营操作的灵活性。通过 eBay 的 O/R 层实现了对数据库的虚拟化。这样应用程序开发者无需关注数据存在哪里的。

Cache

其中提到了 Cache 的应用场景：针对缓慢改变的数据、只读为主的数据、元数据、配置信息和静态数据等。 把握这个原则是很关键的。我个人就看到有病急乱投医的设计者把数据一股脑的扔进 Cache，潜在的麻烦很难消除。

强烈推荐大家直接点过去看一下该文。

补充：关于 BASE。
Basically Availble
Soft-state
Eventual Consistency

--EOF--

1) LinkedIn - A Professional Network built with Java Technologies and Agile Practices

这是我看到的 Web 2.0 公司中第一个完全拥抱 SOA 的。这个文档中大致描述了 LinkedIn 开发过程上的一些经验。

| View

News Service Architecture 对于国内鲜果这样的 RSS 工具网站或许能有点参考价值。另外一个值得注意的地方是架构的变迁，随着业务的增长，后端 DB 的变化非常明显。

2) LinkedIn Communication Architecture

这一篇中描述了几次迭代经验，其思路值得借鉴。

| View

其中提到了对 CLOB 字段的更新认识。我个人的建议是：不到万不得已，还是别在 Web 应用中用 CLOB 了。

--EOF--

提高可用性技术，前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题，默认情况下达到一定 mount 次数或者超过一定时间，系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后，文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理，即可避免不必要的停机时间。

另外维护中能尽量积累那些"可用性高"的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题，Fdisk 命令是搞不定的，而这里提到的 partprobe 命令 刚好派上用场。

以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题，积少成多，也就有用了。

--EOF--

Updated:

• Linux 的 Out-of-Memory Killer

数据结构原型

字段               数据类型         
Path_query         Varchar(255)        PK         
Domain             Varchar(50)                         
Owner              Bigint                              
When               Date                                
Object-ID          Bigint                              
Object-Type        Tinyint                             
Counts and stuff   Various ints        May be some keys

主键是字符串，开销太大。其他的索引如果做主键，也比较大。当表大小超过内存的时候，插入速度很慢，I/O 能力也上不来。

优化数据结构

数据预处理，通过 CONV(SUBSTR(MD5(Url),0,16),16,10) 把 Path_query 修改为 64 位的 ID (8字节), 主键为 ID+Owner+object+object-type，这个统计信息很容易抽象到一个数据对象，这个索引的设计也在于此。

另外补充一点，利用 PHP 的 ip2long() 和 long2ip() 函数对 IP 地址作预处理，耗费的存储空间只为原来地 25%，这是个很有趣的技巧。

数据 Sharding

对于海量的数据，以一个礼拜为间隔，水平分割。按照不同的数据力度每周一个表，每年一个全局表，再加上一个汇总表。数据量越大，InnoDB 存储引擎针对字符串的索引浪费的空间就越大。单个查询的 I/O 也自然大了起来。

所有应用对 DB 的响应要求 是 300 毫秒。但高并发写入的时候响应时间就糟糕起来。Flickr 的 Java 牛人实现了 Referral 队列，每 4000 条做批量处理。这样 IO 拥塞的就解决掉了。

总体的服务器规模过去 介绍过，对专业版用户的数据是永久保留的，而普通用户则只保留几周，为节省空间，采用 MyISAM 引擎，当用户转为专业版时，迁移数据。

补充一下，抓取 URL 是用的 curl 。最后，这篇 PPT 在线观看。

--EOF--

Cache 为 王

任何一个成功的站点都有一套最合适自己的 Cache 策略。

Note：这个层次图画的稍微有点问题，不是严格从上到下的。

The Alternative PHP Cache , APC

Facebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。

Lucas Nealan 的 PPT 举了一个例子，一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下，性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

Memcached 层

APC Cache 的是非用户相关的信息，而用户相关的数据 Cache 当然是在 Memcached 中。

Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。

程序 Profiling

Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。

补充一下：语言的选择

为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: "Languages's don't Scale, Architecture Scale"。

从 80-20 的原则看，APC 和 Memcached 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。

(上面的图是从 Lucas Nealan 的文档截的，版权所有是他的)

--EOF--

Skype 在数据库上的横向扩展能力以 PL/Proxy 为基础的。其实几乎所有部署 MySQL 的站点也都在考虑 Scale Out (相比 Scale Up) 的扩展方案，也有 MySQL Proxy 这样的产品推出来，只是看起来还不够成熟。PL/Proxy 的设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发，示意图如下：

PL/Proxy 的设计初衷就是在这一层充当"数据总线"的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。（虽然随着服务器越多，通信的开销越大，但只要不大于某个规模，似乎还不足以成为比较大的问题)

随着数据总线层的水平扩展，连接池的问题就凸显出来。Skype 在连接池上的解决方案是采用 PgBouncer，PgBouncer 极大地增强了 PostgreSQL 的连接数扩展能力。顺便说一下，"池"有三种级别：Session 池、事务池、语句池。

Skype 另外开发了一套工具包： SkyTools 来进行数据库的维护，主要是解决数据的复制与队列以及失败接管问题。

整体看下来，围绕着 PostgreSQL 的解决方案其实蛮成熟的。BTW，看起来挺适合阿里旺旺的 :)

--EOF--

Alexa 的相关数据

Alexa 超过 1000 台 Linux 服务器 Farm，每半年增长 300T 新数据。经过了同类产品的选型后，最后选择了 Ibrix 融合文件系统。

SAN 使用的是 HP Modular Smart Array (MSA1000) ，最大支持 12T ，Cache I/O 最大 3 万个，算是个中低端的阵列。Amazon 没有透漏这套系统的吞吐能力，只是说 Ibrix 这套系统能达到 1T 的 I/O 聚合能力，单个 NameSpace 可达 16PB 容量。

不过从现在的一些迹象上来看，Amazon 对存储层重新做了改造。这套解决方案被替换掉了也说不定.

AOL 的相关数据

原有状况：3000 台主机通过 10000 多个光纤通道端口连接到传统的 SAN 上。其中有 8PB 的非结构化数据，分布在大约 1000 台 文件服务器上。管理维护的复杂度可想而知。

解决方案：文件服务器采用直连的磁盘，每个 12 块 700GB 的 ATA 磁盘，然后通过 Ibrix 融合文件系统进行集群化。

看起来，Ibrix 提供的解决方案很有竞争力。现在一些比较大的用户对于存储层的集群的需求越来越多，快成为趋势，一揽子解决方案还是有必要的，毕竟不是每家技术能力都强如 Amazon、Google ，有的时候用第三方的成本是能小于自己动手 DIY 的。

--EOF--