服务器宕机【宕机】

位于美国加州中部的萨克拉门托（Sacramento）有三个身份：1850年代的淘金人口集散地、如今的加州州府和Twitter的数据中心。 7月26日上午8点20分，这个数据中心停止了工作。当你输入Twitter网址时，你会看到页面显示“Twitter目前因某些原因宕机，预计稍后恢复”的提示。这种状况持续了两个多小时，直到10点25分，Twitter才恢复正常。部分用户怀疑这和7月27日开幕的伦敦奥运会有关。
尽管Twitter的运营团队通过后台的流量图看到了即将到来的奥运会热潮对各项指标的拉升—这种可预期的、能带来大流量的事件，Twitter一般都会提前做准备，然而意外还是发生了。
在Twitter的预案里，如果这里发生了洪水、地震或者其他任何有可能导致服务器停止工作的问题，距离萨克拉门托965公里的另一个数据中心就会开始工作，它位于托管服务商Raging Wire旗下的一处建筑内，当然，情况也可能相反：Raging Wire这边出了问题，萨克拉门托开始工作。
无论哪一种情况，Twitter希望保证的是用户的不间断使用体验，即便是远在大洋彼岸的用户，也可以正常地把自己的消息Tweet出去，而不会感受到服务中断。
对于互联网公司而言，在线就是生命。Facebook早期迅速积累用户并不是由于它来自哈佛大学的好名声，而是它几乎从不宕机。这与当时强劲的竞争对手MySpace形成了鲜明对 照。
但在7月26日这一天，Twitter两个数据中心同时发生故障，全球用户的Twitter服务中止。Twitter提供的解释是由于“基础设施元件中的级联式漏洞”，但没有公布更详细的信息。在Twitter的成长史上几乎每年都会有多次重大宕机事故，宕机时网站就会显示出一幅有趣的：几只小鸟用线艰难地拉起一头搁浅的鲸鱼。
这是Twitter在两个月之内的第二次重大宕机故障。此前一次是6月21日，Twitter停止服务将近两个多小时。
Twitter负责工程技术的副总裁拉瓦德（Mazen Rawashdeh）事后解释说，Twitter在数据中心有两套能互相备份的数据系统同时出现了故障，这是基础设施上的“巧合事件”。通常情况下，如果一个系统出现故障，那么另一个将被紧急启用。而两套系统同时出现问题则比较少见，为避免类似故障重演，Twitter称计划对基础设施大幅投资。
数据中心问题一直困扰着Twitter。截至3月，Twitter已有14亿活跃用户，每天会发出34亿条Tweet。随着用户量和信息读写量的增长，Twitter迫切需要一个能自我完全掌控的数据中心。
Twitter早期租用第三方的数据服务，之后计划转向租用位于犹他州盐湖城的定制化数据中心，然而在去年该数据中心却出现了漏雨、电力不足等问题，于是Twitter不得不改变其计划，另谋他处。
在同一天，悲催的不仅仅是Twitter。谷歌的即时通讯服务Gtalk也在早上6点40分发生故障，并迟迟没有被修复。有用户报告，微软旗下面对企业客户的云服务工具Windows Azure在西欧地区也发生了宕机问题。
在宕机这段时间内，Gtalk用户发现虽然能够登录，但无法像以往一样正常发送信息以及进行语音、视频聊天。他们持续接到谷歌通过网页更新的问题修复状态通知，时间单位大约为半小时，而这一状态持续了近5个小时，算是谷歌史上罕见的长时间故障。习惯线上沟通的用户们不得不转向其他工具，有人说，接连两起宕机事件让他们有一种“全球停电”的感觉。
谷歌的数据中心分布全球且多达20多个，目前无法得知是哪一块数据中心发生了故障以致Gtalk瘫痪，谷歌至今也未解释具体原 因。
世界正在变成一个由数据洪流组成的存在，而整个世界也因几个重要信息节点而相互连接在一起。但即使是像谷歌这样著名的互联网公司也无法保证自己所有的服务全年都不出问题。
据谷歌称，其最受欢迎的服务Gmail电子邮件服务2010年全年宕机时间为7分钟，这已经是业内最短时间。根据Radicati Group的数据，电子邮件系统平均宕机时间为每月38小时。对比起来，Gmail可谓优秀。
一般造成系统不稳定甚至宕机的原因是多样的，开发安卓手机管理工具豌豆荚的豌豆实验室技术总监高磊对《第一财经周刊》介绍，在用户使用网站服务时，从用户输入信息，网络传送信息给网站服务器，网站服务器按照程序对用户要求进行处理，将结果返还用户，整个过程中其中一个环节出现问题就会导致网站的服务受到影响，甚至发生宕机而不可用。
引发问题的潜在因素多种多样，包括网站自身程序、服务器的 *** 作系统、硬件设备、机房与网络运营商等基础设施。
如果网站自身程序有Bug，可能会导致使用变慢，或部分功能失效；服务器的 *** 作系统也会出现漏洞，比如装有Linux部分版本的服务器就在本月因为闰秒问题而宕机；服务器硬件本身损坏，比如硬盘或内存都存在一定物理故障的机率。
而在基础设施上，机房停电或进水、遭到雷击等也会造成设备停止运行。最基础的问题是过热，因此大型数据中心旁边一般都有冷却装置。
6月底，美国一场风暴袭击了弗吉尼亚北部，大面积电力供应中断。而恰巧亚马逊在这里安置了US-East-1数据中心，因为停电，整个数据中心瘫痪。
亚马逊是业界领先的云服务提供商，其提供给网站以数据服务的云服务Amazon Web Services也因此一度中断服务。之后连锁反应便产生，使用其服务的Instagram、Pinterest、Quora、Netflix等知名网站也停止了服务，进而影响到各自的生态系统。
为避免风险，一些网络公司选择不把鸡蛋放在一个篮子里，设置多个数据中心，或者在使用云服务时同时选择多家供应商，当然，这也会增加成本。
据新浪微博技术总监杨卫华对《第一财经周刊》介绍，是否能稳定登录，响应的速度怎样，都会对用户的体验造成直接影响。新浪微博采用了分布式的架构，这意味着它没有把所有的服务器都放在新浪所在的北京，而是在国内多个主要城市都设置了数据中心，在突发事件发生后的流量处理和响应速度等各方面来保证用户体验。
你在宕机时体验到多少焦虑，稳定对于互联网公司就有多重要。
当越来越多的人被接入同一个网络─比如被称为“世界的脉搏”的Twitter，数据中心瘫痪的风险等级也相应增加。这些数据就存储在像加州萨克拉门托的大房子里，一旦宕机，空白也从这里开始。

