b站高可用架构 笔记
b站高可用架构
关键点:主机房,多活和多活机房
参考文章:bilibili技术总监毛剑:B站高可用架构实践
1. 前端和数据中心负载均衡
-
前端负载均衡(动态CDN):最近节点、带宽策略、可用服务容量
-
数据中心负载均衡:均衡流量、识别异常节点、扩容、提高可用性
-
子集选择算法:减少心跳检测成本,平均分配后端至客户端,节点变更持续均衡
-
高并发:多集群提高吞吐量,数据保存多缓存,单集群故障迁移成本降低
2. 负载均衡算法
-
正常:轮询
-
问题:请求处理成本不同、物理机差异、k8s容器切换用户感知
-
关键:考虑服务器可用性,构建全局视图,负载+可用性
-
算法:choice-of-2 算法,选2节点打分选择;预热新节点;低分节点统计衰减避免“永久黑名单”
3. 分布式限流
-
作用:服务器过载,先降级服务->限流保证服务稳定
-
正常:静态QPS
-
问题:某用户请求过重,挤兑其他用户
-
关键:不同流量、重要性、用户对应不同QPS,最重要服务自保
-
解决:使用算法quota-server获取quota,基于滑动窗口(一段时间内使用的次数)最大值计算quota;最大最小公平算法解决大消耗者饥饿;客户端概率公式截流,不全部拒绝
-
配额获取:基于统一错误码
4. 重试、超时、应对连锁故障
-
重试:限制次数,只失败层重试,失败返回错误码避免级联,设置周期速率诊断
-
超时:高并发高延迟引发故障,超时为fail fast让请求消耗或丢弃,上下游不一致导致资源浪费
-
“默认值策略”:每个请求每个阶段检查足够剩余时间
-
跨进程超时控制:rpc承诺超时时间,不足取消传递,超时时间覆盖上游
-
应对连锁故障:避免过载,限流->降级,重试退避,超时控制,变更管理,压测演练,扩容重启消除流量
5. 其他
当客户端访问服务时,将用户数据保存到多个缓存上
-
当Quota耗尽或申请Quota的时间过期,也能主动拉取数据。
-
quota server故障:降级本地策略或直接放行
-
Apisix vs Envoy:Apisix基于nginx ,nginx的多 worker 的协作方式具有高并发优势,Envoy总线设计使得处理东西向流量具有优势
多服务器心跳检测成本过高:
解决:子集选择。client不连接全集,只连接一部分服务器进行负载均衡。
6. b站架构
-
无限递归导致主机房CPU爆掉,限流无解,用户刷新多活机房流量挂掉
-
崩溃不影响CDN静态资源
-
多活:不同业务不同机房,主机房承载所有在线业务
无限递归导致主机房CPU爆掉,限流无解,用户刷新多活机房流量挂掉
问题:
1. b站架构如何实现高效和可靠的负载均衡
-
前端和数据中心负载均衡器(BFE和Envoy),选择最近节点、根据带宽和容量均衡流量
-
子集选择算法,减少连接和心跳检测成本,持续均衡节点变更
-
choice-of-2算法考虑服务器可用性,选2节点打分选择,预热新节点,统计衰减低分节点
2. 如何优化超大规模集群的连接和限流
-
子集选择算法,客户端只连接后端子集,减少连接和心跳成本
-
quota-server获取和计算quota,减少请求backend频次;滑动窗口算法;最大最小公平算法防大消耗者饥饿
-
客户端概率公式截流,不全部拒绝,配额获取基于统一错误码
3. 如何设置合理的重试和超时策略- 重试:限制次数,只失败层重试,失败返回错误码避免级联,设置周期速率诊断
- 超时:高并发高延迟引发故障,超时为fail fast让请求消耗或丢弃
- “默认值策略”:每个请求每个阶段检查足够剩余时间
- 跨进程超时控制:rpc承诺超时时间,不足取消传递,超时时间覆盖上游
4. 如何防止和处理连锁故障- 避免过载,限流->降级,重试退避,超时控制
- 变更管理,压测演练,扩容重启消除有害流量
5. 如何利用多活机房来提高服务可用性
- 多活(容灾):根据不同业务选择不同机房,主机房承载所有在线业务
其他:主机房CPU炸掉,限流无解,用户刷新导致多活机房流量挂掉,导致崩溃。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!