Tair分布式缓存

谁借莪１个温暖的怀抱￠ 2022-04-22 11:48 183阅读 0赞

# 淘宝缓存架构 #

redis很好用，提供缓存服务。相比memcached多了新数据结构和主从模式增加可用性。不过redis有一点不能满足一些互联网公司开发者需求。

redis集群中，想用缓存必须得指明redis服务器地址去要。这就增加了程序的维护复杂度。因为redis服务器很可能是需要频繁变动的。

为什么不能像操作分布式数据库或者hadoop那样，增加一个中央节点，让它去代理所有事情。

所以就开发了这个tair。程序只要跟tair中心节点交互就可以。

还开发了**配置服务器**。免去了像操作hadoop那样，每台hadoop一套一模一样配置文件。改配置文件得整个集群都跟着改。

tair使用了google在bigtable里面的merge-dump模型。底层存储可以用redis或者google的levelDB。已经开源了。

# 开源地址 #

http://tair.taobao.org/

# Tair简介 #

分布式 key/value 存储引擎

持久化和非持久化两种使用方式

# Tair总体结构 #

![012350570157314.png][]

![012351037185667.jpg][]

tair 作为一个分布式系统, 是由一个中心控制节点和一系列的服务节点组成. 我们称中心控制节点为config server. 服务节点是data server。

config server 负责管理所有的data server, 维护data server的状态信息。

data server 对外提供各种数据服务, 并以心跳的形式将自身状况汇报给config server。

config server是控制点, 而且是单点, 目前采用一主一备的形式来保证其可靠性。

所有的 data server 地位都是等价的。

# Tair 的负载均衡算法 #

![012350207183070.jpg][]

tair 的分布采用的是一致性哈希算法, 对于所有的key, 分到Q个桶中, 桶是负载均衡和数据迁移的基本单位.

config server 根据一定的策略把每个桶指派到不同的data server上. 因为数据按照key做hash算法, 所以可以认为每个桶中的数据基本是平衡的. 保证了桶分布的均衡性, 就保证了数据分布的均衡性.

## 增加或者减少data server的时候会发生什么 ##

当有某台data server故障不可用的时候, config server会发现这个情况, config server负责**重新计算一张新的桶在data server上的分布表**, 将原来由故障机器服务的桶的访问重新指派到其它的data server中. 这个时候, 可能会发生**数据的迁移**.

比如原来由data server A负责的桶, 在新表中需要由 B负责. 而B上并没有该桶的数据, 那么就将数据迁移到B上来. 同时config server会发现哪些桶的备份数目减少了, 然后根据负载情况在负载较低的data server上增加这些桶的备份. 当系统增加data server的时候, config server根据负载, 协调data server将他们控制的部分桶迁移到新的data server上. 迁移完成后**调整路由**.

当然, 系统中可能出现减少了某些data server 同时增加另外的一些data server. 处理原理同上. 每次路由的变更, config server都会将新的配置信息推给data server. 在客户端访问data server的时候, 会发送**客户端缓存的路由表的版本**号. 如果data server发现客户端的版本号过旧, 则会通知客户端去config server取一次新的路由表. 如果客户端访问某台data server 发生了不可达的情况(该 data server可能宕机了), 客户端会主动去config server取新的路由表.

## 发生迁移的时候data server如何对外提供服务 ##

当迁移发生的时候, 我们举个例子, 假设data server A 要把 桶 3,4,5 迁移给data server B. 因为迁移完成前, 客户端的路由表没有变化, 客户端对 3, 4, 5 的访问请求都会路由到A. 现在假设 3还没迁移, 4 正在迁移中, 5已经迁移完成. 那么如果是对3的访问, 则没什么特别, 跟以前一样. 如果是对5的访问, 则A会把该请求转发给B,并且将B的返回结果返回给客户, 如果是对4的访问, 在A处理, 同时如果是对4的修改操作, 会记录修改log.当桶4迁移完成的时候, 还要把log发送到B, 在B上应用这些log. 最终A B上对于桶4来说, 数据完全一致才是真正的迁移完成. 当然, 如果是因为某data server宕机而引发的迁移, 客户端会收到一张中间临时状态的分配表. 这张表中, 把宕机的data server所负责的桶临时指派给有其备份data server来处理. 这个时候, 服务是可用的, 但是负载可能不均衡. 当迁移完成之后, 才能重新达到一个新的负载均衡的状态.

## 桶在data server上分布时候的策略 ##

程序提供了两种生成分配表的策略, 一种叫做负载均衡优先, 一种叫做位置安全优先: 我们先看负载优先策略. 当采用负载优先策略的时候, config server会尽量的把桶均匀的分布到各个data server上. 所谓尽量是指在不违背下面的原则的条件下尽量负载均衡. 1 每个桶必须有COPY\_COUNT份数据 2 一个桶的各份数据不能在同一台主机上; 位置安全优先原则是说, 在不违背上面两个原则的条件下, 还要满足位置安全条件, 然后再考虑负载均衡. 位置信息的获取是通过 \_pos\_mask(参见安装部署文档中关于配置项的解释) 计算得到. 一般我们通过控制 \_pos\_mask 来使得不同的机房具有不同的位置信息. 那么在位置安全优先的时候, 必须被满足的条件要增加一条, 一个桶的各份数据不能都位于相同的一个位置(不在同一个机房). 这里有一个问题, 假如只有两个机房, 机房1中有100台data server, 机房2中只有1台data server. 这个时候, 机房2中data server的压力必然会非常大. 于是这里产生了一个控制参数 \_build\_diff\_ratio(参见安装部署文档). 当机房差异比率大于这个配置值时, config server也不再build新表. 机房差异比率是如何计出来的呢? 首先找到机器最多的机房, 不妨设使RA, data server数量是SA. 那么其余的data server的数量记做SB. 则机房差异比率=|SA – SB|/SA. 因为一般我们线上系统配置的COPY\_COUNT是3. 在这个情况下, 不妨设只有两个机房RA和RB, 那么两个机房什么样的data server数量是均衡的范围呢? 当差异比率小于 0.5的时候是可以做到各台data server负载都完全均衡的.这里有一点要注意, 假设RA机房有机器6台,RB有机器3台. 那么差异比率 = 6 – 3 / 6 = 0.5. 这个时候如果进行扩容, 在机房A增加一台data server, 扩容后的差异比率 = 7 – 3 / 7 = 0.57. 也就是说, 只在机器数多的机房增加data server会扩大差异比率. 如果我们的\_build\_diff\_ratio配置值是0.5. 那么进行这种扩容后, config server会拒绝再继续build新表.

# Tair 的一致性和可靠性问题 #

分布式系统中的可靠性和一致性是无法同时保证的, 因为我们必须允许网络错误的发生.

tair 采用**复制技术**来提高可靠性, 并且为了提高效率做了一些优化, 事实上在没有错误发生的时候, tair 提供的是一种强一致性. 但是在有data server发生故障的时候, 客户有可能在一定时间窗口内读不到最新的数据. 甚至发生最新数据丢失的情况。

# 参考博客 #

Tair-分布式K/V结构数据存储系统：http://ju.outofmemory.cn/entry/41538

[012350570157314.png]: /images/20220422/72c303899db04752b8092b688d0a6bd3.png
[012351037185667.jpg]: /images/20220422/c1325ce6d90d48b6b9f0749bebc0d648.png
[012350207183070.jpg]: /images/20220422/6d9fb75efe064a379284ff86716eb660.png