tair與redis比較總結


1. Tair總述

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),而不需要知道內部節點的情況。

 

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) 流控

2.tair的使用場景

2.1 tair 的使用場景

2.1.1 Tair緩存使用的場景

1. 數據可以以key/value的形式存儲

2. 數據可以接受丟失

3. 訪問速度要求很高

4. 單個數據大小不是很大,一般在KB級別

5. 數據量很大,並且有較大的增長可能性

6. 數據更新不頻繁

2.1.2 Tair持久化適用的場景

1. 數據可以以key/value的形式存儲

2. 數據需要持久化

3. 數據量很大,並且有較大的增長可能性

4. 單個數據大小不是很大,一般在KB級別

5. 數據的讀寫比例較高

2.2 不適Tair用的場景

1.對數據有查詢需求,比如對key的模糊查詢,或者根據value反查詢key等

2.單條數據很大

3.讀寫比例很低

3.tair與redis關系

3.1 功能對比

 產品比較項

 Tair

REDIS

開源情況

完全開源

完全開源

使用語言

服務器端C++;客戶端支持C、JAVA、PHP等

ANSI C語言編寫 ,提供多種語言(C/C++/JAVA/PHP等)的API 

分布式

支持

目前redis的3.0已經支持分布式式,特點是主從的方式支持即主從庫方式添加代理進行管理。3.0版本處於測試版

集群

支持

不支持,3.0測試版支持

動態擴展

支持

不支持,3.0測試版支持

持久化

可配,fdb方式實現持久化

支持,快照及aof方式都支持

效率

mdb 較高,fdb稍次

較高

容錯

支持,數據在寫入主節點后,會異步同步到輔節點;如果主節點不可用,則輔節點會自動接管為主節點;當有節點不可用時,能自動復制數據,保證數據的備份數。

支持,主從節點互為備份

緩存過期移除策略

支持

支持

緩存數據方式

持久化和非持久化兩種,前者和memcached類似的緩存數據方式。

支持,一是 key/value,一是關系數據庫。

吞吐量

每秒高達66000次(mdb),fdb時,吞吐量減半

每秒高達60000次

KEY/VALUE

key :1024個字符;value: 1M個字節。

key :254個字符;value: 高達1G個字節。

單點故障

已解決,通過備份

存在

內存管理

支持

支持

其他數據結構

支持redis的內存存儲結構。支持k/v,list,hash,set等數據結構。

本身支持持k/v,list,hash,set,sortedset等數據結構

跨機房管理

支持

不支持

多集群管理

支持

不支持

是否支持副本

支持

不支持

使用情況

國內淘寶網 在最大規模的使用

國內新浪微博,以前曾出現過故障

 

 

 

 

3.2 關系總結

tair及redis集成關系:Tair是淘寶開源的分布式KV緩存系統,內部將功能模塊化,抽離出底層存儲細節,可以接入不同的存儲引擎。redis是一個開源的、高效的key-value存儲,提供了strings、hashs、lists、sets、sorted sets等多種高級數據結構。redis作為Tair的存儲引擎接入,稱為rdb,rdb從redis繼承了豐富的操作,包括list、hash、sorted set、set(與mdb相比,list不再那么ugly)。

總結:rdb:是tair集成從redis繼承了豐富的操作,包括list、hash、sorted set、set(與mdb相比,list不再那么ugly),Tair將Redis的存儲部分抽離出來,作為非持久化的存儲引擎rdb(目前代碼里面沒有rdb代碼,即沒有開源);

4 tair與redis集群管理

4.1 redis集群介紹

首先增加一個代理端,作用是檢測處理應用請求,如果是讀代理會嘗試在tair及redis兩個系統查找數據,返回給應用;如果是寫數據代理直接將數據寫入tair。

4.1.1 目前readis系統

4.1.2 redis目前測試版本的結構

 

4.2 tair 目前現狀 

4.2.1 tair支持的集群一個機房

 

