服务器被挤爆产生什么后果

1
服务器宕机；
2
网站或者服务器上应用无法正常打开或者正常连接；
3
访问量过大，并发较高，会大量占用服务器带宽，CPU等资源，会导致服务器一时无法及时反应，造成宕机，应用无法正常运行；
4
但服务器宕机并不会给服务器硬件设施造成伤害，也不会影响到应用程序以后的正常运行和使用。

“宕机”的拼音读法为：dàng ji。宕机属于计算机的术语，指电脑或者服务器不能正常工作。口语中我们简单地把停掉机器叫做down机，转换为汉字是“宕机”，不过多数人都叫做“当机”/“死机”，虽然不规范但却流行。

down就是up的反义，就是计算机不能正常工作了，包括一切原因而导致出现的死机。

通俗一点来说，宕机我们完全可以理解为服务器或者电脑出现故障，导致了无法正常工作。相信我们在浏览一些不知名的网站，有的时候出现无法访问的问题，那么这种现象都可以叫服务器宕机。

B站回应崩了：部分服务器机房发生故障

周二 ( 7 月 13 日 ) 晚间有消息称，B 站出现服务器宕机事故。消息传来之后，哔哩哔哩股价短线走低，涨幅收窄至 3%。

稍早前，有多位网友反映，B 站网页端和移动端均出现加载失败现象，有网友一开始还以为是手机或者信号的问题。

针对昨晚哔哩哔哩全平台崩溃一事官方现回应称，B 站的部分服务器机房发生故障，造成无法访问。技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。

除此之外，官方未对任何服务器方面或技术方面的细节进行讲解。

B站服务器机房发生故障，造成了多方面的后果。从影响上来说，创下了多个热搜；从用户的角度来说，减少了熬夜时间；从其他同类型网站角度来说，无辜躺q了。

网上有一条关于“B站崩了”的热搜，让很多人知道了B站服务器机房故障。现在B站也算是国内的主流视频平台之一，每天有大量的用户。服务器无法使用，用户自然只能跑到其他平台。由于其他平台比较小，远远比不上B站，大量用户的涌入，直接导致了他们的服务器崩塌。一家崩，全员崩，形成了一个连锁反应。

1、事情经过

B站在一天晚上，突然出现了服务器无法访问的情况，当时不是个别现象，而是全体用户。在经过技术团队的排查之后，确定了原因，是部分服务器机房发生的故障。因为现在B站做得很大，即使到了晚上也有很多用户，所以立马上了热搜。

随后相关的工作人员也出来解释，表示问题正在解决，相关的服务器已经恢复正常，大家可以向往常一样使用。其实出现这个问题，是很正常的一件事，很多网站都出现过类似的现象。

2、引起的后果

众所周知，B站不是传统意义上的主流平台，它兼顾视频、短视频、二次元、主播等多个方向。因此B站崩了之后，直接引起了连锁反应。

为了继续看相关内容，网友们先后进入到A站、豆瓣、晋江等多个相关平台。因为这些平台本身用户是一个平稳的状态，突然涌入的用户让服务器措手不及，于是就出现了连环崩的情况。这几个相关的平台无一幸免，全部加入到了维修服务器的行列，让原本处于这些平台的用户，也无法继续，只能选择睡觉。热搜也从“B站崩了”，变成了“B站、A站、豆瓣、晋江都崩了”。

3、减少了用户熬夜

要说这次事件产生的一个好影响，那就是减少了用户的熬夜时间。现在很多人明明第二天有课程、有工作、有业务，可是仍然会选择熬夜看视频，以至于第二天没有精力。随着全平台的服务器崩坏，大家不得不选择睡觉，熬夜时间大大减少。把所有平台的用户熬夜时间叠加在一起，这可不是一个小数字。事情发生后，还有很多网友调侃，说自己可以睡个好觉了。

