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
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。