支持副本,管理結點是主從,數據結點是多個,不同數據結點之間沒有主從關系,有副本。

4.2.2 tair雙機房單集群單份

雙機房單集群單備份數是指,該Tair集群部署在兩個機房中(也就是該Tair集群的機器分別在兩個機房), 數據存儲份數為1, 該類型集群部署示意圖如下所示。數據服務器(Dataserver)分布在兩個機房中,他們都屬於同一集群

 

4.2.3 雙機房獨立集群是指,在兩個機房中同時部署2個獨立的Tair集群,這兩個集群沒有直接關系。下圖是一個典型的雙機房獨立集部署示意圖,可以看到,cm3和cm4各有一個完整的tair集群(2個configserver+多個dataserver)。圖中還多了一個invalidserver的角色, invalidserver接收客戶端的invalid或者hide請求后,會對各機房內的集群進行delete或者hide操作,以此保障Tair中的數據和后端數據源保持一致的。

 

4.2.3  雙機房單集群雙份

雙機房單集群雙份,是指一個Tair集群部署在2個機房中,數據保存2份,並且同一數據的2個備份不會放在同一個數據服務器上。根據數據分布策略的不同,還可以將同一份數據的不同備份分布到不同的機房上。該類型的集群部署方式與雙機房單集群單份數據的部署方式一樣。其不同之處,數據保存份數不一樣。該類型集群部署方式示意圖如下圖所示,數據服務器分別部署在兩個不同的機房里,所有的數據服務器都被相同的配置服務器管理,在邏輯上,他們構成一個獨立的集群。

 

 

4.2.4  雙機房主備集群

這種部署方式中,存在一個主集群和一個備份集群,分別在兩個機房中。如下圖所示,不妨假設CM3中部署的是主集群,CM4中部署的是備份集群。那么,在正常情況下,用戶只使用主集群,讀寫數據都與主集群交互。主備集群會自動同步數據(不需要業務去更新兩邊),保證兩個機房數據的最終一致性。當一個機房發生故障后,備集群會自動切換成主集群,提供服務,保證系統可用性。

 

5 tair與redis比較總結

5.1 tair優勢

a.在分布式集群支持方面tair支持副本,支持多種集群結構,如:一機房一個集群、雙     機房單集群單份、雙機房獨立集群、雙機房單集群雙份、雙機房主備集群;

b.對於讀寫性能根據結點添加對線性上升,原因是各個結點之間是沒有關系,節點增多相應性能提升。

c.高可用比較強,任何小於副本數結點掛掉,不會影響正常業務。

e.淘寶在多個實際應用場景應用,滿足不同業務需求。

F.支持跨機房數據分布。

5.2 tair弱勢 

a.在單節點的性能比較方面,redis是性能比tair高大概1/5

b.redis目前研究人員比較少,社區不是很活躍。

5.3 redis優勢

a.在單節點的性能比較方面,redis是性能比tair高大概1/5

b.redis目前研究人員比較多,社區比較活躍。

c.在支持多種數據結構方面tair沒有redis支持的全面。

5.4 redis弱勢

a.目前發布版不支持分布式,測試版支持,測試版對分布式支持比較弱,是用主備支持高可能,沒有副本。

b.容災性相比tair弱,原因是redis的分布式不支持多副本。

 

 

 

 

 

適應場景

Redis

適用

需要使用復雜數據結構(map, set),map/set中元素很多(1000以上)
延遲敏感服務

不適用

數據量超過600GB(數據太多,全內存太浪費資源)
需要多語言客戶端支持

Tair

適用

不能容忍數據丟失
數據量大,內存放不下的服務

不適用

使用復雜數據結構(map/set),map/set中元素很多(1000以上)

詳細對比

1.訪問模式

