服务器是做什么用的，具体有什么作用，为什么机房要用服务器。

服务器是为我们提供不间断的互联网应用以及服务的主机，能起到为我们提供文件上传，数据保存，应用服务或网站浏览等作用，其实不是机房要用服务器，而是服务器需要机房，将服务器放在机房，是为了统一管理，节省资源，使其提供的服务更稳定。

服务器也并非就是高性能的代名词，随着目前个人电脑的性能提升，其实就算普通的电脑都可以充当服务器。

在网络环境下，根据服务器提供的服务类型不同，分为文件服务器、数据库服务器、应用程序服务器、WEB服务器等。

文件服务器为我们的文件离线存储提供了可能，我们使用的各大网盘云盘背后就有无数的文件服务器帮助存储我们上传的文件。

数据库服务器为我们的信息保存提供了可能，我们在各大网站注册的账号，提交的文字，甚至我们的行为数据，均被保存到了数据库服务器中。

应用服务器以及WEB服务器则为我们提供了浏览网页，使用各式各样应用的能力。

将服务器统一放在机房是为了便于管理，而服务器之所以需要长开，相信上边几种服务器的功能已经让你略知一二，如果这些服务器不能长时间稳定的工作，那我们将得不到稳定且随时随地都能使用网络的权力。

不难想象，如果在我们使用即时通讯工具时，服务器关机，那我们将联系不到对方，我们所有的消息都发不出去。

如果我们在使用云盘网盘等服务时，服务器关机，那我们上传一半的文件将丢失，同时也无法下载我们已经上传的文件。

还有很多各式各样的服务器为我们提供各式各样的服务，对于一些大企业，他们必须保证一天24小时甚至全年365天稳定运行，不然将会造成难以想象的损失。

所以，服务器并非没人用，我们无时无刻不在使用。

扩展资料：

在网络环境下，根据服务器提供的服务类型不同，分为文件服务器、数据库服务器、应用程序服务器、WEB服务器等。一般来说服务器应具备承担服务并且保障服务的能力。

服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

参考资料：

百度百科-服务器

转载表面上看，是一套基于B/S方式实现的分布式管理系统，但其实背后的架构是基于C/S完成的。你以为他是一只鞋吗？其实他是一个吹风机。作为界面化的系统，浏览器框架是不可或缺的，但更加重要的东西在Socket上面。

一、需要解决中央控制端到各节点服务器之间的通信。

这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的 *** 作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。

二、跨语言的socket通信

为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用phppuppet的方式管理集群，这不是不可以，puppet自己解决了socket通信协议和文件传输的问题，可你需要为了puppet在每台服务器上都安装ruby。我是个有点服务器和代码洁癖的人。光是为了一个puppet就装个ruby，我觉得心里特对不起服务器的资源。所以我自己写了一个python的代理端。python是不管哪个linux系统在安装的时候就都会有了。然后主控端的通信，可以用python实现，也可以用php实现，但是考虑到对于更多的使用者来说，改php可能要比改tornado简单许多，所以就没用python开发。hadoop分支版本众多，发布出去，用户要自己修改成安装适合自己的hadoop发行版，就势必要改源码，会php的明显比会python的多。php里面的model封装了所有的 *** 作，而python只是个 *** 作代理人的角色而已。

所以也延伸出一个问题，什么语言用来做这种分布式管理系统的代理端比较合适，我自己觉得，也就是python比较合适了， *** 作系统自带，原生的package功能基本够用。用java和php也可以写agent，但是你势必在各节点预先就铺设好jre或者php运行环境。这就跟为什么用python和java写mapred的人最多是一样的。没人拦着你用nodejs写mapred，也可以写，就是你得在每个节点都装v8的解释引擎，不嫌麻烦完全可以这样干。原理参看map/rece论文，不解释。perl也是 *** 作系统原生带的，但是perl的可维护性太差了，还是算了吧。

所以这就牵扯到一个跨语言的socket问题，理论上来说，这不存在什么问题。但这是理论上的，实际开发过程中确实存在问题，比如socket长连接，通信数据包在底层的封装方式不同。我没有使用xml-rpc的原因之一就是我听说php的xmlrpc跟其他语言的xmlrpc有不同的地方，需要修改才能用,我就没有用这种办法。最早是自己定义的 *** 作协议，这时就遇到了这些问题，所以后来直接采用了thrift方式。就基本不存在跨语言的socket通信问题了。

三、代理端执行结果的获取

无论命令还是文件是否在代理端执行成功，都需要获取到执行结果返回给中央端。所以这里也涉及一个读取节点上的stdout和stderr的问题。这个总体来说不是很难，都有现成的包。当然这个时候你需要的是阻塞执行，而不能搞异步回调。

还有个问题是，我要尽可能使用python默认就带的包，而尽量不让服务器去访问internet下载第三方的包。

