如何設計、建造和運維一個能夠支撐互聯網時代社交媒體的，每秒併發超過千萬QPS流量的分佈式系統？讓運維高性能和高擴展性的後臺系統不再是生命中不能承受之重？本篇活動家就為大家帶來主題《Twitter 千萬 QPS 分佈式系統的架構設計和高效運維》
分享者
王亞雷
清華本科,美國德州大學奧斯汀分校碩士。十多年從事互聯網服務平臺，分佈式計算和數據存儲的開發和技術管理工作。先後任職微軟總部、eBay 和 Twitter 總部。
一、形形色色的數據庫
Twitter 整體存儲架構有如下四套系統：
1、NoSql，主要包括用戶信息、比較小的數字；當時大約有三萬多節點。
2.、大文件系統，主要是存儲圖片、video 等大數據文件。與 NoSql 同樣，也有三萬多個節點。
3.、Hadoop 系統，主要用於後臺數據處理、分析；最多的時候有九千個節點左右。
4.、MySQL，簡單、比較複雜的關係性數據查詢
各種數據庫的 CAP
說到數據庫，不得不說的就是 CAP。CAP 是什麼呢？C就是一致性。A是可用性。P就是分區容錯性。
Eric Brewer 證明了在 CAP 三個訴求中，你只能滿足兩個；永遠做不到三個。所以你做數據庫設計的時候就要考慮應用場景是什麼；犧牲那個特性來取得另一外兩個特性。
事實上所有的數據庫，包括現在新興的數據庫都遵從這個 CAP 原則。它們針對某個應用場景做優化，沒有一個大而統什麼都能用的系統。
下面是不同類型數據庫對 CAP 的抉擇：
關係型數據庫，主要應用於交易系統；例如銀行系統。因此它是強一致性的；放棄了A。
NoSql 的好處在於它的高併發，能夠支撐很高的併發數；但是一致性稍差，是最終一致的。
NewSQL, 如 google 的 spanner 號稱能夠同時滿足 CAP 三個；實際上是採取了一些措施來增強網絡的穩定性，把網絡出現 partition 的可能性降低很低。但是理論上還是 不能突破 CAP。
特殊用途的數據庫；例如時間序列型的 OpenTSDB，文檔型的 mongoDB 以及圖數據庫 Neo4j 等。
還沒看夠或看懂？點擊右上角，關注活動家，及時獲取大會嘉賓演講乾貨及視頻！
精彩閱讀：
閱讀更多 活動家 的文章
