作者：劉旭暉 Raymond 轉載請註明出處

== 目標問題 ==

TAO的目標問題是構建一個在Facebook這樣大規模的社交類分散式應用服務中，能夠從海量相關聯的資料中高效的生成精確定製化內容的資料倉庫。其應用場合具有全球性，海量動態變化資料，高併發查詢等特性。

== 核心思想 ==

Facebook的社交網路服務的資料模型是基於物件和物件之間的關聯來構建的。資料主要表現為物件和關聯兩類，物件如使用者，圖片，帖子，評論，一次checkin等等，關聯就是各種物件之間的關係，朋友阿，誰的帖子阿，針對哪個帖子的評論啦等等。所有物件和關聯都有一個ID欄位作為唯一標識。

在這種應用模型下，各種離散的資料之間都有眾多的關聯關係，難以簡單的分類處理，最終的應用展現也千變萬化，因此眾多的工作不是在更新資料時完成，而只能在查詢時再進行處理，所以是一個

Facebook原有的框架靠應用程式分別與MySQL和Memcached伺服器互動來管理和快取資料。問題在於memcached不能有效的利用上這種物件關聯模型的資訊，各個client也不能有效地全域性規劃管理cache，在資料更新後的一致性方面也存在較高的代價。

TAO依舊以MySQL為底層資料庫來儲存資料，資料以ID劃分到眾多的shard上，每個MySQL伺服器負責管理若干個Shard，TAO的快取層中，多臺Cache伺服器組成一個Tier，一個Tier包含了支援所有TAO操作請求所需的資訊。客戶端程式通過類似的Shard演算法與特定的Cache伺服器通訊，由

== 實現 ==

為了提高併發處理的能力，TAO的快取層實際由兩級的Tier組成（一個Leader和多個Follower），客戶端與就近的Follower Tier通訊，而FollowerTier將寫請求轉發通過Leader Tier完成，讀請求主要由Follower Tier完成，除非有資料Miss不在快取中的，才向Leader Tier傳送請求。

可以看到Followers並不與資料庫互動。為了適應全球化的佈局，減少全域性網路通訊延遲帶來的影響，TAO的資料庫和快取層實際上如上圖所示，又進一步劃分為Master/Slave Region

以上Region的劃分是增對每一個Shard，不同的Shard可能由不同的Master負責，由於關聯的更新操作可能涉及多個Shard，為了減少通訊開銷，所有的Master還是傾向於分配在同一個Region內部。

值得注意的是，每個Region都需要有完整的資料，而因為資料量巨大，所以單個Region可能是由多個地域上接近的資料中心組成的。

== 相關研究，專案等 ==

由於快取層的存在，由RMDBS資料庫（這裡的MySQL）保證的ACID方面的指標，在一定程度上被減弱了。當然根據CAP理論，這也是大規模分散式資料庫不可避免的問題，通常都會降低一致性要求。在TAO中，犧牲C不完全是出於滿足AP的要求，很大一部分的原因是為了解決latency的問題，類似於這裡說的：http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html

其它全球規模的資料庫，如Google的Megastore，Spanner等系統，通過Paxos，GPS，原子時鐘等各種機制保證資料的讀寫一致性。而從上面可以看到TAO在資料一致性方面，採用的是漸進一致性，存在讀取過時資料等各種問題，整體的多層框架也有拼湊的感覺，但總體上來說，一切還是為了最大化海量併發請求下的吞吐率所做的妥協。