阅读570 返回首页    go 微软 go windows


CAP in tns

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中节点的增加、移除操作均为人工操作,所以这样部署问题也不大,只要在操作前检查下集群状态即可,操作后检查下结果是否已经被广播到整个集群。

最后更新:2017-04-11 16:00:48

  上一篇:go tns(thrift 分布式组件)介绍
  下一篇:go Java集合类操作优化经验总结