设为首页收藏本站

UNIX技术社区

 找回密码
 注册

QQ登录

只需一步,快速开始

搜索
热搜: console
查看: 1677|回复: 0

对淘宝tair分布式K、V的一些理解

[复制链接]
发表于 2013-1-1 12:10:00 | 显示全部楼层 |阅读模式
Tair是什么Tair是由淘宝开发的key/value方案,系统默认支持基于内存和文件的存储引擎,对应于通常我们所说的缓存和持久化存储,这里可以获取更多关于tair的信息,淘宝团队介绍,Tair在淘宝有着大规模的应用,在登录淘宝、查看商品详情页面、在淘江湖和好友“捣浆糊”等等时候,后面都在直接或间接的和Tair交互。

对照表Tair使用路由表来解决数据的路由问题。
简单的路由表包含两列,一列是hash值(我们通常称其为桶——bucket),一列是负责这个hash值的节点。比如:
0192.168.0.1
1192.168.0.2
2192.168.1.1
3192.168.1.2
4192.168.2.1
5192.168.2.2
这里共6个桶,由6台机器负责,每台机器负责1个桶。客户端将key hash后,对6取模,找到负责的数据节点,然后和其直接通信,比如加入了一台新的机器,Tair会自动调整对照表,将部分桶交由新的节点负责,在阿里开源的memcached的客户端中,也采用的是同样的方式
轻量级的configserverTair的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数据节点的进程时不会导致数据的丢失,从而使升级对应用来说很平滑,不会导致命中率的波动,这点的设计和ehcache、threcottoa相似
fdb是一个简单高效的持久化存储引擎,使用树的方式根据数据key的hash值索引数据,加快查找速度。索引文件和数据文件分离,尽量保持索引文件在内存中,以便减小IO开销。使用空闲空间池管理被删除的空间,这点设计有点oracle设计的味道
自动的复制和迁移为了增强数据的安全性,Tair支持配置数据的备份数。比如你可以配置备份数为3,则每个数据都会写在不同的3台机器上。得益于抽象的存储引擎层,无论是作为cache的mdb,还是持久化的fdb,都支持可配的备份数。
当数据写入一个节点(通常我们称其为主节点)后,主节点会根据对照表自动将数据写入到其他备份节点,整个过程对用户是透明的。
当有新节点加入或者有节点不可用时,configserver会根据当前可用的节点,重新build一张对照表。数据节点同步到新的对照表时,会自动将在新表中不由自己负责的数据迁移到新的目标节点。迁移完成后,客户端可以从configserver同步到新的对照表,完成扩容或者容灾过程。整个过程对用户是透明的,服务不中断。
多机架和多数据中心的支持为了更进一步的提高数据的安全性,Tair的configserver在build对照表的时候,可以配置考虑机房和机架信息。
比如你配置备份数为3,集群的节点分布在两个不同的机房A和B,则Tair会确保每个机房至少有一份数据。当A机房包含两份数据时,Tair会确保这两份数据会分布在不同机架的节点上。这可以防止整个机房发生事故和某个机架发生故障的情况。
这里提到的特性需要节点物理分布的支持,当前是通过可配置的IP掩码来区别不同机房和机架的节点,上述复制以及机架的设计思想和apache hadoop的设计方式相同
插件容器Tair还内置了一个插件容器,可以支持热插拔插件。
插件由configserver配置,configserver会将插件配置同步给各个数据节点,数据节点会负责加载/卸载相应的插件。
插件分为request和response两类,可以分别在request和response时执行相应的操作,比如在put前检查用户的quota信息等。
插件容器也让Tair在功能方便具有更好的灵活性。
versionTair中的每个数据都包含版本号,版本号在每次更新后都会递增。这个特性可以帮助防止数据的并发更新导致的问题。
比如系统有一个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,然后在其基础上修改,也可以选择强行更新,个人觉得Tail的version的还不够完善,毕竟这样的设计方式在性能上还有些问题,同时在错误处理上也存在bug,为什么不采用类似于oracle集群中ASM的控制文件中SCN与本地oracle节点的相关SCN做比对("起","止"两处进行更新,进行对比),这样在本地节点获取数据前就对服务器端SCN版本进行"起"更新,"止"更新SCN在数据提交后进行,这样可以解决节点突然宕机的问题
原子计数器支持Tair从服务器端支持原子的计数器操作,这使得Tair成为一个简单易用的分布式计数器。
item支持Tair还支持将value视为一个item数组,对value中的部分item进行操作。比如有个key的value为[1,2,3,4,5],我们可以只获取前两个item,返回[1,2],也可以删除第一个item。还支持将数据删除,并返回被删除的数据,通过这个接口可以实现一个原子的分布式FIFO的队列。

结束语
毋庸置疑,现在整个阿里集团的人才确实很多,同时也就因为这样造成了一些问题,不管是阿里、淘宝开源的哪种K/V分布式,设计的思路大致采用的方式80%基本相似,为什么就不能自立于一套上面进行深入、带些创新的研究,非要反复的画出轮子,获取因为分公司之间的竞争,或许因为团队之间内部的管理方式,或者因为都太过信任自己的小团队,但不管怎样,能够见到阿里、淘宝等公司在开源社区作出的贡献,我们也算有幸了!
您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 返回顶部 返回列表