tair緩存
A. TAIR的DataServer內部結構
DataServer負責數據的物理存儲，並根據configserver構建的對照表完成數據的復制和遷移工作。DataServer具備抽象的存儲引擎層，可以很方便地添加新存儲引擎。DataServer還有一個插件容器，可以動態地載入/卸載插件。
抽象的存儲引擎層 Tair的存儲引擎有一個抽象層，只要滿足存儲引擎需要的介面，便可以很方便地替換Tair底層的存儲引擎。比如可以很方便地將bdb、tc甚至MySQL作為Tair的存儲引擎，而同時使用Tair的分布方式、同步等特性。
Tair默認包含兩個存儲引擎：mdb和fdb。
mdb是一個高效的緩存存儲引擎，它有著和memcached類似的內存管理方式。mdb支持使用share memory，這使得在重啟Tair數據節點的進程時不會導致數據的丟失，從而使升級對應用來說更平滑，不會導致命中率的較大波動。
fdb是一個簡單高效的持久化存儲引擎，使用樹的方式根據數據key的hash值索引數據，加快查找速度。索引文件和數據文件分離，盡量保持索引文件在內存中，以便減小IO開銷。使用空閑空間池管理被刪除的空間。
自動的復制和遷移 為了增強數據的安全性，Tair支持配置數據的備份數。比如可以配置備份數為3，則每個數據都會寫在不同的3台機器上。得益於抽象的存儲引擎層，無論是作為cache的mdb，還是持久化的fdb，都支持可配的備份數。
當數據寫入一個節點（通常稱其為主節點）後，主節點會根據對照表自動將數據寫入到其他備份節點，整個過程對用戶是透明的。
當有新節點加入或者有節點不可用時，configserver會根據當前可用的節點，重新build一張對照表。數據節點同步到新的對照表時，會自 動將在新表中不由自己負責的數據遷移到新的目標節點。遷移完成後，客戶端可以從configserver同步到新的對照表，完成擴容或者容災過程。整個過 程對用戶是透明的，服務不中斷。
插件容器 Tair還內置了一個插件容器，可以支持熱插拔插件。
插件由configserver配置，configserver會將插件配置同步給各個數據節點，數據節點會負責載入/卸載相應的插件。
插件分為request和response兩類，可以分別在request和response時執行相應的操作，比如在put前檢查用戶的quota信息等。
插件容器也讓Tair在功能方便具有更好的靈活性。
B. .Net的Cache和Memcached有什麼優缺點
如果你的伺服器只有一台，且資料庫讀寫壓力不大，就沒必要使用Memcached。HttpRuntime.Cache是本地緩存，Memcached是分布式緩存，兩者的區別在於：
本地緩存
本地緩存可能是大家用的最多的一種緩存方式了，不管是本地內存還是磁碟，其速度快，成本低，在有些場合非常有效。
但是對於web系統的集群負載均衡結構來說，本地緩存使用起來就比較受限制，因為當資料庫數據發生變化時，你沒有一個簡單有效的方法去更新本地緩存；然而，你如果在不同的伺服器之間去同步本地緩存信息，由於緩存的低時效性和高訪問量的影響，其成本和性能恐怕都是難以接受的。
分布式緩存
前面提到過，本地緩存的使用很容易讓你的應用伺服器帶上「狀態」，這種情況下，數據同步的開銷09會比較大；尤其是在集群環境中更是如此！
分布式緩存這種東西存在的目的就是為了提供比RDB更高的TPS和擴展性，同時有幫你承擔了數據同步的痛苦；優秀的分布式緩存系統有大家所熟知的Memcached、Redis（當然也許你把它看成是NoSQL，但是我個人更願意把分布式緩存也看成是NoSQL），還有淘寶自主開發的Tair等。
對比關系型資料庫和緩存存儲，其在讀和寫性能上的差距可謂天壤之別；就拿淘寶的Tair來說，mdb引擎的單機QPS已在10w以上，ldb的也達到了5w~7w，而集群的性能會更高（目前uic所用的Tair集群QPS高達數十萬！）。
所以，在技術和業務都可以接受的情況下，我們可以盡量把讀寫壓力從資料庫轉移到緩存上，以保護看似強大，其實卻很脆弱的關系型資料庫。
C. 淘寶tair 為什麼不用redis
redis很好用，提供緩存服務。相比memcached多了N多新數據結構和主從模式增加可用性。不過redis有一點不能滿足一些互聯網公司開發者需求。
redis集群中，想借用緩存資源必須得指明redis伺服器地址去要。這就增加了程序的維護復雜度。因為redis伺服器很可能是需要頻繁變動的。
所以人家淘寶就想啊，為什麼不能像操作分布式資料庫或者hadoop那樣。增加一個中央節點，讓他去代理所有事情。
所以人家就開發了這個tair。程序只要跟tair中心節點交互就OK了。甚至人家還弄了個配置伺服器這種概念。免去了像操作hadoop那樣，還得每台hadoop一套一模一樣配置文件。改配置文件得整個集群都跟著改。
tair使用了google在bigtable裡面的merge-mp模型。
底層存儲可以用redis或者google的levelDB.而且人家淘寶已經把他開源了。
http://tair.taobao.org/
未來，如果你用redis不弄個中央節點。你還好意思說你會redis嗎？
D. LevelDB 可以用來替換 Redis 做緩存嗎
可能很多人都不知道RedisStorage 和redis 之間的區別。
redis的存儲是存儲在內存里的, RedisStorage可以選擇存儲在磁碟里.
當redis崩潰的時候。redis 會從rdb或者aof文件重新讀取數據到內存里。如果數據量很大的話。這個初始化是相當的慢。(這就是 redis的假數據持久)。
RedisStorage 是直接存儲在 磁碟里。所以不存在這個數據重載入問題。
還有redis 存儲是受物理內存限制的，比如你有幾千萬或者幾億的數據。如果存儲在redis里。那得需要多巨大的內存了。使用RedisStorage 就沒有物理內存限制這個問題。最大可以存儲十億數據。
最後說一下淘寶的Tair ldb項目。同樣基於leveldb 存儲引擎。 廣泛的用在 登錄淘寶、查看商品詳情頁面、在淘江湖和好友「搗漿糊」等。 說明leveldb 數據引擎的可靠性和海量數據存儲。 但是開源版的Tair ldb 並不好用。所以自己寫了個基於 leveldb的 server端。
E. 什麼是分布式存儲系統
分布式存儲系統
定義
分布式存儲系統是大量普通PC伺服器通過Internet互聯，對外作為一個整體提供存儲服務
特性
可擴展
低成本
高性能
易用
挑戰
分布式存儲系統的挑戰主要在於數據、狀態信息的持久化，要求在自動遷移、自動容錯、並發讀寫的過程中保證數據的一致性。分布式存儲涉及的技術主要來自兩個領域：分布式系統以及資料庫。
分類
非結構化數據，一般的文檔
結構化數據， 存儲在關系資料庫中
半結構化數據，HTML文檔
不同的分布式存儲系統適合處理不同類型的數據：
分布式文件系統
非結構化數據，這類數據以對象的形式組織，不同對象之間沒有關聯，這樣的數據一般稱為Blob（二進制大對象）數據
典型的有Facebook Haystack 以及 Taobao File System
另外，分布式文件系統也常作為分布式表格系統以及分布式資料庫的底層存儲，如谷歌的GFS可以作為分布式表格系統Google Bigtable 的底層存儲，Amazon的EBS（彈性存儲塊）系統可以作為分布式資料庫（Amazon RDS）的底層存儲
總體上看，分布式文件系統存儲三種類型的數據：Blob對象、定長塊以及大文件
分布式鍵值系統
較簡單的半結構化數據，只提供主鍵的CRUD（創建、讀取、更新、刪除）
典型的有Amazon Dynamo 以及 Taobao Tair
分布式表格系統
較復雜的半結構化數據，不僅支持CRUD，而且支持掃描某個主鍵范圍
以表格為單位組織數據，每個表格包括很多行，通過主鍵標識一行，支持根據主鍵的CRUD功能以及范圍查找功能
典型的有Google Bigtable 以及 Megastore，Microsoft Azure Table Storage，Amazon DynamoDB等
分布式資料庫
存儲結構化數據，一般是由單機關系資料庫擴展而來
典型的包括MySQL資料庫分片集群、Amazon RDS以及Microsoft SQL Azure
F. TAIR的Tair的功能
Tair是一個Key/Value結構數據的解決方案，它默認支持基於內存和文件的兩種存儲方式，分別與緩存和持久化存儲對應。
Tair除了普通Key/Value系統提供的功能，比如get、put、delete以及批量介面外，還有一些附加的實用功能，使得其有更廣的適用場景，包括：
Version支持
原子計數器
Item支持
G. 怎麼搭建一個tair緩存伺服器
能啊，不過不知你要怎麼做。
一般來說，對企業級用戶才需要這些功能。主要就是避開上網高峰期，利用夜間來把網頁等內容緩存下來，到了白天再用，再打開時可以看到網頁是前一天或當天凌晨的。不過，不要緊，一點「刷新」就好了，因為大部分內容都下來了，改動也就很少，瀏覽網頁的速度也就很快了。
方法我知道有兩種，都是基於系統伺服器的：1 WINDOWS系統下可以裝一個ISA2000之類的軟體，它可以提供防火牆、NAT、緩存三大功能。這個軟體一時半會說不清楚，你可以自己下一個下來慢慢來，並不是很難。2 LINUX系統下也可以實現，在安裝了一個叫squid的服務後，這個功能就可以再通過配置來實現，不過配置全是用命令，有點困難了。
最後，建議用ISA來做，或者找些專用的小軟體之類的。順便問一下，你該不是在開網吧，自學吧。
H. e照通緩存中未查詢到key
分布式緩存是網站服務端經常用到的一種技術.
在讀多寫少的業務場景中，通過使用緩存可以有效地支撐高並發的訪問量，對後端的資料庫等數據源做到很好地保護。現在市面上有很多分布式緩存，比如Redis、Memcached以及阿里的Tair等，不管我們使用的哪種緩存產品，基本上都會遇到緩存擊穿、緩存失效以及熱點key的問題。如何有效地防止這些問題，也是我們在享受緩存帶來的紅利的同時，必須要解決的難題。
通常我們在使用緩存時都是先檢查緩存中是否存在，如果存在直接返回緩存內容，如果不存在就直接查詢資料庫然後再緩存查詢結果返回.
緩存擊穿：查詢一個資料庫中不存在的數據，比如商品詳情，查詢一個不存在的ID，每次都會訪問DB，如果有人惡意破壞，很可能直接對DB造成過大的壓力。
解決方案：當通過某一個key去查詢數據的時候，如果對應在資料庫中的數據都不存在，我們將此key對應的value設置為一個默認的值，比如「NULL」，並設置一個緩存的失效時間，這時在緩存失效之前，所有通過此key的訪問都被緩存擋住了。後面如果此key對應的數據在DB中存在時，緩存失效之後，通過此key再去訪問數據，就能拿到新的value了。