还有代理端最重要的一点，就是python的版本兼容性。centos5用python24，centos6用python26，ubuntu基本默认都是27。所以一定要最大限度的保证语言的跨版本兼容性，要是每个 *** 作系统和每一个版本我都写一个代理，我一个人就累死了。

四、浏览器端的model，view，controller

这里面你要封装好所有的通信协议，以及需要在节点上面执行的脚本。发送文件的 *** 作和数据库 *** 作也要在model里面完成。

如果对tcl/tk很熟，也可以写基于 *** 作系统界面方式的管理，不用浏览器就是了。

view对我来说是最痛苦的事，都是现学的jQuery怎么用，前端的工作太可怕了。关于这方面，没有太多可描述的，html和js带给我的只有痛苦的回忆，万恶的undefined。

五、跨 *** 作系统的安装文件封装。

要适应不同的 *** 作系统也是个很麻烦的事情，需要用agent提前获知 *** 作系统的发行分支，版本号。然后去找到对应的安装文件去执行。你不能保证一个分布式系统的集群中所有的节点都可以访问internet，更多的情况是这些节点都存在在一个安全的内网中。只有个别几个节点是可以访问外网的。所以，我势必要把所有的安装文件以及他们的依赖尽可能集中起来。我不确定安装 *** 作系统的lzo，yum或者apt-get会去下什么鬼东西，甚至无论是yum还是apt-get，里面都没有hadoop-lzo的库文件。所以，最好的办法是自己编译打包rpm和deb包。直接安装就好了，别去找repo下载什么。

这就是第五步工作，把需要的依赖的东西自己编译打包成rpm和deb。

deb包很好解决，但是rpm就没那么好办了，需要学习rpm的编译文件如何编写，这块是挺麻烦的，但是这玩意用好了还是挺不错的。现在我自制的安装包里面就已经包含了自己编译的lzo和snappy两种压缩库，以及hadoop-gpl-packaging的rpm和deb。下一个发布的easyhadoop将直接支持centos5,6，suse，以及ubuntu/debian的系统上安装hadoop。已经自带了lzo和snappy以及lzop和snzip。

六、把这些所有东西，整合到一个系统里面。

关联这些所有事情间的联系，整合到一个浏览器界面里面去。写一个分布式的管理脚本不难，写一个界面也不难，但是也许是我的水平不行，这两件事结合起来让他们协同工作还是有点难度的。对我来说，写界面的工作可能更难一点。

Cloudera可能是十来个人在写Manager的东西，ambari也是放到github和apachesvn上面，apache基金会的各种committer在写。easyhadoop没他们功能那么强大，一年来只有我一个人设计架构，功能，各种语言的编码，测试，发布。Fortheloveofgod,WhathaveIdone(英文部分请站在山顶仰天长啸)T_T。从前台到后台，到hadoop和生态系统以及他们的依赖软件的单独patch、编译打包。(系统yum或者apt-get的包不如自己打的好使。)

从时间上来看，全球第一款开源的hadoop部署管理系统应该还是属于ambari，2011年8月开始写的，2012年9月底进入apache的incubator。我是大概2012年8月开始写的easyhadoop，全球第一没赶上，估计国内第一个开源的hadoop管理系统还是可以排上的。

Raft是一个 一致性算法 ，旨在易于理解。它提供了Paxos的容错和性能。不同之处在于它被分解为相对独立的子问题，它清楚地解决了实际系统所需的所有主要部分。我们希望Raft能够为更广泛的受众提供共识，并且这个更广泛的受众将能够开发出比现在更多的高质量共识系统。

Raft是一个通过管理一个副本日志的一致性算法。它提供了跟(multi-)Paxos一样有效的功能，但是它的架构和Paxos不一样；它比Paxos更加容易理解，并且能用于生产环境中。为了加强理解，raft把一致性的问题分成了三个子问题，例如 leader election, log replication, and safety,

Role

Leader，Follower，candidate

在Raft集群中，有且仅有一个Leader，在Leader运行正常的情况下，一个节点服务器要么就是Leader，要么就是Follower。Follower直到Leader故障了，才有可能变成candidate。

Leader负责把client的写请求log复制到follower。它会和follower保持心跳。每个follower都有一个timeout时间（一般为150ms~300ms），在接受到心跳的时候，这个timeout时间会被重置。如果follower没有接收到心跳，这些follower会把他们的状态变为candidate，并且开启新的一轮leader election。

term逻辑时钟

Term相当于paxos中的proposerID，相当于一个国家的朝代。term是一段任意的时间序号。每一任Leader都有一个与之前不同的term。

当Leader选举成功之后，一个节点成为了Leader，就会产生一个新的term，并且直到Leader故障，整个集群都会一直在这个term下执行 *** 作。

如果leader选举失败了，则会再生成出一个term，再开启一轮leader选举。

Quorums：

