一个Tair集群主要包括3个必选模块:configserver、dataserver和client,一个可选模块:invalidserver。一般状况下,一个集群中包含2台configserver及多台dataServer。两台configserver互为主备并经过维护和dataserver之间的心跳获知集群中存活可用的dataserver,构建数据在集群中的分布信息(对照表)。dataserver负责数据的存储,并按照configserver的指示完成数据的复制和迁移工做。client在启动的时候,从configserver获取数据分布信息,根据数据分布信息和相应的dataserver交互完成用户的请求。invalidserver主要负责对等集群的删除和隐藏操做,保证对等集群的数据一致。redis
从架构上看,configserver的角色相似于传统应用系统的中心节点,整个集群服务依赖于configserver的正常工做。但实际上相对来讲,tair的configserver是很是轻量级的,当正在工做的服务器宕机的时候另一台会在秒级别时间内自动接管。并且,若是出现两台服务器同时宕机的最恶劣状况,只要应用服务器没有新的变化, tair依然服务正常。而有了configserver这个中心节点,带来的好处就是应用在使用的时候只须要配置configserver的地址(如今能够直接配置Diamond key),而不须要知道内部节点的状况。数据库
1) 经过维护和dataserver心跳来获知集群中存活节点的信息后端
2) 根据存活节点的信息来构建数据在集群中的分布表。缓存
3) 提供数据分布表的查询服务。服务器
4) 调度dataserver之间的数据迁移、复制。数据结构
1) 提供存储引擎架构
2) 接受client的put/get/remove等操做异步
3) 执行数据迁移,复制等分布式
4) 插件:在接受请求的时候处理一些自定义功能ide
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. 数据能够以key/value的形式存储
2. 数据能够接受丢失
3. 访问速度要求很高
4. 单个数据大小不是很大,通常在KB级别
5. 数据量很大,而且有较大的增加可能性
6. 数据更新不频繁
1. 数据能够以key/value的形式存储
2. 数据须要持久化
3. 数据量很大,而且有较大的增加可能性
4. 单个数据大小不是很大,通常在KB级别
5. 数据的读写比例较高
1.对数据有查询需求,好比对key的模糊查询,或者根据value反查询key等
2.单条数据很大
3.读写比例很低
产品比较项 |
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等数据结构 |
跨机房管理 |
支持 |
不支持 |
多集群管理 |
支持 |
不支持 |
是否支持副本 |
支持 |
不支持 |
使用状况 |
国内淘宝网 在最大规模的使用 |
国内新浪微博,之前曾出现过故障 |
|
|
|
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代码,即没有开源);
首先增长一个代理端,做用是检测处理应用请求,若是是读代理会尝试在tair及redis两个系统查找数据,返回给应用;若是是写数据代理直接将数据写入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中部署的是备份集群。那么,在正常状况下,用户只使用主集群,读写数据都与主集群交互。主备集群会自动同步数据(不须要业务去更新两边),保证两个机房数据的最终一致性。当一个机房发生故障后,备集群会自动切换成主集群,提供服务,保证系统可用性。
a.在分布式集群支持方面tair支持副本,支持多种集群结构,如:一机房一个集群、双 机房单集群单份、双机房独立集群、双机房单集群双份、双机房主备集群;
b.对于读写性能根据结点添加对线性上升,缘由是各个结点之间是没有关系,节点增多相应性能提高。
c.高可用比较强,任何小于副本数结点挂掉,不会影响正常业务。
e.淘宝在多个实际应用场景应用,知足不一样业务需求。
F.支持跨机房数据分布。
a.在单节点的性能比较方面,redis是性能比tair高大概1/5
b.redis目前研究人员比较少,社区不是很活跃。
a.在单节点的性能比较方面,redis是性能比tair高大概1/5
b.redis目前研究人员比较多,社区比较活跃。
c.在支持多种数据结构方面tair没有redis支持的全面。
a.目前发布版不支持分布式,测试版支持,测试版对分布式支持比较弱,是用主备支持高可能,没有副本。
b.容灾性相比tair弱,缘由是redis的分布式不支持多副本。