1.1 系統架構
一個Tair叢集主要包括3個必選子產品：configserver、dataserver和client，一個可選子產品：invalidserver。通常情況下，一個叢集中包含2台configserver及多台dataServer。兩台configserver互為主備并通過維護和dataserver之間的心跳獲知叢集中存活可用的dataserver，建構資料在叢集中的分布資訊（對照表）。dataserver負責資料的存儲，并按照configserver的訓示完成資料的複制和遷移工作。client在啟動的時候，從configserver擷取資料分布資訊，根據資料分布資訊和相應的dataserver互動完成使用者的請求。invalidserver主要負責對等叢集的删除和隐藏操作，保證對等叢集的資料一緻。
從架構上看，configserver的角色類似于傳統應用系統的中心節點，整個叢集服務依賴于configserver的正常工作。但實際上相對來說，tair的configserver是非常輕量級的，當正在工作的伺服器當機的時候另外一台會在秒級别時間内自動接管。而且，如果出現兩台伺服器同時當機的最惡劣情況，隻要應用伺服器沒有新的變化， tair依然服務正常。而有了configserver這個中心節點，帶來的好處就是應用在使用的時候隻需要配置configserver的位址（現在可以直接配置Diamond key），而不需要知道内部節點的情況。
Tair叢集介紹
1.1.1 ConfigServer的功能
1) 通過維護和dataserver心跳來獲知叢集中存活節點的資訊
2) 根據存活節點的資訊來建構資料在叢集中的分布表。
3) 提供資料分布表的查詢服務。
4) 排程dataserver之間的資料遷移、複制。
1.1.2 DataServer的功能
1) 提供存儲引擎
2) 接受client的put/get/remove等操作
3) 執行資料遷移，複制等
4) 插件：在接受請求的時候處理一些自定義功能
5) 通路統計
1.1.3 InvalidServer的功能
1) 接收來自client的invalid/hide等請求後，對屬于同一組的叢集（雙機房獨立叢集部署方式）做delete/hide操作，保證同一組叢集的一緻。
2) 叢集斷網之後的，髒資料清理。
3) 通路統計。
1.1.4 client的功能
1) 在應用端提供通路Tair叢集的接口。
2) 更新并緩存資料分布表和invalidserver位址等。
3) LocalCache，避免過熱資料通路影響tair叢集服務。
4) 流控
1.2 存儲引擎與應用場景
Tair經過這兩年的發展演進，除了應用于cache緩存外，在存儲（持久化）上支援的應用需求也越來越廣泛。現在主要有mdb，rdb，ldb三種存儲引擎。
1.2.1 mdb
定位于cache緩存，類似于memcache。
支援k/v存取和prefix操作
1.2.1.1 mdb的應用場景
在實際業務中，大部分當緩存用（後端有DB之類的資料源）。
也可用做大通路少量臨時資料的存儲（例如session登入，防攻擊統計等）。
集團内絕對多數cache服務都是采用的tair mdb。
1.2.2 rdb
定位于cache緩存，采用了redis的記憶體存儲結構。
支援k/v，list，hash，set，sortedset等資料結構。
1.2.2.1 rdb的應用場景
适用于需要高速通路某些資料結構的應用，例如SNS中常見的的粉絲存儲就可以采用set等結構；或者存儲一個商品的多個屬性（hashmap）；高效的消息隊列（list）等。現在有30個左右的應用在使用rdb服務。
1.2.3 ldb
定位于高性能存儲，并可選擇内嵌mdb cache加速，這種情況下cache與持久化存儲的資料一緻性由tair進行維護。 支援k/v，prefix等資料結構。今後将支援list，hash，set，sortedset等redis支援的資料結構。
1.2.3.1 ldb的應用場景
存儲，裡面可以細分如下場景：
1) 持續大資料量的存入讀取，類似淘寶交易快照。
2) 高頻度的更新讀取，例如計數器，庫存等。
3) 離線大批量資料導入後做查詢。參見fastdump
也可以用作cache：
資料量大，響應時間敏感度不高的cache需求可以采用。例如天貓實時推薦。
1.3 基本概念
1.3.1 configID
唯一辨別一個tair叢集，每個叢集都有一個對應的configID，在目前的大部分應用情況下configID是存放在diamond中的，對應了該叢集的configserver位址和groupname。業務在初始化tairclient的時候需要配置此ConfigID。
1.3.2 namespace
又稱area， 是tair中配置設定給應用的一個記憶體或者持久化存儲區域， 可以認為應用的資料存在自己的namespace中。
同一叢集（同一個configID）中namespace是唯一的。
通過引入namespace，我們可以支援不同的應用在同叢集中使用相同的key來存放資料，也就是key相同，但内容不會沖突。一個namespace下是如果存放相同的key，那麼内容會受到影響，在簡單K/V形式下會被覆寫，rdb等帶有資料結構的存儲引擎内容會根據不同的接口發生不同的變化。
1.3.3 quota配額
對應了每個namespace儲存區的大小限制，超過配額後資料将面臨最近最少使用（LRU）的淘汰。
持久化引擎（ldb）本身沒有配額，ldb由于自帶了mdb cache，是以也可以設定cache的配額。超過配額後，在内置的mdb内部進行淘汰。
1.3.3.1 配額是怎樣計算的
配額大小直接影響資料的命中率和資源利用效率，業務方需要給出一個合适的值，通常的計算方法是評估在保證一定命中率情況下所需要的記錄條數，這樣配額大小即為： 記錄條數 * 平均單條記錄大小。
1.3.3.2 管理者如何配置配額
單份資料情況下，業務提供的配額就是需要配置在Tair系統中的配額。但對于多備份，在系統中實際計算的配額為： 業務配額 * 備份數
1.3.4 expireTime:過期時間
expiredTime 是指資料的過期時間，當超過過期時間之後，資料将對應用不可見，這個設定同樣影響到應用的命中率和資源使用率。不同的存儲引擎有不同的政策清理掉過期的資料。調用接口時，expiredTime機關是秒，可以是相對時間（比如：30s），也可以是絕對時間（比如：當天23時,轉換成距1970-1-1 00:00:00的秒數）。 小于0，不更改之前的過期時間
如果不傳或者傳入0，則表示資料永不過期；
大于0小于目前時間戳是相對時間過期；
大于目前時間戳是絕對時間過期；
1.3.5 version
Tair中存儲的每個資料都有版本号，版本号在每次更新後都會遞增，相應的，在Tair put接口中也有此version參數，這個參數是為了解決并發更新同一個資料而設定的，類似于樂觀鎖。
很多情況下，更新資料是先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，然後在其基礎上修改，也可以選擇強行更新。
1.3.5.1 如何擷取到目前key的version
get接口傳回的是DataEntry對象，該對象中包含get到的資料的版本号，可以通過getVersion()接口獲得該版本号。在put時，将該版本号作為put的參數即可。 如果不考慮版本問題，則可設定version參數為0，系統将強行覆寫資料，即使版本不一緻。
1.3.5.2 version是如何改變的
Version改變的邏輯如下：
1) 如果put新資料且沒有設定版本号，會自動将版本設定成1。
2) 如果put是更新老資料且沒有版本号，或者put傳來的參數版本與目前版本一緻，版本号自增1。
3) 如果put是更新老資料且傳來的參數版本與目前版本不一緻，更新失敗，傳回VersionError。
4) put時傳入的version參數為0，則強制更新成功，版本号自增1。
1.3.5.3 version傳回不一緻的時候，該如何處理
如果更新所基于的version和系統中目前的版本不一緻，則伺服器會傳回ResultCode.VERERROR。 這時你可以重新get資料，然後在新版本的資料上修改；或者設定version為0重新請求，以達到強制更新的效果，應用可以根據自身對資料一緻性的要求在這兩種政策間進行選擇。
1.3.5.4 version具體使用案例
如果應用有10個client會對key進行并發put，那麼操作過程如下：
1) get key。如果get key成功，則進入步驟2；如果資料不存在，則進入步驟3.
2) 在調用put的時候将get key傳回的verison重新傳入put接口。服務端根據version是否比對來傳回client是否put成功。
3) get key資料不存在，則新put資料。此時傳入的version必須不是0和1，其他的值都可以（例如1000，要保證所有client是一套邏輯）。因為傳入0，tair會認為強制覆寫；而傳入1，第一個client寫入會成功，但是新寫入時服務端的version以0開始計數啊，是以此時version也是1，是以下一個到來的client寫入也會成功，這樣造成了沖突
1.3.5.5 version分布式鎖
Tair中存在該key，則認為該key所代表的鎖已被lock；不存在該key，在未加鎖。操作過程和上面相似。業務方可以在put的時候增加expire，已避免該鎖被長期鎖住。
當然業務方在選擇這種政策的情況下需要考慮并處理Tair當機帶來的鎖丢失的情況。
1.3.5.6 什麼情況下需要使用version
業務對資料一緻性有較高的要求，并且通路并發高，那麼通過version可以避免資料的意外結果。
如果不關心并發，那麼建議不傳入version或者直接傳0。
1.4 叢集部署方式
Tair通過多種叢集部署方式，來滿足各類應用的容災需求。
下面所述的雙機房可以擴充到多機房，現階段基本還是采用的雙機房。
現總共有4種方式：
mdb存儲引擎适用于雙機房單叢集單份，雙機房獨立叢集，雙機房單叢集雙份。
rdb存儲引擎适用于雙機房單叢集單份。
ldb存儲引擎适用于雙機房主備叢集，雙機房單叢集單份。
1.4.1 雙機房單叢集單份
雙機房單叢集單備份數是指，該Tair叢集部署在兩個機房中（也就是該Tair叢集的機器分别在兩個機房）， 資料存儲份數為1， 該類型叢集部署示意圖如下所示。資料伺服器（Dataserver）分布在兩個機房中，他們都屬于同一叢集。
Tair叢集介紹
使用場景：
1) 後端有無資料源都可。
2) 後端有資料源，且更新比例很高的場景。
優點：
1) 伺服器存在于雙機房，任一機房當機保持可用。
2) 單份資料，無論應用在哪個機房，看到的都是同一個資料。
缺點：
1) 應用伺服器會跨機房通路。如上圖，并假設應用伺服器在cm3和cm4，那麼cm3的應用伺服器也可能調用到cm4的tair機器，cm4的亦然。
2) 當一邊機房出現故障時，tair中的資料會失效一半（一半這個數值是按兩邊機房tair機器數相同估計的，如果不相同，則按對應比例估算）
該部署方式，應用在删除資料時，隻需要調用delete即可，無需調用invalid。當然，調用invalid也可，這種方式下會直接退化到delete。
1.4.2 雙機房獨立叢集
雙機房獨立叢集是指，在兩個機房中同時部署2個獨立的Tair叢集，這兩個叢集沒有直接關系。下圖是一個典型的雙機房獨立集部署示意圖，可以看到，cm3和cm4各有一個完整的tair叢集（2個configserver+多個dataserver）。圖中還多了一個invalidserver的角色， invalidserver接收用戶端的invalid或者hide請求後，會對各機房内的叢集進行delete或者hide操作，以此保障Tair中的資料和後端資料源保持一緻的。
Tair叢集介紹
适用場景：
1) 後端必須要有資料源，否則則退化成單機房叢集，Tair叢集本身不做同步。
2) 讀寫比不能過小，不然可能會帶來Tair命中率降低。例如某個key，在資料庫中被頻繁更新，那麼此時應用必須調用invalid來確定Tair和DB的一緻性。此時應用讀Tair一直會不命中，導緻整體命中率低，可能造成DB壓力比較大。 如果依然有疑問的話，請聯系 tair答疑。
優點：
1) 每個機房擁有獨立Tair叢集，應用在哪個機房就通路相同機房的Tair叢集，不會出現跨機房調用和流量。
2) 單邊機房故障，不會影響業務通路tair命中率。
缺點：
1) 後端必須要有資料源，也就是這種部署方式下，Tair必然是當作傳統意義上的cache存在的。因為Tair mdb叢集之間本身不會做資料同步，多叢集間一緻性保證依賴于後端資料源，如DB。
2) 當後端資料源資料發生更新後，業務不能直接把資料put到Tair，而是先需要調用invalid接口來失效這些對等叢集中的資料（來保持各Tair叢集的資料和後端資料源的一緻性）。之後業務可以把資料put到目前Tair叢集（注意：隻會put到本機房的Tair叢集，不會put到對端叢集）或者在讀Tair時發生not exist的時候從後端資料源取來放入Tair。
1.4.3 雙機房單叢集雙份
雙機房單叢集雙份，是指一個Tair叢集部署在2個機房中，資料儲存2份，并且同一資料的2個備份不會放在同一個資料伺服器上。根據資料分布政策的不同，還可以将同一份資料的不同備份分布到不同的機房上。該類型的叢集部署方式與雙機房單叢集單份資料的部署方式一樣。其不同之處，資料儲存份數不一樣。該類型叢集部署方式示意圖如下圖所示，資料伺服器分别部署在兩個不同的機房裡，所有的資料伺服器都被相同的配置伺服器管理，在邏輯上，他們構成一個獨立的叢集。
Tair叢集介紹
現隻有tbsession叢集使用了這種部署方式。
适用場景：
後端無資料源，臨時資料的存放，非cache。
cache類應用推薦使用雙機房獨立叢集和雙機房單叢集單份部署方式。
優點：
1) 資料存放兩份，資料安全性有一定保障。但由于存儲引擎是mdb，資料存放在記憶體中，無法絕對保證資料不丢失。
2) 當一邊機房故障時，另外一邊機房依然可以服務，并且資料不丢失。
缺點：
1) 如果機房間網絡出現異常情況，依然有較小幾率丢失資料。
1.4.4 雙機房主備叢集
這種部署方式中，存在一個主叢集和一個備份叢集，分别在兩個機房中。如下圖所示，不妨假設CM3中部署的是主叢集，CM4中部署的是備份叢集。那麼，在正常情況下，使用者隻使用主叢集，讀寫資料都與主叢集互動。主備叢集會自動同步資料（不需要業務去更新兩邊），保證兩個機房資料的最終一緻性。當一個機房發生故障後，備叢集會自動切換成主叢集，提供服務，保證系統可用性。
Tair叢集介紹
适用場景：
該方式隻在ldb存儲引擎中存在，也就是業務将Tair當作最終存儲使用。我們會在目前主叢集存兩份資料，并由Tair異步将資料更新到備叢集，確定資料安全和服務可用。
優點：
1) 資料安全和服務可用性高。
2) 使用者調用友善，無需考慮多叢集間資料一緻性的問題。
轉載于:https://my.oschina.net/whiteInfo/blog/820007