在计算机网络日益普及的今天，计算机安全不但要求防治计算机病毒，而且要提高系统抵抗黑客非法入侵的能力，还要提高对远程数据传输的保密性，避免在传输途中遭受非法窃取。下面壹基比小喻来给你们讲讲服务器托管站点崩溃的几大原因。
第一，内存泄漏
C/C++程序还可能产生另一个指针问题:丢失对已分配内存的引用。当内存是在子程序中被分 配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要 *** 作系统还在运行中，则进程就会一 直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。
第二，C指针错误
用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引 用指针(即，访问指向的内存)中出现一个错误，就会导致 *** 作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量(analog)将访问一个空的 对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但 使用Java对可靠性进行额外的度量则会对性能产生一些负面影响。
第三，数据库中的临时表不够用
许多数据库的临时表(cursor)数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。
第四，线程死锁
由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁 时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形:在人行道上两个人迎面相遇，为了给对方让 道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续 下去，这样就不难理解为何会发生死锁现象了。
第五，磁盘已满
导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中(例如磁带)。
日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQLNet的日志文件、 JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与 *** 作系统不同的文件系统中。日志文件系统空间已 满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。
第六，服务器超载
Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其 它的Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。 *** 作系统级别可能还在不断地接收新的连接， 而应用程序(Web服务器)却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected(已连接)的提示消息，但这以后什么也不会发生。
总之，还有许多因素也极有可能导致服务器租用或服务器托管站点无法工作。有许多种原因可能导致Web站点无法正常工作，这使得系统地检查所有问题变得很困难。

---