—、服务器出现宕机的原因
1运行环境出现问题，机房断电导致的服务器断电(欠压，过载，波动)、机房温度过高，散热不良、资源冲突、DirectX文件的损坏、系统不完善等等原因而造成服务器宕机。
⒉服务器不堪负重，最常见的如磁盘空间耗尽、访问值过大、程序中毒、遭受攻击等大规模高消耗服务器资源情况。
3由于主备数据不—致导致的复制问题。
4性能问题，运维运行糟糕的SQL或Schema和索引设计等。
二、服务器宕机应该从哪些方面检查呢
①硬件
(1)检查硬件是否有冲突;
(2)对比服务器电源所负载的功率判断电源是否出现故障;
(3)扫描硬盘表面检查是否有坏道;
(4)通过错误报告和 *** 作系统的报错信息来判断;
(5)使用替换法判断主板、CPU、SCSI/RAID卡或其他PCI设备是否出现故障。
②软件
(1)检查 *** 作系统的系统日志，可以通过系统日志来判断部分造成死机的原因;
(2)在判断硬件没有故障后，考虑系统软件的BUG和漏洞原因;
(3)如果是因为软件使用不当或系统工作压力过大，可以适当降低服务器的工作压力;
(4)电脑病毒。
以上就是有关服务器宕机的原因有哪些，应该从哪些方面检查的知识介绍。
在想解决处理办法之前要知道服务器宕机的两种形态：假死机和死机
假死机(非蓝屏死机)是由于硬件资源暂时性地被消耗殆尽，因而无法对外部指令进行响应的现象， 通常是网站处于访问高峰期，带宽等资源跑满，这时只需要等待一定的时间，待服务器腾出更多的硬件资源即可恢复正常。
而死机，如果通过ping测试服务器，键盘切换数字锁定键(NumLock)或大写锁定键(Caps Lock)功能， 显示器无画面输出，或者鼠标光标没有任何反应则表明服务器硬件故障。
再了解服务器出现宕机的常见原因 ：
1在运行环境的问题中，最普遍的问题时磁盘空间耗尽。
2在性能问题中，最普通的服务器宕机原因确实是运行很糟糕的SQL， 但也不一定都是这个原因，比如也有很多问题是由于服务器Bug或错误的行为导致的。
3糟糕的Schema和索引设计是第二大影响性能的问题。
4复制问题通常由于主备数据不一致导致。
5数据丢失问题通常由于drop table的错误 *** 作导致，并总是便随着缺少可用备份的问题。
如何查看服务器宕机的原因：
a、是否是应用程序导致内存溢出或者泄露，out of memory导致
b、是否是进程过多或者不断创建，耗尽资源导致
c、是否是数据库程序死锁，连接数过多导致
d、是否是应用程序异常导致
e、是否是流量负载过大导致
f、 是否是遭受黑客入侵攻击导致
g、是否是误 *** 作导致
服务器宕机自行解决办法：
1要即时发现服务器宕机的问题。时间就是金钱，这是不变的真理。我们要第一时间， 发现宕机的问题，服务器宕机时，为了避免造成不必要的损失，要尽早通知IDC服务商解决相关问题。
2最好准备2个服务器空间，他们存放的内容相同，而ip不同，并且机房的地理位置不同。这样2个区域的服务器， 能够做到有效异地容灾备份。发现宕机问题后，可以迅速的通过修改>由于微软激活服务器出现宕机，Windows10无法激活可能是因为服务器出现了硬件故障、网络问题、软件错误或者 *** 作系统负载过高等原因。首先检查服务器运行状态，确保服务器能够正常运行；其次要检查服务器网络情况，确保服务器能够正常连接到网络；最后要检查 *** 作系统版本，确保 *** 作系统版本正确并且能够正常运行。

最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对DBA来说也是一项挑战，可能你的手一抖就会导致多少人无法正常使用业务，如果你没有把握，请先把现场环境备份后再进行 *** 作，避免数据的二次损坏，下面壹基比小喻说一下大概的思路吧。
1检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。
2对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。
在mycnf中[mysqld]下加上以下配置，采用强制恢复机制，看是否能够启动
[mysqld]
innodb_force_recovery=1
如果设置成1不能启动，可以逐渐的将数据增大到6，下文会详细说下1-6是什么意思，如果在1-6之间启动成功了，那么你运气还不错，这时候不要恢复业务，赶紧把数据用逻辑方式导出来，再启个新的实例把数据还原，有人会问，为什么mysql已经启动了，还要导出数据呢，原因在这：
当innodb_force_recovery被设置为大于0的时候 ，会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务，类似于windows系统下的安全模式。以下这段引于其它地方，具体地址不太清楚了，也可以从官方文档中找到。
innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B树和其它数据库结构的更多破坏。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页，也让服务器运行着；试着让SELECT FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化 *** 作过程中发生，这将阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并 *** 作。如果你可能会导致一个崩溃。最好不要做这些 *** 作，不要计算表统计表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志：InnoDB把未完成的事务视为已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery被设置为大于0的值时，InnoDB阻止用户执行INSERT, UPDATE或DELETE *** 作
即使强制恢复被使用，你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程，然后设置innodb_force_recovery为3，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
关于上面进行逻辑备份也可能会遇到问题，可能会备份失败，如果出错，建议先按库一个一个的备份，到哪个库出错后，再按照当前库的表一个一个备份，表出错根据表中主键一点一点备份，最终将大部分数据导出。如果你的数据不重要，可以容忍丢失，那么可以当我说的都是废话了。
3如果还是不可以启动，那么恭喜你，你遇到挑战了。
查看错误日志，看没有提示因为某个表的原因而导致启动不了，可以先把损坏的表的ibd文件先从数据目录mv走，再试着启动，在数据已经恢复后，我把当时错误的文件拿到本地，做了测试，把几个报错的ibd文件mv走后，数据库就可以正常启动了，但是mv走的这几个表数据会丢失。怎么把这个表的数据弄回来呢，曾想过用在线表空间传输，但是cfg文件却没有，这种方法没有行通。后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复，关于这个工具的介绍与 *** 作，网上一大堆，我就不详细说明了。

---