Tair总结整理(基础篇)

Tair是一款高效的nosql存储产品,在整个公司内部有广泛的应用。Tair产品丰富,既有内存型的缓存产品,也有持久化产品、在数据类型上,既支持单个key-value方式,也支持key对应多个value的方式。

适用的基础场景:

  • 单个数据大小较小,一般在kb级别以下,建议最大不要超过10k,虽接口限制value最大值为1M,但是大value会极大降低集群性能,不推荐。Value较大且必须使用Tair的,可以考虑对value进行拆分或者压缩。
  • 访问qps(query per second)较高,达到千级别以上,rt(response time)要求较高,在ms级别。

QPS :Query-per-second    1秒钟内完成的请求数量

RT:Response-time     1个请求完成的时间

不适用的基础场景:

  • 需要类似于关系型数据库的like查询
  • 需要根据value进行反查询
  • 单条value很大,达到百k甚至M
  • qps很低,百级别以下

Tair服务端

Tair的服务端包括config server和data server两钟角色的服务器,作用分别为:

  • Config server:配置服务器,负责维护一个集群的配置信息,包括可用的data server列表。
  • Data server:数据服务器,负责物理存储数据的地方。

一个config server维护一个集群,一个集群可以包含任意多台data server。Config server使用Group的概念将物理服务器划分成多个互相独立的group,提供给客户端使用。一个集群可以划分成任意多个组,一个组可以为一个或多个应用提供服务。由于一个组可以同时存储多个应用的数据,为了避免多个应用的数据的key冲突,我们提供了namespace的概念,一个组最多可以包含65535个不同的namespace,当单个应用出现key冲突的情况,也可以使用namespace来解决。

客户端在获取服务时,需要做如下的准备工作:

  • 根据应用配置的group和config server地址,从config server获取该group的data server列表和配置信息。
  • 根据从config server获取的配置进行初始化。
  • 在客户端初始化成功后,就可以提供数据的存储访问服务了。在接口调用时,客户端会自动选择相应的data server,将请求发送给相应的服务器,并将结果返回给调用者。

1

但是,由于在生产环境中,集群配置可能发生变更,甚至Tair集群也会没能及时获取最新的配置信息而发生错误。另外,直连集群也给容灾带来了难度。基于以上考虑,tair客户端基于公司内部广泛使用的diamond系统,推出了具有容灾功能的客户端。如下图所示:

2

Tair架构图:

3

数据分布与对照表

Tair使用一致性hash算法,对于所有的key,分布到Q个桶中,桶作为数据负载和迁移的基本单位,config server根据一定的策略,把每个桶分布到不同的data server上,因为数据是根据key进行的hash算法,所以每个桶中的数据都是平衡的。保证了桶分布的均衡性就保证了数据分布的均衡性。

Tair对照表

对照表简介

下面我们看对照表是怎么完成数据的分布功能的,为了方便,我们这里假设对照表的行数为6。最简单的对照表包含两列,第一列为hash值,第二列为负责该hash值对应数据的dataserver节点信息。比如我们有两个节点192.168.10.1和192.168.10.2,那么对照表类似:

0 192.168.10.1
1 192.168.10.2
2 192.168.10.1
3 192.168.10.2
4 192.168.10.1
5 192.168.10.2

当客户端接收到请求后,将key的hash值和6取模,然后根据取模后的结果查找对照表。比如取模后的值为3,客户端将和192.168.10.2通信。

节点数量变化时,对照表如何适应。

我们假设新增了一个节点——192.168.10.3,当configserver发现新增的节点后,会重新构建对照表。构建依据以下两个原则:

  • 数据在新表中均衡的分布到所有的节点上。
  • 尽可能的保持现有的对照关系。

更新之后的对照表如下所示:

0 192.168.10.1
1 192.168.10.2
2 192.168.10.1
3 192.168.10.2
4 192.168.10.3
5 192.168.10.3

这里将原本由192.168.10.1负责的4和192.168.10.2负责的5交由新加入的节点192.168.10.3负责。如果是节点不可用,删除节点时,则相当于上述过程反过来,道理是一样的。如此,Tair采用对照表的方式解决将数据均衡的分布到所有的节点上,而且还能使用集群节点变化这两个问题,对照表的行数是一个固定的值,这个值远远大于集群的物理机器数,由于对照表是需要和客户端同步的,所以这个值不易过大,不然同步会带来较大的开销,生产环境中行数一般为1023。

增加减少Data server

当一个data server宕机的时候,config server会感受到,config server将重新计算一张新的桶在data server上的分布表(对照表),将原来故障机器服务的桶的访问重新指派到其他的data server上,这个时候可能发生数据的迁移,比如原来由ds A负责的现在让ds B负责,但是ds B上并没有ds A的桶的信息,这个时候就会根据备份将ds A上的桶的数据迁移到ds B上来,同时config server会发现哪些桶的备份少了,然后根据负载情况,在负载较低的data server上增加这些桶的备份。增加ds的时候,cs会根据负载,协调ds将他们控制的部分桶迁移到新的ds上,迁移完成后调整路由,每次路由更新时cs都会将新配置的信息推给ds。客户端访问ds的时候,数据节点会把自己的对照表的版本号放入response 中返回给客户端,客户端接到response后,会将数据节点返回的版本和自己缓存的版本号比较 ,不过不相同,客户端会主动去去config server上取一次新的路由表,如果client 访问ds发生了不可达的情况,client会主动去cs 上取新的路由表。

多备份的支持

Tair支持自定义的备份数,比如你可以设置数据备份为2,以提高数据的可靠性。对照表可以很方便地支持这个特性。我们以行数为6,两个节点为例,2个备份的对照表类似:

0 192.168.10.1 192.168.10.2
1 192.168.10.2 192.168.10.1
2 192.168.10.1 192.168.10.2
3 192.168.10.2 192.168.10.1
4 192.168.10.1 192.168.10.2
5 192.168.10.2 192.168.10.1

第二列为主节点的信息,第三列为辅节点信息。在Tair中,客户端的读写请求都是和主节点交互,所以如果一个节点不做主节点,那么它就退化成单纯的备份节点。因此,多备份的对照表在构建时需要尽可能保证各个节点作为主节点的个数相近。当有节点不可用时,如果是辅节点,那么config server会重新为其指定一个辅节点,如果是持久化存储,还将复制数据到新的辅节点上。如果是主节点,那么config server首先将辅节点提升为主节点,对外提供服务,并指定一个新的辅节点,确保数据的备份数。

多机架多数据中心的支持

对照表在构建时,可以配置将数据的备份分散到不同机架或数据中心的节点上。Tair当前通过设置一个IP掩码来判断机器所属的机架和数据中心信息。比如你配置备份数为3,集群的节点分布在两个不同的数据中心A和B,则Tair会确保每个机房至少有一份数据。假设A数据中心包含两份数据时,Tair会尽可能将这两份数据分布在不同机架的节点上。这可以减少整个数据中心或某个机架发生故障是数据丢失的风险。

存储引擎

Tair目前支持的存储引擎有非持久化的MDB(自主研发的类memcached,支持kv和分级kv—分级kv类似于模拟一个数据结构,在实际应用中会有这样的需求)、RDB(抽离Redis的存储部分,可以支持Redis原来的复杂数据结构)、持久化的LDB(接入Level DB,进行数据排序)

参考资料:

http://code.taobao.org/p/tair/wiki/index/

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">