Facebook近期兩次宕機 禍起數(shù)據(jù)庫集群？
原創(chuàng)【51CTO綜合報道】據(jù)國外媒體報道，全球***的社交網(wǎng)絡Facebook由于其數(shù)據(jù)中心內(nèi)發(fā)生錯誤，導致停機長達兩小時之久。這是Facebook運行4年以來停機最長的時間。該網(wǎng)站就這次時間對用戶造成的不便深表歉意。
51CTO向您推薦：《世界***的PHP站點 Facebook后臺技術探秘》和《專訪人人網(wǎng)黃晶：SNS網(wǎng)站后臺架構探秘》，以便于您了解國外SNS網(wǎng)站與國內(nèi)SNS網(wǎng)站。
關于這次故障發(fā)生的原因，官方最初的說法是一個自動驗證值系統(tǒng)出現(xiàn)了不正?，F(xiàn)象，使得其產(chǎn)生的錯誤遠比其修復的錯誤多。但是究其根本，更主要的原因是由于一個錯誤的配置從而引起的數(shù)據(jù)庫集群進入反饋循環(huán)。所以該網(wǎng)站不得不關閉了數(shù)據(jù)庫集群來恢復正確的配置，這也就是為什么Facebook的用戶會有兩個多小時打不開網(wǎng)站的原因。
原因分析：
Facebook數(shù)據(jù)庫的配置值發(fā)生了變化，在處理錯誤的時候應該檢測無效的配置值，并更新指定的配置值。但是新的配置值很快被系統(tǒng)認定為無效，這樣就形成了一個死循環(huán)。更糟糕的是，每當一個客戶發(fā)現(xiàn)錯誤并嘗試重新查詢數(shù)據(jù)庫時，會打斷它并認定它是無效值，并刪除之前的緩存值從而創(chuàng)造更多的錯誤。這就意味著原先的問題還沒有解決，新的請求流又產(chǎn)生了。在經(jīng)過一段時間后，數(shù)據(jù)庫就無法處理相關請求，數(shù)據(jù)庫自己產(chǎn)生了更多的請求給自己。我們已經(jīng)進入一個反饋循環(huán)（feedback loop ）
Facebook全球知名SNS網(wǎng)站
Facebook的官方主頁***強調(diào)說：“我們對這次停運事件表示十分抱歉，但我們希望我們的用戶知道，F(xiàn)acebook對于網(wǎng)站的性能和可靠性非常的重視。
延伸閱讀
在后臺架構中，數(shù)據(jù)庫一直是我們關心的重點。曾經(jīng)日壯山河的關系型數(shù)據(jù)庫，在NoSQL運動下，仿佛顯得日薄西山，這句話用在SNS站點中再合適不過了。沒錯，由于SNS站點的高復雜性，其對數(shù)據(jù)庫的要求非常高，高性能、可擴展性以及可用性，缺一不可。
Facebook并不是一個傳統(tǒng)意義上的LAMP站點，MySQL也主要作為一個Key-value的持久性存儲使用，而它的存儲系統(tǒng)則是NoSQL運動的一個重要組成部分——Cassandra，它的特點也正是SNS站點所需求的，盡管很多人認為NoSQL還不夠成熟，缺乏可靠性，但Facebook的成功卻是一個活生生的例子。
Facebook數(shù)據(jù)庫架構圖，請點擊原圖查看
Memcached是Facebook用到的一個分布式內(nèi)存緩存系統(tǒng)，其已成為互聯(lián)網(wǎng)最有名氣的軟件之一了。當然，緩存的手段是多種多樣的，僅僅保證日常后臺的穩(wěn)定運行也是不夠的。面對一些突發(fā)事件，緩存機制更是尤為重要，特別是在數(shù)據(jù)庫服務器與Web服務器上。此次出現(xiàn)的問題雖然與Memcached沒有多大的關系，但是數(shù)據(jù)庫的正確配置，卻是我們需要注意的部分。
【編輯推薦】
