tair 是淘寶的一個開源項目，它是一個分布式的key/value結構數據的解決方案。
作為一個分布式系統，Tair由一個中心控制節點（config server）和一系列的服務節點（data server）組成，
- config server 負責管理所有的data server，並維護data server的狀態信息；為了保證高可用（High Available），config server可通過hearbeat 以一主一備形式提供服務；
- data server 對外提供各種數據服務，並以心跳的形式將自身狀況匯報給config server；所有的 data server 地位都是等價的。
tair集群的基本概念：
- configID，唯一標識一個tair集群，每個集群都有一個對應的configID，在當前的大部分應用情況下configID是存放在diamond中的，對應了該集群的configserver地址和groupname。業務在初始化tair client的時候需要配置此ConfigID。
- namespace，又稱area， 是tair中分配給應用的一個內存或者持久化存儲區域， 可以認為應用的數據存在自己的namespace中。 同一集群（同一個configID）中namespace是唯一的。通過引入namespace，我們可以支持不同的應用在同集群中使用相同的key來存放數據，也就是key相同，但內容不會沖突。一個namespace下是如果存放相同的key，那么內容會受到影響，在簡單K/V形式下會被覆蓋，rdb等帶有數據結構的存儲引擎內容會根據不同的接口發生不同的變化。
- quota配額，對應了每個namespace儲存區的大小限制，超過配額后數據將面臨最近最少使用（LRU）的淘汰。持久化引擎（ldb）本身沒有配額，ldb由於自帶了mdb cache，所以也可以設置cache的配額。超過配額后，在內置的mdb內部進行淘汰。
- expireTime，數據的過期時間。當超過過期時間之后，數據將對應用不可見，不同的存儲引擎有不同的策略清理掉過期的數據。
存儲引擎
tair 分為持久化和非持久化兩種使用方式：
- 非持久化的 tair 可以看成是一個分布式緩存；
- 持久化的 tair 將數據存放於磁盤中，為了解決磁盤損壞導致數據丟失，tair 可以配置數據的備份數目。tair 自動將一份數據的不同備份放到不同的主機上，當有主機發生異常，無法正常提供服務的時候，其余的備份會繼續提供服務。
Tair的存儲引擎有一個抽象層，只要滿足存儲引擎需要的接口，便可以很方便的替換Tair底層的存儲引擎。比如你可以很方便的將bdb、tc、redis、leveldb甚至MySQL作為Tair的存儲引擎，而同時使用Tair的分布方式、同步等特性。
Tair主要有下面三種存儲引擎：
- mdb，定位於cache緩存，類似於memcache。支持k/v存取和prefix操作；
- rdb，定位於cache緩存，采用了redis的內存存儲結構。支持k/v，list，hash，set，sortedset等數據結構；
- ldb，定位於高性能存儲，采用了levelDB作為引擎，並可選擇內嵌mdb cache加速，這種情況下cache與持久化存儲的數據一致性由tair進行維護。支持k/v，prefix等數據結構。今后將支持list，hash，set，sortedset等redis支持的數據結構。
MDB流程
RDB流程
LDB流程
fastdump
大數據量導入：數據預排序，按桶分memtable。
分布式策略
tair 的分布采用的是一致性哈希算法，對於所有的key，分到Q個桶中，桶是負載均衡和數據遷移的基本單位。config server 根據一定的策略把每個桶指派到不同的data server上，因為數據按照key做hash算法，所以可以認為每個桶中的數據基本是平衡的，保證了桶分布的均衡性, 就保證了數據分布的均衡性。
具體說，首先計算Hash(key)，得到key所對應的bucket，然后再去config server查找該bucket對應的data server，再與相應的data server進行通信。也就是說，config server維護了一張由bucket映射到data server的對照表，比如：
bucket data server
0 192.168.10.1 1 192.168.10.2 2 192.168.10.1 3 192.168.10.2 4 192.168.10.1 5 192.168.10.2
這里共6個bucket，由兩台機器負責，每台機器負責3個bucket。客戶端將key hash后，對6取模，找到負責的數據節點，然后和其直接通信。表的大小（行數）通常會遠大於集群的節點數，這和consistent hash中的虛擬節點很相似。
假設我們加入了一台新的機器——192.168.10.3，Tair會自動調整對照表，將部分bucket交由新的節點負責，比如新的表很可能類似下表：
0 192.168.10.1 1 192.168.10.2 2 192.168.10.1 3 192.168.10.2 4 192.168.10.3 5 192.168.10.3
在老的表中，每個節點負責3個桶，當擴容后，每個節點將負責2個桶，數據被均衡的分布到所有節點上。
如果有多個備份，那么對照表將包含多列，比如備份是為3，則表有4列，后面的3列都是數據存儲的節點。
為了增強數據的安全性，Tair支持配置數據的備份數（COPY_COUNT）。比如你可以配置備份數為3，則每個bucket都會寫在不同的3台機器上。當數據寫入一個節點（通常我們稱其為主節點）后，主節點會根據對照表自動將數據寫入到其他備份節點，整個過程對用戶是透明的。
當有新節點加入或者有節點不可用時，config server會根據當前可用的節點，重新build一張對照表。數據節點同步到新的對照表時，會自動將在新表中不由自己負責的數據遷移到新的目標節點。遷移完成后，客戶端可以從config server同步到新的對照表，完成擴容或者容災過程。整個過程對用戶是透明的，服務不中斷。
為了更進一步的提高數據的安全性，Tair的config server在build對照表的時候，可以配置考慮機房和機架信息。比如你配置備份數為3，集群的節點分布在兩個不同的機房A和B，則Tair會確保每個機房至少有一份數據。當A機房包含兩份數據時，Tair會確保這兩份數據會分布在不同機架的節點上。這可以防止整個機房發生事故和某個機架發生故障的情況。這里提到的特性需要節點物理分布的支持，當前是通過可配置的IP掩碼來區別不同機房和機架的節點。
Tair 提供了兩種生成對照表的策略：
- 負載均衡優先，config server會盡量的把桶均勻的分布到各個data server上，所謂盡量是指在不違背下面的原則的條件下盡量負載均衡：每個桶必須有COPY_COUNT份數據； 一個桶的各份數據不能在同一台主機上；
- 位置安全優先，一般我們通過控制 _pos_mask（Tair的一個配置項） 來使得不同的機房具有不同的位置信息，一個桶的各份數據不能都位於相同的一個位置（不在同一個機房）。
位置優先策略還有一個問題，假如只有兩個機房，機房1中有100台data server，機房2中只有1台data server。這個時候，機房2中data server的壓力必然會非常大，於是這里產生了一個控制參數 _build_diff_ratio（參見安裝部署文檔），當機房差異比率大於這個配置值時，config server也不再build新表，機房差異比率是如何計出來的呢？首先找到機器最多的機房，不妨設使RA，data server數量是SA，那么其余的data server的數量記做SB，則機房差異比率=|SA – SB|/SA，因為一般我們線上系統配置的COPY_COUNT=3，在這個情況下，不妨設只有兩個機房RA和RB，那么兩個機房什么樣的data server數量是均衡的范圍呢? 當差異比率小於 0.5的時候是可以做到各台data server負載都完全均衡的。這里有一點要注意，假設RA機房有機器6台，RB有機器3台，那么差異比率 = 6 – 3 / 6 = 0.5，這個時候如果進行擴容，在機房A增加一台data server，擴容后的差異比率 = 7 – 3 / 7 = 0.57，也就是說，只在機器數多的機房增加data server會擴大差異比率。如果我們的_build_diff_ratio配置值是0.5，那么進行這種擴容后，config server會拒絕再繼續build新表。
一致性和可靠性
分布式系統中的可靠性和一致性是無法同時保證的，因為我們必須允許網絡錯誤的發生。tair 采用復制技術來提高可靠性，並且為了提高效率做了一些優化。事實上在沒有錯誤發生的時候，tair 提供的是一種強一致性，但是在有data server發生故障的時候，客戶有可能在一定時間窗口內讀不到最新的數據，甚至發生最新數據丟失的情況。
version
Tair中的每個數據都包含版本號，版本號在每次更新后都會遞增。這個特性可以幫助防止數據的並發更新導致的問題。
如何獲取到當前key的version？
get接口返回的是DataEntry對象，該對象中包含get到的數據的版本號，可以通過getVersion()接口獲得該版本號。
在put時，將該版本號作為put的參數即可。 如果不考慮版本問題，則可設置version參數為0，系統將強行覆蓋數據，即使版本不一致。
很多情況下，更新數據是先get，然后修改get回來的數據，再put回系統。如果有多個客戶端get到同一份數據，都對其修改並保存，那么先保存的修改就會被后到達的修改覆蓋，從而導致數據一致性問題,在大部分情況下應用能夠接受，但在少量特殊情況下，這個是我們不希望發生的。
比如系統中有一個值”1”, 現在A和B客戶端同時都取到了這個值。之后A和B客戶端都想改動這個值，假設A要改成12，B要改成13，如果不加控制的話，無論A和B誰先更新成功，它的更新都會被后到的更新覆蓋。Tair引入的version機制避免了這樣的問題。剛剛的例子中，假設A和B同時取到數據，當時版本號是10，A先更新，更新成功后，值為12，版本為11。當B更新的時候，由於其基於的版本號是10，此時服務器會拒絕更新，返回version error，從而避免A的更新被覆蓋。B可以選擇get新版本的value，然后在其基礎上修改，也可以選擇強行更新。
Version改變的邏輯如下：
- 如果put新數據且沒有設置版本號，會自動將版本設置成1；
- 如果put是更新老數據且沒有版本號，或者put傳來的參數版本與當前版本一致，版本號自增1；
- 如果put是更新老數據且傳來的參數版本與當前版本不一致，更新失敗，返回VersionError；
- put時傳入的version參數為0，則強制更新成功，版本號自增1。
version具體使用案例，如果應用有10個client會對key進行並發put，那么操作過程如下：
- get key，如果成功，則進入步驟2；如果數據不存在，則進入步驟3；
- 在調用put的時候將get key返回的verison重新傳入put接口，服務端根據version是否匹配來返回client是否put成功；
- get key數據不存在，則新put數據。此時傳入的version必須不是0和1，其他的值都可以（例如1000，要保證所有client是一套邏輯）。因為傳入0，tair會認為強制覆蓋；而傳入1，第一個client寫入會成功，但是新寫入時服務端的version以0開始計數啊，所以此時version也是1，所以下一個到來的client寫入也會成功，這樣造成了沖突
version分布式鎖
Tair中存在該key，則認為該key所代表的鎖已被lock；不存在該key，在未加鎖。操作過程和上面相似。業務方可以在put的時候增加expire，已避免該鎖被長期鎖住。
當然業務方在選擇這種策略的情況下需要考慮並處理Tair宕機帶來的鎖丟失的情況。
config server
client 和 config server的交互主要是為了獲取數據分布的對照表，當client啟動時獲取到對照表后，會cache這張表，然后通過查這張表決定數據存儲的節點，所以請求不需要和config server交互，這使得Tair對外的服務不依賴configserver，所以它不是傳統意義上的中心節點，也並不會成為集群的瓶頸。
config server維護的對照表有一個版本號，每次新生成表，該版本號都會增加。當有data server狀態發生變化（比如新增節點或者有節點不可用了）時，configserver會根據當前可用的節點重新生成對照表，並通過數據節點的心跳，將新表同步給data server。當client請求data server時，后者每次都會將自己的對照表的版本號放入response中返回給客client，client接收到response后，會將data server返回的版本號和自己的版本號比較，如果不相同，則主動和config server通信，請求新的對照表。
這使得在正常的情況下，client不需要和configserver通信，即使config server不可用了，也不會對整個集群的服務造成大的影響。有了config server，client不需要配置data server列表，也不需要處理節點的的狀態變化，這使得Tair對最終用戶來說使用和配置都很簡單。
容災
當有某台data server故障不可用的時候，config server會發現這個情況，config server負責重新計算一張新的桶在data server上的分布表，將原來由故障機器服務的桶的訪問重新指派到其它有備份的data server中。這個時候，可能會發生數據的遷移，比如原來由data server A負責的桶，在新表中需要由 B負責，而B上並沒有該桶的數據，那么就將數據遷移到B上來。同時，config server會發現哪些桶的備份數目減少了，然后根據負載情況在負載較低的data server上增加這些桶的備份。
擴容
當系統增加data server的時候，config server根據負載，協調data server將他們控制的部分桶遷移到新的data server上，遷移完成后調整路由。
注意：
不管是發生故障還是擴容，每次路由的變更，config server都會將新的配置信息推給data server。在client訪問data server的時候，會發送client緩存的路由表的版本號，如果data server發現client的版本號過舊，則會通知client去config server取一次新的路由表。如果client訪問某台data server 發生了不可達的情況(該 data server可能宕機了)，客戶端會主動去config server取新的路由表。
遷移
當發生遷移的時候，假設data server A 要把 桶 3,4,5 遷移給data server B。因為遷移完成前，client的路由表沒有變化，因此對 3, 4, 5 的訪問請求都會路由到A。現在假設 3還沒遷移，4 正在遷移中，5已經遷移完成，那么：
- 如果是對3的訪問，則沒什么特別，跟以前一樣；
- 如果是對5的訪問，則A會把該請求轉發給B，並且將B的返回結果返回給client；
- 如果是對4的訪問，在A處理，同時如果是對4的修改操作，會記錄修改log，桶4遷移完成的時候，還要把log發送到B，在B上應用這些log，最終A B上對於桶4來說，數據完全一致才是真正的遷移完成；
Tair更多功能
客戶端
tair 的server端是C++寫的，因為server和客戶端之間使用socket通信，理論上只要可以實現socket操作的語言都可以直接實現成tair客戶端。目前實際提供的客戶端有java 和 C++， 客戶端只需要知道config server的位置信息就可以享受tair集群提供的服務了。
plugin支持
Tair還內置了一個插件容器，可以支持熱插拔插件。
插件由config server配置，config server會將插件配置同步給各個數據節點，數據節點會負責加載/卸載相應的插件。
插件分為request和response兩類，可以分別在request和response時執行相應的操作，比如在put前檢查用戶的quota信息等。
插件容器也讓Tair在功能方便具有更好的靈活性。
原子計數支持
Tair從服務器端支持原子的計數器操作，這使得Tair成為一個簡單易用的分布式計數器。
item支持
Tair還支持將value視為一個item數組，對value中的部分item進行操作。比如有一個key的value為 [1,2,3,4,5]，我們可以只獲取前兩個item，返回[1,2]，也可以刪除第一個item。還支持將數據刪除，並返回被刪除的數據，通過這個接口可以實現一個原子的分布式FIFO的隊列。
客戶端
目前淘寶開源的客戶端有C++和Java兩個版本，不過tair如果作為存儲層，前端肯定還需部署Nginx這樣的web服務器，以Nginx為例，淘寶似乎還沒有開源其tair模塊，春哥（agentzh）也沒有公布tair的lua插件，如果想在Nginx里面訪問tair，目前似乎還沒有什么辦法了，除非自己去開發一個模塊。