什么是服务器上下线动态感知,你了解多少!

什么是服务器上下线动态感知,你了解多少!,第1张

分布式服务器上下线动态感知(Hadoop HA)
HDFS集群中NameNode 存在单点故障问题,对于只有一个NameNode的集群,如果NameNode机器出现意外情况,将导致整个集群无法使用,直到NameNode 重新启动。

影响HDFS集群不可用主要包括以下两种情况:

NameNode机器宕机,将导致集群不可用,重启NameNode之后才可使用。

计划需要对NameNode节点软件或硬件升级,导致集群在短时间内不可用。

为了解决上述问题,Hadoop给出了HDFS的 高可用 HA方案:HDFS的HA通常由两个NameNode组成,一个处于 active 状态,另一个处于 standby 状态。Active NameNode对外提供服务,比如处理来自客户端的RPC请求,而Standby NameNode则不对外提供服务,仅同步Active NameNode的状态,以便能够在它失败时快速进行切换。而这里的快速切换是如何实现的呢?是通过zookeeper的 动态上线感知 来实现的。

简单介绍下zookeeper是什么?

ZooKeeper 顾名思义  动物园管理员 ,他是拿来管大象(Hadoop) 、 蜜蜂(Hive) 、 小猪(Pig)  的管理员, Apache Hbase和 Apache Solr 以及LinkedIn sensei  等项目中都采用到了 Zookeeper。ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,ZooKeeper是以Fast Paxos算法为基础,实现同步服务,配置维护和命名服务等分布式应用。这是zookeeper的官方介绍,对于程序原来说zookeeper在hadoop中的应用可以理解为是hadoop的整体监控系统,如果namenode宕机后,这时候Zookeeper 的重新选出leader。这是它最大的作用所在。

接下来看看zookeeper的 动态上线感知 图:

1、首先在hadoop中配置自动故障转移机制。

2、在配置HA的时候首先配置zookeeper集群,然后启动zookeeper集群。

3、在第一次启动hadoop的HA之前先初始化HA在zookeeper中的状态然后启动HA,在启动过程中会在各个NameNode节点上启动DFSZK Failover Controller,作用就是向zookeeper中注册服务器的信息,然后hadoop通过进程监控在zookeeper中的节点状态。

4、在zookeeper中注册的节点是临时节点,当服务器宕机下线的时候,zookeeper会把这个节点删除掉,这样才会产生事件,客户端(hadoop)才能监听到,然后hadoop将Standby NameNode转换为Active NameNode。

1、强一致性
这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大。

2、弱一致性

这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不久承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态。

3、最终一致性

最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型。

分布式环境的各种问题
分布式系统体系结构从其出现之初就伴随着诸多的难题和挑战:

1、通信异常

从集中式向分布式演变的过程中,必然引入网络因素,由于网络本身的不可靠性,因此 也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信,因此每次网络通信都会伴随着网络不可用的风险,网络光纤、路由器或是DNS等硬件设备或 是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外,即使分布式系统各个节点之间的网络通信能够正常进行,其延时也会大于单机 *** 作。通常 我们认为现代计算机体系结构中,单机内存访问的延时在纳秒数量级(通常是10ns),而正常的一次网络通信的延迟在01~1ms左右(相当于内存访问延 时的105倍),如此巨大的延时差别,也会影响到消息的收发过程,因此消息丢失和消息延迟变得非常普遍。

2、网络分区
当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够正常通信,而另一些节点则不能----我们将这个现象称为网络分区。当网络分区出现时,分布式系统会出现局部小集群,在极端情况下,这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能,包括对数据的事物处理,这就对分布式一致性提出了非常大的挑战。

3、三态
上面两点,我们已经了解到在分布式环境下,网络可能会出现各式各样的问题,因此分布式系统的每一次请求与响应,存在特有的三态概念,即成功、失败、超时。 在传统的单机系统中,应用程序在调用一个函数之后,能够得到一个非常明确的响应:成功或失败。而在分布式系统中,由于网络是不可靠的,虽然在绝大部分情况 下,网络通信也能够接受到成功或失败的响应,当时当网络出现异常的情况下,就可能会出现超时现象,通常有以下两种情况:

(1)由于网络原因,该请求并没有被成功地发送到接收方,而是在发送过程中就发生了消息丢失现象。
(2)该请求成功地被接收方接收后,进行了处理,但是在将响应反馈给发送方的过程中,发生了消息丢失现象。

当出现这样的超时现象时,网络通信的发起方是无法确定当前请求是否被成功处理的。

4、节点故障
节点故障则是分布式环境下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象,通常根据经验来说,每个节点都有可能出现故障,并且每天都在发生。

CAP理论
一个经典的分布式系统理论。CAP理论告诉我们:一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中两项。

BASE理论
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结, 是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。

服务器集群:
服务器集群就是指将很多服务器集中起来一起进行同一种服务,在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度,也可以用多个计算机做备份,从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡:
负载均衡
(Load
Balancing)
建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器:
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上,而是分散到多个服务器,以网络上分散分布的地理信息数据及受其影响的数据库 *** 作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化,克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷,解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题,是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构,集群的主要是IT公司在做,可以保障重要数据安全;负载均衡主要是为了分担访问量,避免临时的网络堵塞,主要用于电子商务类型的网站;分布式服务器主要是解决跨区域,多个单个节点达到高速访问的目前,一般是类似CDN的用途的话,会采用分布式服务器。
纯手工打字,希望可以帮的到你!

分布式资源共享服务器就是指数据和程序可以不位于一个服务器上,而是分散到多个服务器,以网络上分散分布的地理信息数据及受其影响的数据库 *** 作为研究对象的一种理论计算模型服务器形式。

分布式资源共享服务器有利于任务在整个计算机系统上进行分配与优化,克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷,解决了网络GIS中存在的数据异构、数据共享、运算复杂等问题,是地理信息系统技术的一大进步。

分布式资源共享服务器的特点:

1、其具有一个以全局数据库管理员为基础的分层控

服务器宕机有可能是网络故障,有可能是突发的访问量暴增、服务器处理不过来的问题。

服务器处理和响应不过来,会导致丢弃部分请求不予处理,更严重的会导致服务端崩溃。

防止由于服务器宕机可能导致的数据丢失问题的解决办法有:

一、数据备份与“多云”

如果是物理机,要做好数据备份,比如做raid;如果是选择的公有云,则最好把数据分存在不同的服务商那里。

二、web服务器配置优化

对Web服务器进行配置优化,比如:调整内存数量、线程数量等;提供多个能提供相同服务的Web服务器,以实现负载均衡;仔细规划Web服务器上部署的应用规模;对Web服务器进行集群。

三、数据库集群,进行读写分离

文件服务器用爱米云共享网盘更好,管理非常方便。安装后几分钟就能用起来,属于看看就会用了,特别简单,以尤其是对管理员省事多了。功能完全可以满足,并且资源占用很低,普通电脑就能带起来。从xp到win10,server系统都支持


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13062707.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-30
下一篇 2023-05-30

发表评论

登录后才能评论

评论列表(0条)

保存