本文目录一览：
b站用的什么典型数据库
Mysql。
B站后台应该也是golang和java混搭的，目前B站不是在逐渐去除java嘛，还有就是B站后台稳不稳定跟用什么搭建没有呀直接关系，与一个系统的架构设计，熔断降级等配置有关系，是否有完善的监控系统，有强大的运维团队，有高质量的代码等因素有关系。从之前B站泄露出来的代码看，目前B站后台的核心技术栈是Go语言。至于为什么用Go语言后面会说到，事实上B站流量在行业内并不是顶尖，就算是用Go语言作为核心技术栈的网站中，B站也不是技术难度最高的。不过同样值得关注的是，B站对于UP主的保护是全行业最佳，刚刚B站也签下了冯提莫，不断大动作的B站未来发展可期。随着行业的不断发展，各种新兴语言不断出现，一个项目中多种语言并存、互补的现象是必然的，也许几十年后你还会发现用Go写的后台被其他语言改写了，或者某种你以为已经成为历史的语言卷土重来也不是没有可能。
降级与熔断
降级与熔断
1.1、降级
降级也就是服务降级，当我们的服务器压力剧增，为了保证核心功能的可用性，可以选择性的降低一些功能的可用性，或者直接关闭该功能。典型的弃车保帅！ 就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。
1.2、熔断
降级一般而言是我们自身的系统出现了故障而降级。而熔断一般是指依赖的外部接口出现故障，断绝和外部接口之间的关联。
例如你的A服务里面的一个功能依赖B服务，这时候B服务出问题了，返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能，因此我们这时候就需要熔断！即当发现A要调用这B时就直接返回错误(或者返回其他默认值啊啥的)，就不去请求B了。
1.3、熔断状态机
三种状态：
Close 关闭状态，熔断器的初始化状态，允许请求通过
Open 开放状态，即熔断状态，不允许请求通过
HalfOpen 半开放状态，允许部分请求通过
1.4、hystrix包详解
hystrix是Netflix的开源库，go版本是hystrix-go。
主要以下几个模块：setting，hystrix，circuit，metrics，pool和eventstream。
1.4.1、settings
setting 用来管理熔断器的配置，包括存储，新增和读取。
map+读写锁实现多个circuit的配置。
Timeout: 执行command的超时时间。默认时间是1000毫秒
MaxConcurrentRequests：command的最大并发量 默认值是10
SleepWindow：当熔断器被打开后，SleepWindow的时间就是控制过多久后去尝试服务是否可用了。默认值是5000毫秒
RequestVolumeThreshold： 一个统计窗口10秒内请求数量。达到这个请求数量后才去判断是否要开启熔断。默认值是20
ErrorPercentThreshold：错误百分比，请求数量大于等于RequestVolumeThreshold并且错误率到达这个百分比后就会启动熔断 默认值是50
1.4.2、circuit
circuit 用来管理熔断器的状态变更。
除此之外，circuit还上报事件给统计器
创建circuit的时候，会根据配置创建相应的metric和exePool
1.4.3、metrics
metrics用来统计和计算请求的响应情况。
每一个Command都会有一个默认统计控制器，当然也可以添加多个自定义的控制器。 默认的统计控制器DefaultMetricCollector保存着熔断器的所有状态，调用次数，失败次数，被拒绝次数等等。
在执行newMetricExchange的时候会启动一个协程 go m.Monitor()去监控Updates的数据，然后上报给metricCollectors 保存执行的信息数据比如前面提到的调用次数，失败次数，被拒绝次数等等。
1.4.3、pool
pool 用来管理请求池，控制请求池最大数目以及请求ticket的发放和回收。
1.4.4、hystrix
hystrix 是熔断器的主要部分，对外提供同步和异步的方法，对内上报请求事件以及fallback降级处理。
func GoC(ctx context.Context, name string, run runFuncC, fallback fallbackFuncC) chan error
参考：
go-zero高可用-自适应熔断器
微服务集群中，每个应用基本都会依赖一定数量的外部服务。有可能随时都会遇到网络连接缓慢，超时，依赖服务过载，服务不可用的情况,在高并发场景下如果此时调用方不做任何处理，继续持续请求故障服务的话很容易引起整个微服务集群雪崩。
比如高并发场景的用户订单服务，一般需要依赖一下服务：
假如此时 账户服务 过载，订单服务持续请求账户服务只能被动的等待账户服务报错或者请求超时，进而导致订单请求被大量堆积，这些无效请求依然会占用系统资源：cpu，内存，数据连接...导致订单服务整体不可用。即使账户服务恢复了订单服务也无法自我恢复。
这时如果有一个主动保护机制应对这种场景的话订单服务至少可以保证自身的运行状态,等待账户服务恢复时订单服务也同步自我恢复，这种自我保护机制在服务治理中叫熔断机制。
熔断是调用方自我保护的机制（客观上也能保护被调用方），熔断对象是外部服务。
降级是被调用方（服务提供者）的防止因自身资源不足导致过载的自我保护机制，降级对象是自身。
熔断这一词来源时我们日常生活电路里面的熔断器，当负载过高时（电流过大）保险丝会自行熔断防止电路被烧坏，很多技术都是来自生活场景的提炼。
熔断器一般具有三个状态：
使用较多的熔断组件：
基于上面提到的熔断器原理，项目中我们要使用好熔断器通常需要准备以下参数：
实际上可选的配置参数还有非常非常多，参考
对于经验不够丰富的开发人员而言，这些参数设置多少合适心里其实并没有底。
那么有没有一种自适应的熔断算法能让我们不关注参数，只要简单配置就能满足大部分场景？
其实是有的， google sre 提供了一种自适应熔断算法来计算丢弃请求的概率：
算法参数：
算法解释：
接下来思考一个熔断器如何实现。
初步思路是：
下面来逐步分析 go-zero 的源码实现：
core/breaker/breaker.go
兵马未动，粮草先行，明确了需求后就可以开始规划定义接口了，接口是我们编码思维抽象的第一步也是最重要的一步。
核心定义包含两种类型的方法：
Allow()：需要手动回调请求结果至熔断器，相当于手动挡。
DoXXX()：自动回调请求结果至熔断器，相当于自动挡，实际上 DoXXX() 类型方法最后都是调用
DoWithFallbackAcceptable(req func() error, fallback func(err error) error, acceptable Acceptable) error
circuitBreaker 继承 throttle，实际上这里相当于静态代理，代理模式可以在不改变原有对象的基础上增强功能，后面我们会看到 go-zero 这样做的原因是为了收集熔断器错误数据，也就是为了实现可观测性。
熔断器实现采用静态代理模式，看起来稍微有点绕脑。
throttle 接口实现类：
loggedThrottle 增加了为了收集错误日志的滚动窗口，目的是为了收集当请求失败时的错误日志。
errorWindow 是一个环形数组，新数据不断滚动覆盖最旧的数据，通过取余实现。
看到这里我们还没看到实际的熔断器实现，实际上真正的熔断操作被代理给了 internalThrottle 对象。
可以看到熔断器属性其实非常简单，数据统计采用的是滑动时间窗口来实现。
滑动窗口属于比较通用的数据结构，常用于最近一段时间内的行为数据统计。
它的实现非常有意思，尤其是如何模拟窗口滑动过程。
先来看滑动窗口的结构体定义：
window 是数据的实际存储位置，其实就是一个数组，提供向指定 offset 添加数据与清除操作。
数组里面按照 internal 时间间隔分隔成多个 bucket。
window 添加数据：
window 统计数据：
熔断器对外暴露两种类型的方法
func (b *googleBreaker) allow() (internalPromise, error)
func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error
Acceptable 参数目的是自定义判断请求是否成功。
微软 azure 关于熔断器设计模式
索尼参考微软的文档开源的熔断器实现
go-zero 自适应熔断器文档
电脑开机显示器黑屏，出现POWER SAVING MODE
显示器显示：Enter power saving mode 的意思是显示器进入省电模式。
如果接好了线，但显示器没有反映，表示显示器没有接收到主机显卡的显示信号。
1，检查显示器和显卡的连接（特别是有独显和集显的，不要接到集显上）是否正确，接触是否良好。
2，检查显卡和主板是否接触良好，显卡是否正常工作，清洁显卡的金手指，重新插拔试试。
3，检查主机是因内存接触不良等问题没有正常开机（硬盘灯没有跳动，没有进入系统的声音[有音箱的话]）。
4，将主机接别的显示器试下，如果也不亮证明是主机问题，用替换法检查显卡，内存，主板找出损坏的硬件。
5，如果接别的显示器能显示，换回原来的显示器还是一样，显示器损坏，需要维修。
