<b>Facebook近期两次宕机 祸起数据库集群?</b>[MSSQL防范]

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

51CTO向您举荐:《世界最大的PHP站点 Facebook后台技术探秘》和《专访大家网黄晶:SNS网站后台架构探秘》,以便于您理解国外SNS网站与国内SNS网站.

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

缘由解析:

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

Facebook环球出名SNS网站 

Facebook的官方主页最后夸大说:“我们对这次停运事件表示非常抱愧,但我们但愿我们的用户知道,Facebook关于网站的性能和坚固性非常的器重.

延伸阅读

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

Facebook并非一个传统意义上的LAMP站点,MySQL也主要作为一个Key-value的长期性存储利用,而它的存储系统则是NoSQL运动的一个重要构成部份——Cassandra,它的特点也恰是SNS站点所需求的,固然很多人认为NoSQL还不够成熟,贫乏坚固性,但Facebook的成功倒是一个活生生的例子.

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

Memcached是Facebook用到的一个分布式内存缓存系统,其已成为互联网最闻名望的软件之一了.当然,缓存的手段是多种多样的,仅仅保证平常后台的安定运行也是不够的.面对一些突发事件,缓存机制更是尤为重要,分外是在数据库服务器与Web服务器上.此次呈现的问题固然与Memcached没有多大的关系,但是数据库的精确配置,倒是我们需求注意的部份.