Facebook近期两次宕机祸起数据库集群？

【综合报道】据国外媒体报道，全球***的社交网络Facebook由于其数据中心内发生错误，导致停机长达两小时之久。这是Facebook运行4年以来停机最长的时间。该网站就这次时间对用户造成的不便深表歉意。

向您推荐：《世界***的PHP站点 Facebook后台技术探秘》和《专访人人网黄晶：SNS网站后台架构探秘》，以便于您了解国外SNS网站与国内SNS网站。

关于这次故障发生的原因，官方最初的说法是一个自动验证值系统出现了不正常现象，使得其产生的错误远比其修复的错误多。但是究其根本，更主要的原因是由于一个错误的配置从而引起的数据库集群进入反馈循环。所以该网站不得不关闭了数据库集群来恢复正确的配置，这也就是为什么Facebook的用户会有两个多小时打不开网站的原因。

原因分析：

Facebook数据库的配置值发生了变化，在处理错误的时候应该检测无效的配置值，并更新指定的配置值。但是新的配置值很快被系统认定为无效，这样就形成了一个死循环。更糟糕的是，每当一个客户发现错误并尝试重新查询数据库时，会打断它并认定它是无效值，并删除之前的缓存值从而创造更多的错误。这就意味着原先的问题还没有解决，新的请求流又产生了。在经过一段时间后，数据库就无法处理相关请求，数据库自己产生了更多的请求给自己。我们已经进入一个反馈循环（feedback loop ）

[[15743]]

Facebook全球知名SNS网站

Facebook的官方主页***强调说：“我们对这次停运事件表示十分抱歉，但我们希望我们的用户知道，Facebook对于网站的性能和可靠性非常的重视。

延伸阅读

在后台架构中，数据库一直是我们关心的重点。曾经日壮山河的关系型数据库，在NoSQL运动下，仿佛显得日薄西山，这句话用在SNS站点中再合适不过了。没错，由于SNS站点的高复杂性，其对数据库的要求非常高，高性能、可扩展性以及可用性，缺一不可。

Facebook并不是一个传统意义上的LAMP站点，MySQL也主要作为一个Key-value的持久性存储使用，而它的存储系统则是NoSQL运动的一个重要组成部分——Cassandra，它的特点也正是SNS站点所需求的，尽管很多人认为NoSQL还不够成熟，缺乏可靠性，但Facebook的成功却是一个活生生的例子。

Facebook数据库架构图，请点击原图查看

Memcached是Facebook用到的一个分布式内存缓存系统，其已成为互联网最有名气的软件之一了。当然，缓存的手段是多种多样的，仅仅保证日常后台的稳定运行也是不够的。面对一些突发事件，缓存机制更是尤为重要，特别是在数据库服务器与Web服务器上。此次出现的问题虽然与Memcached没有多大的关系，但是数据库的正确配置，却是我们需要注意的部分。

【编辑推荐】