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同步给下一个节点,并记录被同步节点的健康状态。

一致性

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:

cluster视角

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

client视角

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

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

目前tns-client采用方法2

分区容忍性

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

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

时间: 2024-09-11 11:38:03

CAP in tns的相关文章

计算机改名引发的ORA-12541: TNS无监听程序错误

 近期上班时,由于开机时老是提示" 局域网出现计算机重名冲突",于是把计算机名字给改了,从PC2010081312zeo改为了CXBIKKKKKKK,结果第二天来的时候,用 PL/SQL连接我本地机子的ORACLE实例时,弹出ORA-12541:TNS无监听程序错误的提示,当时也没想到是计算机改名引起的问题,以为是相 关服务没有启动缘故,于是我打开服务面板,如图所示,发现 OracleOraDb10g_home1TNSListener服务没有启动,于是启动这个服务,结果等我启动后,出现

关于CAP定理的个人理解

CAP定理简介 在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点: 一致性(Consistency):同一个数据在集群中的所有节点,同一时刻是否都是同样的值. 可用性(Availability):集群中一部分节点故障后,集群整体是否还能处理客户端的更新请求. 分区容忍性(Partition tolerance):是否允许数据的分区,分区的意思是指是否允许集群中的节点之间无法通

TNS-12533: TNS:illegal ADDRESS parameters

崩溃了.这样也不行 tnsping ORCL1 报错 Used TNSNAMES adapter to resolve the alias  )SERVICE_NAME = orcl)= TCP)(HOST = 192.168.4.1)(PORT = 1521)) TNS-12533: TNS:illegal ADDRESS parameters tnsnames.ora 摘 ORCL1 =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOS

oracle-ORA-12523: TNS: 监听程序无法找到适用于客户机连接的例程

问题描述 ORA-12523: TNS: 监听程序无法找到适用于客户机连接的例程 ORA-12523: TNS: 监听程序无法找到适用于客户机连接的例程 解决方案 这是要修改客户端配置tnnames.ora文件,你试一下如下的修改 demo = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 主机名)(PORT = 端口号)) ) (CONNECT_DATA = (SERVER = SHARED) (SID=de

Oracle 8i TNS Listener 缓冲区溢出漏洞

Oracle 8i TNS Listener 缓冲区溢出漏洞 (Other,缺陷)     Oracle 8i 发现重大漏洞,允许攻击者执行任意代码 详细: Oracle 8i TNS (Transparent Network Substrate) Listener 负责建立和维系客户机同 ORACLE 数据库服务的远程连接.发现该 Listener 存在缓冲区溢出漏洞.攻击者成功利用此漏洞,将能在数据库服务器上执行任意代码. 更为糟糕的是,缓冲溢出发生在验证之前,这意味着激活了口令保护机制的

解决ORA-12560: TNS: 协议适配器错误

错误|解决 造成ORA-12560: TNS: 协议适配器错误的问题的原因有三个:   --------------------------------------------------------------------------------1.监听服务没有起起来.windows平台个一如下操作:开始---程序---管理工具---服务,打开服务面板,启动oraclehome92TNSlistener服务. 2.database instance没有起起来.windows平台如下操作:开始-

在windows server 2003系统防火墙上开放Oracle服务端口 连接1521 TNS超时

要使Oracle客户端能正常连接到设置有防火墙的Oracle服务器,单开放一个1521或自定义的监听端口是不够的. 服务器装成Windows2003了,并开放了系统自带的防火墙,在连接中发现在防火墙上打开监听端口1521后还是无法连通,报TNS连接超时错误.于是试将防火墙关闭,就可以连通,说明还有什么端口未打开所致. 当我打开1521端口时,连接操作仍然失败.我又怀疑网络有问题,用telnet server_ip:1521尝试,连接被接受,说明1521端口已经被打开. 没有办法,查询Oracle

分布式系统设计权衡:CAP

写在最前: 1.为什么学习并记录分布式设计理念一系列相关的东西 在日常工作中系统设计评审的时候,经常会有一些同事抛出一些概念,高可用性,一致性等等字眼,他们用这些最基本的概念去反驳系统最初的设计,但是很多人理解的可用性,一致性等等问题,都是自己拍脑袋想的,或者根本和最原始表达的意思就不是一个东西,在这种情况下PK,就像不再一个频段的人在交流,除了争论,没有任何实质性的进展,所以有必要熟悉其理论基础,以免贻笑大方.(其实类似的例子还有很多,国内的技术人员都喜欢把一些此词模糊化,混淆而谈.例如XX云

ORA-12535错误: TNS:operation timed out

如果Oracle资料库和client端连线有经过firewall,在MTS模式下连线的设定可能需要特别注意,因为就算你防火墙开通了1521 port,但是在MTS下listener会把连线要求redirect给dispatcher,而dispatcher的port又是random port,这时候你可以选择client端改用Dedicated 连线,或者修改dispatcher设定来达成正常连结,而不会出现ORA-12535: TNS:operation timed out. 1)client端