tair与redis分析.docx

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的分布式不支持多副本。