Facebook近期兩次宕機 禍起數據庫集群？
原創【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沒有多大的關系，但是數據庫的正確配置，卻是我們需要注意的部分。
【編輯推薦】
