大家好，我是码哥，可以叫我靓仔。
作为靓仔，是应该经常打开 B 站的，毕竟里面很多美好的“东西”，结果出现网络错误，我以为由于日夜观摩 B 站的视频导致流量超了。
吃瓜虽好，可不要贪杯。我们的重点是根据 B 站、小红书服务故障来聊聊高可用架构的一些设计思路。
在 2020-07-02 上午 10 点~11 点左右，B 站和小红书都崩了，出现了不同程度的故障。
打开微博， 看到 #B 站（哔哩哔哩）、小红书崩了# 的话题相继登上热搜。
图片
还有网友反映小红书首页内容无法刷新。有的则表示刷出来的内容也不是我的推荐。
图片
图片
图片
@酷安网 也发文表示网站崩了。随后，阿里云客户服务中心回复：北京时间 2024 年 07 月 02 日 10:04，阿里云监控发现上海地域可用区 N 网络访问出现异常，阿里云工程师正在紧急处理中。
图片
B 站、小红书崩了之后，对于阿里云的回应，网友认为裁员裁到大动脉了有网友认为，这次是阿里云裁员裁到大动脉了。
码哥跳动
Infoq签约作者，51CTO Top红人，阿里云开发者社区专家博主，担任后端架构师职责，擅长 Redis，Spring，Kafka，MySQL技术和云原生微服务。愿大家拥抱硬核技术和对象，面向人民币编程。
169篇原创内容
公众号
言归正传，吃瓜归吃瓜，我们应该从阿里云的网络切换故障，看到一些高可用的解决方案。
虽然网络故障，B 站、并不是所有的网页打不开，而且系统并没有垮掉，依然返回相关错误信息或者页面给用户。我们也能从里面了解到大厂工程师如何应对此问题的解决方案。
从这次的故障可以看出，B 站和小红书的系统均满足系统服务可降级。
B 站的做法是提供一个加载错误的页面，引导用户重试。
图片
小红书的降级策略有所不同，因为其表现为无法刷新内容，首页刷出来的内容不是用户推荐的。
所以小红书的降级策略是使用了缓存作为降级，比如平台无法通过网络获取用户推荐的信息流时，就直接从缓存系统或者服务器本地的缓存中获取一些内容返回给用户。
这些也是只码哥根据有限的信息哥大家聊聊，估计不久就会有官方的反馈了。本次故障相当于验证了一把 B 站和小红书的高可用是否足够强大。
系统宕机原因主要有以下：
无计划的
有计划的
分个类。
系统出现问题的地方很多，解决的方式各不相同，想要解决问题，先说下高可用的总体解决思路，才能更好的解决问题。
想要系统高可用，我们要想办法避免问题的发生。比如说，我们可以通过 UPS（Uninterruptible Power System，不间断电源）来避免服务器断电。
如果问题真的发生了，我们要考虑的是如何故障转移，比如说，我们可以通过冗余部署，当一个节点发生故障时，用其它正常的节点来代替问题节点。
几乎所有的存储系统都提供了主从复制的功能，例如 MySQL、Redis、MongoDB 等。
主从复制要点：
图片
图片来源https://raw.githubusercontent.com/dunwu/images/master/snap/20200614184921.png
主从复制有一个问题，每个机器上存储的都是全量数据。
但是，单机的数据存储量总是有上限的，当数据量上升为 TB 级甚至 PB 级数据，单机终究有无法支撑的时候。这时，就需要对数据进行分片（sharding）。
分片后的节点可以视为一个独立的子集，每个子集也要保证高可用降级：系统抛弃部分不重要的功能，比如不发送短信通知，以此确保核心功能不受影响。。
图片
图片来源https://raw.githubusercontent.com/dunwu/images/master/snap/20200614184921.png
如果故障无法正面方式解决，那我们要做的就是努力降低故障带来的影响。比如说流量太大，我们可以通过限流，来保证部分用户可以正常使用，或者通过业务降级的手段，关闭一些次要功能，保证核心功能仍旧可用。
这次 B 站、小红书亦是采取了该方案。
限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。
降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。比如 B 站返回错误引导页，以此确保核心功能不受影响。
拒绝服务 - 拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用。或者随机拒绝部分调用，节约资源，避免要死大家一起死的惨剧。
关闭服务 - 关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约资源。
熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但其实内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。
我们不去调用出问题的服务，让系统绕开故障点，就像电路的保险丝一样，自己熔断，切断通路，避免系统资源大量被占用
在实践中，系统的故障防不胜防，问题的定位和解决也非常的困难，所以，要想全面保障系统的可用性，最重要的手段就是监控。
通过监控，我们可以实时地了解系统的当前状态，这样很多时候，业务还没出问题，我们就可以提前干预，避免事故；而当系统出现问题时，我们也可以借助监控信息，快速地定位和解决问题。
博主简介
码哥，9 年互联网公司后端工作经验，InfoQ 签约作者、51CTO Top 红人，阿里云开发者社区专家博主，目前担任后端架构师主责，擅长 Redis、Spring、Kafka、MySQL 技术和云原生微服务。
本文链接：//www.dmpip.com//www.dmpip.com/showinfo-26-98421-0.html高可用架构下 B 站、小红书崩了？对于阿里回应，网友认为裁员裁到大动脉
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： Python用户宝典：了解并实现遗传算法
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