多数派，意思是超过一半的机器存活，则这个机器可用，这个Quorums指的就是集群可用的指标。例如：集群中的节点数为2N，如果有N+1的机器存活，则代表集群可用，可接受请求，写入log，应用到state machine中去，执行 *** 作。如果少于N+1个机器存活，则代表集群可用，可接受请求，可写入log，但不应用到state machine中去，不执行 *** 作。

Leader Election

只有在下列两种情况下才会进行leader election：

在第一次启动raft集群的时候

在一个已存在的Leader故障的时候

选举流程：

如果以上两种任何一种发生了，所有的Follower无法再和Leader保持心跳，则它们都会等待一个（选举）timeout，如果其中一个Follower的timeout最先到时，则这个Follower变成candidate开始选举，

第一，增加term计数器，

第二，给自己投票并向所有其他的节点服务器请求投自己一票。

如果一个Follower在接受到投票请求时，接受到两个term相同的投票请求时（也就是说，产生了两个candidate），则在多个相同term的投票请求中，这个Follower只能给投给其中一个请求，只能投一票，并且按照先来先服务的原则投票。

如果这个candidate收到另外一个节点服务器的消息，并且这个节点服务器的term序号和当前的term序号一样大，甚至更大的话，则这个candidate选举失败，从而它的状态变成Follower，并且接受新的Leader。

如果一个candidate获得了 Quorums 选票N+1(2N为集群中节点的数目)，则它变成新的leader。

如果多个candidate和多个Follower投完票之后，有多个candidate获得了相同的票数，则会产生split vote，则新的term产生，重新选举。Raft用随机选举timeout迅速地解决split vote问题，这个方法就是对于产生spit vote的candidates各自随机生成一个选举timeout，谁先到时，谁当leader，其他candidate都变为Follower。

当一个leader被选举出来之后，就在Follower timeout到时变为candidate之前，发心跳信息给所有Followers。

Log Replication（Raft协议具体过程）

Leader负责把client的请求日志复制给其他Followers。

Raft协议具体过程就是通过复制状态机的架构实现的，如下：

步骤：

Client发送请求给Leader，其中每个请求都是一条 *** 作指令。

Leader接受到client请求之后，把 *** 作指令(Entry)追加到Leader的 *** 作日志中。紧接着对Follower发起AppendEntries请求、尝试让 *** 作指令(Entry)追加到Followers的 *** 作日志中，即落地。如果有Follower不可用，则一直尝试。

一旦Leader接受到多数（ Quorums ）Follower的回应，Leader就会进行commit *** 作，每一台节点服务器会把 *** 作指令交给状态机处理。这样就保证了各节点的状态的一致性。

各服务器状态机处理完成之后，Leader将结果返回给Client。

Saftety

Raft的安全性，体现在如下几个方面：

Election safety:  在一个term下，最多只有一个Leader。

Leader Append-Only:  一个Leader只能追加新的entries，不能重写和删除entries

Log Matching:  集群中各个节点的log都是相同一致的

Leader Completeness: 如果一个log entry被committed了，则这个entry一定会出现在Leader的log里。

State Machine Safety:  如果一个节点服务器的state machine执行了一个某个log entry命令，则其他节点服务器，也会执行这个log entry命令，不会再执行其他命令

之前四条，在前面都有所提及，而 State Machine Safety 是在Leader election过程中用到过。

State Machine Safety

一个candidate在选举的时候，它会向其他节点服务器发送包含他的log的消息，获取票数，如果它的log是最新的，则会获取选票，如果它的log不是最新的，其他节点服务器还有更加新的log，则会拒绝给这个candidate投票。这就保证了State Machine Safety。

所以State Machine Safety保证的就是一个candidate必须拥有最新的log，才能获取票数，才有机会赢得Leader选举，才有机会成为Leader。

Follower crashes

如果一个follower故障了，则不会再接受 AppendEntries  and  vote  requests，并且Leader会不断尝试与这个节点保持心跳。

如果这个节点恢复了，则会接受Leader的最新的log，并且将log应用到state machine中去，执行log中的 *** 作

方格指的是client发出的一条请求。

方格虚线，说明一条log entry写入了log。

方格实线，说明一条log entry应用到state machine中

Leader crashes

则会进行Leader election。

如果碰到Leader故障的情况，集群中所有节点的日志可能不一致。

old leader的一些 *** 作日志没有通过集群完全复制。new leader将通过强制Followers复制自己的log来处理不一致的情况，步骤如下：

对于每个Follower，new leader将其日志与Followers的日志进行比较，找到他们的达成一致的最后一个log entry。

然后删除掉Followers中这个关键entry后面的所有entry，并将其替换为自己的log entry。该机制将恢复日志的一致性。

下面这种情况集群中所有节点的日志可能不一致：

总结

Raft要求具备唯一Leader，并把一致性问题具体化为保持日志副本的一致性，以此实现相较Paxos而言更容易理解、更容易实现的目标。Raft是state machine system，Zab是primary-backup system。

---