具體參數 Redis Redis Cluster Tair
支持Value大小 理論上不超過1GB(建議不超過1MB) 理論上不超過1GB(建議不超過1MB) 256M(更大value還需要測試)
支持Value結構 byte[]/list/map/set byte[]/list/map/set (1)kv/map/list(2)支持big_list(list無長度限制)(3)支持創建schema,cmd query
支持的總數據量   1000+instance scale out,理論上總數據量無限制
適宜的讀寫比 存內存型,均適合 存內存型,均適合 支持多引擎,適宜各種比例的讀寫。讀多寫少(mdb+leveldb),讀少寫多(leveldb)。
數據是否可改寫 Y Y Y
是否支持Scan/Range Query   不支持,並且不支持merge operations 支持scan;支持range query
CAP   CP 用戶可配置,CP或AP
語言支持 主流語言 主流語言,目前java、ruby可用 php,restful,java,c/c++
數據自動過期 支持 支持 支持

2.訪問性能

具體參數 Redis Redis Cluster Tair
點寫latency 虛機上平均1~2ms 虛機上平均1~2ms 5~8ms(write through),1ms左右(write back)
點寫吞吐率 一個instance 5w,單機器整體性能根據cpu來決定 一個instance 5w,單機器整體性能根據cpu來決定 受限網卡帶寬瓶頸(100MB),單機純內存8w~10w qps(key+value=1k)
批量寫吞吐率 受限網卡帶寬瓶頸 受限網卡帶寬瓶頸 受限網卡帶寬瓶頸(100MB),單機純內存8w ~10w batch/s(batch=10keys,key+value=100,batch_size=1k)
讀latency 虛機上平均1~2ms 虛機上平均1~2ms 同機房內存1ms,磁盤5-8ms(延遲不會隨單機數據容量增加而增加)

3.可運維性

具體參數 Redis Redis Cluster Tair
可擴展性(自動擴容、在線擴容)   支持水平擴展 在不停讀和寫的服務下自動擴容
可用性(是否有單點、數據遷移/單機出錯時是否會有服務中斷、過載保護、慢查詢保護) 使用keepalived或者官方哨兵來保持高可用 無單點 (1)無單點(2)不中斷服務(3)有過載保護(4)無慢查詢保護,但有慢查詢遞歸樹監控
可靠性(如何防止數據丟失,包括機器斷電、硬盤損毀等情形下) 0~N個數據slave備份(實際使用情況基本是0個備份) 0~N個數據slave備份(實際使用情況基本是0個備份) (1)多機數據冗余(2)斷電數據不丟失,重放redo log(3)數據完整性crc校驗(防止磁盤損壞)
數據可靠性 用戶可選是否開啟持久化 用戶可選是否開啟持久化 強,有持久存儲,一般不會丟失數據
多副本 支持(副本平時可讀) 支持(副本平時可讀) 支持(副本平時不提供讀寫)
副本一致性 可根據業務需求配置強一致/弱一致
持久化 支持。持久化的數據是用於重啟后的數據恢復。Redis是一個內存數據庫,無論是RDB還是AOF,都只是其保證數據恢復的措施。 支持。持久化的數據是用於重啟后的數據恢復。Redis是一個內存數據庫,無論是RDB還是AOF,都只是其保證數據恢復的措施。 支持
對業務混合部署的支持(性能隔離) 進程級隔離(特殊處理可以到機器間隔離) 進程級隔離(特殊處理可以到機器間隔離) 硬軟隔離:(1)支持不同group的業務混步(2)支持同一個group業務混步(通過名字空間隔離),支持網絡和內存的隔離。
對訪問權限的可控制性 web操作管理員授權.api操作支持鑒權和非鑒權兩種模式 web操作管理員授權.api操作支持鑒權和非鑒權兩種模式 機器粒度的白名單管理
實現語言、代碼量 JAVA,java客戶端14000行、管理中心22000行 JAVA,java客戶端14000行、管理中心22000行 核心代碼c++,10w行左右

作者:高廣超
鏈接:https://www.jianshu.com/p/cecab7c26fd8
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯系作者獲得授權並注明出處。

 

 
 
 
 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM