Tair: 淘宝的key/value解决方案

今天我们对外开源了Tair，Tair是由淘宝开发的key/value解决方案，你可以在这里获取更多信息。

Tair在淘宝有着大规模的应用，在你登录淘宝、查看商品详情页面、在淘江湖和好友“捣浆糊”等等时候，后面都在直接或间接的和Tair交互。

Tair是什么

Tair是一个分布式的key/value结构数据的解决方案，系统默认支持基于内存和文件的存储引擎，对应于通常我们所说的缓存和持久化存储。

Tair具有良好的架构，使得其在可扩展性、数据安全性方面都有较好的表现:

• 基于对照表的灵活、良好的可扩展性
• 轻量级的configserver
• 抽象的存储引擎层，支持添加新的存储引擎
• 自动的复制和迁移，对用户透明
• 多机架和多数据中心的支持
• 插件容器

Tair除了基本的key/value操作外，还提供了一些实用的功能，使得其适用的场景更多：

• 数据的version支持
• 原子计数器支持
• item支持

对照表

Tair使用路由表来解决数据的路由问题。

简单的路由表包含两列，一列是hash值（我们通常称其为桶——bucket），一列是负责这个hash值的节点。比如：

这里共6个桶，由两台机器负责，每台机器负责3个桶。客户端将key hash后，对6取模，找到负责的数据节点，然后和其直接通信。表的大小（行数）通常会远大于集群的节点数，这和consistent hash中的虚拟节点很相似。

这种结构使得Tair具有良好的可扩性，我们定义的好的可扩性是指我们投入多少机器，它们就能发挥其相应的作用。比如我们发现两台机器负载太高，我们可以选择加入1台，而不是通常的做法，将现有的节点数翻番。这种特性在这里的优势可能不是很明显，假设集群有1000台，如果你扩容一定需要再加1000台机器，那这种可扩性对我们来说是不够好的。

假设我们加入了一台新的机器——192.168.10.3，Tair会自动调整对照表，将部分桶交由新的节点负责，比如新的表很可能类似下表：

在老的表中，每个节点负责3个桶，当扩容后，每个节点将负责2个桶，数据被均衡的分布到所有节点上。

如果有多个备份，那么对照表将包含多列，比如备份是为3，则表有4列，后面的3列都是数据存储的节点。

轻量级的configserver

Tair的configserver用于维护集群的可用节点，根据可用的节点，build数据分布的对照表，Tair根据这张对照表决定数据的具体分布。除此之外，configserver还负责管理迁移的进度等。

但和传统集群的中心节点不同，Tair的configserver是个轻量级的服务，并不会成为集群的瓶颈。

Tair用户和configserver的交互主要是为了获取数据分布的对照表，当client获取到对照表后，会cache这张表，然后通过查这张表决定数据存储的节点，所以请求不需要和configserver交互，这使得Tair对外的服务不依赖configserver，所以它不是传统意义上的中心节点。

configserver维护的对照表有一个版本号，每次新生成表，该版本号都会增加。当有数据节点状态发生变化（比如新增节点或者有节点不可用了）时，configserver会根据当前可用的节点重新生成对照表，并通过数据节点的心跳，将新表同步给数据节点。

当客户端请求数据节点时，数据节点每次都会将自己的对照表的版本号放入response中返回给客户端，客户端接收到response后，会将数据节点返回的版本号和自己的版本号比较，如果不相同，则主动和configserver通信，请求新的对照表。

所以客户端也不需要和configserver保持心跳，以便及时的更新对照表。这使得在正常的情况下，客户端不需要和configserver通信，即使configserver不可用了，也不会对整个集群的服务造成大的影响。

有了configserver，客户端不需要配置数据节点列表，也不需要处理节点的的状态变化，这使得Tair对最终用户来说使用和配置都很简单。

抽象的存储引擎

Tair的存储引擎有一个抽象层，只要满足存储引擎需要的接口，便可以很方便的替换Tair底层的存储引擎。比如你可以很方便的将bdb、tc甚至MySQL作为Tair的存储引擎，而同时使用Tair的分布方式、同步等特性。

Tair默认包含两个存储引擎：mdb和fdb。

mdb是一个高效的缓存存储引擎，它有着和memcached类似的内存管理方式。但mdb支持使用share memory，这使得我们在重启Tair数据节点的进程时不会导致数据的丢失，从而使升级对应用来说很平滑，不会导致命中率的波动。

fdb是一个简单高效的持久化存储引擎，使用树的方式根据数据key的hash值索引数据，加快查找速度。索引文件和数据文件分离，尽量保持索引文件在内存中，以便减小IO开销。使用空闲空间池管理被删除的空间。

自动的复制和迁移

为了增强数据的安全性，Tair支持配置数据的备份数。比如你可以配置备份数为3，则每个数据都会写在不同的3台机器上。得益于抽象的存储引擎层，无论是作为cache的mdb，还是持久化的fdb，都支持可配的备份数。

当数据写入一个节点（通常我们称其为主节点）后，主节点会根据对照表自动将数据写入到其他备份节点，整个过程对用户是透明的。

当有新节点加入或者有节点不可用时，configserver会根据当前可用的节点，重新build一张对照表。数据节点同步到新的对照表时，会自动将在新表中不由自己负责的数据迁移到新的目标节点。迁移完成后，客户端可以从configserver同步到新的对照表，完成扩容或者容灾过程。整个过程对用户是透明的，服务不中断。

多机架和多数据中心的支持

为了更进一步的提高数据的安全性，Tair的configserver在build对照表的时候，可以配置考虑机房和机架信息。

比如你配置备份数为3，集群的节点分布在两个不同的机房A和B，则Tair会确保每个机房至少有一份数据。当A机房包含两份数据时，Tair会确保这两份数据会分布在不同机架的节点上。这可以防止整个机房发生事故和某个机架发生故障的情况。

这里提到的特性需要节点物理分布的支持，当前是通过可配置的IP掩码来区别不同机房和机架的节点。

插件容器

Tair还内置了一个插件容器，可以支持热插拔插件。

插件由configserver配置，configserver会将插件配置同步给各个数据节点，数据节点会负责加载/卸载相应的插件。

插件分为request和response两类，可以分别在request和response时执行相应的操作，比如在put前检查用户的quota信息等。

插件容器也让Tair在功能方便具有更好的灵活性。

功能支持

version

Tair中的每个数据都包含版本号，版本号在每次更新后都会递增。这个特性可以帮助防止数据的并发更新导致的问题。

比如系统有一个value为”a,b,c”，A和B同时get到这个value。A执行操作，在后面添加一个d，value为”a,b,c,d”。B执行操作添加一个e，value为”a,b,c,e”。如果不加控制，无论A和B谁先更新成功，它的更新都会被后到的更新覆盖。

Tair无法解决这个问题，但是引入了version机制避免这样的问题。还是拿刚才的例子，A和B取到数据，假设版本号为10，A先更新，更新成功后，value为”a,b,c,d”，与此同时，版本号会变为11。当B更新时，由于其基于的版本号是10，服务器会拒绝更新，从而避免A的更新被覆盖。B可以选择get新版本的value，然后在其基础上修改，也可以选择强行更新。

原子计数器支持

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

item支持

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

Tair的未来

我们将Tair开源，希望能有更多的用户来使用、完善它，我们内部将不再有私有分支，所有的工作都将基于开源的分支进行，希望借助社区的力量，使Tair有更宽广的发展空间和更美好的未来。