tns (thrift nameserver) provides distributed solutions for thrift, support find services, high availability, load balancing, the gray release, horizontal scaling, and so on.
C：一致性A：可用性P：分区容忍性
集群采用无中心化设计，按节点ID排序并顺时针组成一个环，如图C1，节点按固定频率将其知道的cluster list、status和service list同步给下一个节点，并记录被同步节点的健康状态。
在tns中，不可变约束包括cluster node列表、cluster node健康状态、service node 列表。
tns 针对以上不可变约束满足最终一致性
假设数据同步周期为T，链接某个cluster node并增加一个node（cluster、service），在最长T周期后数据会被同步给下个节点，以此类推，假设集群节点数为N，最终一致时间最长为（N－1）T
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的负载特点，基本不会用到这么多节点
目前版本客户端不考虑一致性问题，未来可能会增加单调读一致性，但需求不大
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:
tns中，集群节点数量N>0即可写。
tns中，集群节点数量N>0即可读，同时因为tns是一个最终一致性的系统，节点的down机，会在（N－1）T内广播到整个集群，同时tns-client定时从某个cluster node同步数据也是定时操作，所以同步时某个节点可能不可用，此种情况可以采取两种措施：
换个节点立即重试等待下一个同步周期（选择到一个健康节点）目前tns-client采用方法2
一般认为在同一个机房不会出现分区，在跨机房场景中会出现分区现象；同时在同机房内节点的上下线也被认为是特殊的分区。如图C3:
tns不满足跨机房的分区容忍性，如果跨机房部署，出现分区情况，在没有人为增加、移除节点的情况下没有问题，tns中节点的增加、移除操作均为人工操作，所以这样部署问题也不大，只要在操作前检查下集群状态即可，操作后检查下结果是否已经被广播到整个集群。
相关资源：python入门教程(PDF版)