淘宝tair的学习心得相关记录

晚上回家，想起前一阵子看淘宝Tair相关资料，其实去年tair开源时就有相关关注，但是印象不多，最近重新翻阅了相关资料，感觉很详细，受益非浅，表示感谢，小记了一下，供学习与参考：（http://www.oschina.net/p/tair）

一.Tair的介绍

Tair是由淘宝网自主开发的Key/Value结构数据存储系统.它默认支持基于内存和文件的两种存储方式，分别和我们通常所说的缓存和持久化存储对应。Tair除了普通Key/Value系统提供的功能，比如get、put、delete以及批量接口外，还有一些附加的实用功能，使得其有更广的适用场景，包括：

1.Version支持：Tair中的每个数据都包含版本号，版本号在每次更新后都会递增。这个特性有助于防止由于数据的并发更新导致的问题。

注：对于版本号的支持，每个数据都包含版本号是不是有必要，毕竟大部分数据更新是不需要的，增加了存储！其实tair这样是变相的想实现事物操作，保证数据更新成功。在redis里面采用的是乐观锁的实现，通过watch key，当多线程操作时，如果在watch key以后其它线程优先操作，会执行失败。对于版本号引入，tair应该有它使用场景的考虑，我们的项目中相关数据有自定义Version来保证数据的一致性。

2.原子计数器：Tair从服务器端支持原子的计数器操作，这使得Tair成为一个简单易用的分布式计数器。

3.Item支持：Tair还支持将value视为一个item数组，对value中的部分item进行操作。比如有个key的value为[1,2,3,4,5]，我们可以只获取前两个item，返回[1,2]，也可以删除第一个item，还支持将数据删除，并返回被删除的数据，通过这个接口可以实现一个原子的分布式FIFO的队列。

注:对于原子计数器，以及item的支持，都实现了原子操作，这些在实际使用场景中很有作用吧。淘宝在实现这些功能时应该是考虑到项目中的应用场景了。对于其实现方式（在做分布式处理时，这些数据映射到同一结点，相关key增加通过版本号应该就可以很好的实现了）

二．Tair内部结构

如上图所示，为Tair的基本框架。

从上图看简单的理解ConfigServer是中心结点，其中此server支持主从备份。DataServer为数据存储结点，并与ConfigServer通过心跳机制保持连接。Client为淘宝相关项目中需要使用Tair的应用，通过ConfigServer可以获取数据（Key-hash）值对应的DataServer结点信息，然后与相应的DataServer完成交互。

以上为个人理解：

1.      Tair架构介绍：

一个Tair集群主要包括client、configserver和dataserver 3个模块。Configserver通过和dataserver的心跳（HeartBeat）维护集群中可用的节点，并根据可用的节点，构建数据的在集群中的分布信息（见下文的对照表）。Client在初始化时，从configserver处获取数据的分布信息，根据分布信息和相应的dataserver交互完成用户的请求。Dataserver负责数据的存储，并按照configserver的指示完成数据的复制和迁移工作。

2.      数据分布

分布式系统需要解决的一个重要问题便是决定数据在集群中的分布策略，好的分布策略应该能将数据均衡地分布到所有节点上，并且还应该能适应集群节点的变化。Tair采用的对照表方式较好地满足了这两点。对照表的行数是一个固定值，这个固定值应该远大于一个集群的物理机器数，由于对照表是需要和每个使用Tair的客户端同步的，所以不能太大，不然同步将带来较大的开销。生产环境中的行数一般为1023 。

对照表简介下面看对照表是怎么完成数据的分布功能的，为了方便，这里假设对照表的行数为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通信。

注:tair的分布式策略是通过对照表的方式，hash对应server的结点信息，然后key，hash后取模，以上方式可以很好的增加与删除结点，以及后面所涉及的备份等，考虑的比较全面。我们项目中在实现redis分布式缓存处理时，服务器结点信息做一致性哈希，然后数据key做hash选取对应的结点信息实现，此方式实现，数据能够均均分布，在增加与删除结点时，需要重新init hash的TreeMap，总体来说还是比较平滑。

三．ConfigServer介绍

Tair的configserver是一个轻量级的中心节点，在大部分时候，configserver不可用对集群的服务是不造成影响的。Tair用户和configserver的交互主要是为了获取数据分布的对照表，当client获取到对照表后，会cache这张表，然后通过查这张表决定数据存储的节点，所以请求不需要和configserver交互，这使得Tair对外的服务不依赖configserver，所以它不是传统意义上的中心节点。configserver维护的对照表有一个版本号，每次新生成表，该版本号都会增加。当有数据节点状态发生变化（比如新增节点或者有节点不可用了）时，configserver会根据当前可用的节点重新生成对照表，并通过数据节点的心跳，将新表同步给数据节点。当客户端请求数据节点时，数据节点每次都会将自己的对照表的版本号放入response中返回给客户端，客户端接收到response后，会将数据节点返回的版本号和自己的版本号比较，如果不相同，则主动和configserver通信，请求新的对照表。所以客户端也不需要和configserver保持心跳，以便及时地更新对照表。这使得在正常的情况下，客户端不需要和configserver通信，即使configserver不可用了，也不会对整个集群的服务造成大的影响。有当configserver不可用，此时有客户端需要初始化，那么客户端将取不到对照表信息，这将使得客户端无法正常工作。

注:以上为configserver的工作的介绍，其实简单来说configserver维护分布式对照表，此表有一个version，当有dataserver删除与增加时，configserver会重新生成对照表，并同步给所有的dataserver,而客户端第一次访问时会从configserver中坊取对应的对象表信息并缓存，然后数据key与对应的dataserver通信，每次跟dataserver交互时，会比较对照表的版本号，如果有更新，则会重新请求configserver读取对应的对照表。

总体上来说此ConfigServer很轻量级。

 

四.DataServer的实现

Tair抽象了存储引擎，底层可以基于LevelDb,redis等各种存储引擎，表示很赞。

 总的来说，以上是读Tair相关文档时的一些笔记及相关心得，主要对于其框架的实现，有些小体会，结合自身实现过程中的一些想法简单的记录下，对自己知识的扩展有很大的帮助。