cap in tns
博客专区 > book 的博客 > 博客详情
cap in tns
book 发表于8个月前
cap in tns
  • 发表于 8个月前
  • 阅读 11
  • 收藏 1
  • 点赞 0
  • 评论 0
摘要: tns是一个thrift的分布式组件,说说tns中的cap设计

tns (thrift nameserver) provides distributed solutions for thrift, support find services, high availability, load balancing, the gray release, horizontal scaling, and so on.

cap

C:一致性 A:可用性 P:分区容忍性

Architecture in tns

集群采用无中心化设计,按节点ID排序并顺时针组成一个环,如图C1,节点按固定频率将其知道的cluster list、status和service list同步给下一个节点,并记录被同步节点的健康状态。

C1

一致性

cluster视角

在tns中,不可变约束包括cluster node列表、cluster node健康状态、service node 列表。

tns 针对以上不可变约束满足最终一致性

增加node(cluster、service)

假设数据同步周期为T,链接某个cluster node并增加一个node(cluster、service),在最长T周期后数据会被同步给下个节点,以此类推,假设集群节点数为N,最终一致时间最长为(N-1)T

移除node(service)

tns目前只支持移除service node,对于cluster node的移除功能暂不支持。

对于移除service node,tns需要经历两个阶段:Leaving阶段和Tombstone阶段

  • Leaving阶段
  • 被移除的service node会被立即变更状态为Leaving,并取消对应的ping任务
  • 在周期T内,状态会被传输到下个节点
  • 最终在(N-1)T内,状态会被传输到所有节点
  • Tombstone阶段

    • tns中有一Tombstone任务,每隔10分钟运行一次
    • 每次运行检查service node状态
      • 若状态为Leaving,将状态变更为Tombstone
      • 若状态为Tombstone,直接移除
  • 处于Leaving状态的节点仍会同步给其它节点;处于Tombstone状态的节点不会同步给其它节点;这两种状态均不接受状态更新;

为什么是10分钟?

> 保证Leaving状态广播到整个集群;保证在真正移除前,集群所有节点处于Tombstone状态。

>假设时间比较短,处于Leaving状态的service node,可能还没来得及广播给整个集群,状态即被变更为Tombstone,处于此状态的数据不会进行同步,最终导致集群某个节点没收到移除通知;另外,处于Tombstone状态的service node,节点一旦被执行移除,其上一个节点待移除数据可能处于Leaving甚至是UP状态,数据可能会被同步回来,最终导致集群出现错误。

>tns中,同步的周期被设置为5秒,数据广播到所有节点的最长时间为5(N-1),所以理论上集群节点数量N可以达到120个,结合tns的负载特点,基本不会用到这么多节点

client视角

目前版本客户端不考虑一致性问题,未来可能会增加单调读一致性,但需求不大

tns-client会定时从cluster同步数据,在这个周期内,可能会出现数据不一致。例如某时刻一个service node被移除或已经down 掉,并且未及时被tns-client同步过来,可能会导致client使用一个错误的service node来之行业务,拒绝链接等等,在tns-client中提供了brokenNode接口来移除一个故障节点

可用性

故障检测

tns采用增量故障检测算法来检测集群故障。

一个Up节点单次故障不会被立即标记为Down,而是被标记为Down_1,如果Down_1节点下次检测仍是故障,则会被标记为Down_2,如果Down_2节点下次检测仍是故障,则会被标记为Down,此后不会在对该节点之行故障检测。如图C2:

C2

cluster视角

tns中,集群节点数量N>0即可写。

client视角

tns中,集群节点数量N>0即可读,同时因为tns是一个最终一致性的系统,节点的down机,会在(N-1)T内广播到整个集群,同时tns-client定时从某个cluster node同步数据也是定时操作,所以同步时某个节点可能不可用,此种情况可以采取两种措施:

  1. 换个节点立即重试
  2. 等待下一个同步周期(选择到一个健康节点)

目前tns-client采用方法2

分区容忍性

一般认为在同一个机房不会出现分区,在跨机房场景中会出现分区现象;同时在同机房内节点的上下线也被认为是特殊的分区。如图C3:

C3

tns不满足跨机房的分区容忍性,如果跨机房部署,出现分区情况,在没有人为增加、移除节点的情况下没有问题,tns中节点的增加、移除操作均为人工操作,所以这样部署问题也不大,只要在操作前检查下集群状态即可,操作后检查下结果是否已经被广播到整个集群。

标签: tns 分布式 CAP Thrift rpc
  • 点赞
  • 收藏
  • 分享
book
粉丝 43
博文 18
码字总数 15217
作品 2