B站大型活动背后的数据库保障原创

好的，活动开始之前呢，我将先跟大家介绍一下，本次活动的主办方是由我们数列科技联合talkinging talk组委会共同举办。数列科技是成立于2017年，旗下主动防御式稳定性保障平台taing，目前已帮助国家电网、中国人寿等50多家头部企业的系统稳定运行。而旗下的ting tops组委会呢，则是聚焦于稳定性保障领域的高端技术交流组织，关键词是性能稳定性。我们致力于邀请业界一线的技术高管和技术专家，为大家串联起一个互相交流学习的平台，打造稳定性领域的顶级组织。嗯，Talking talk s live是我们新开辟的一个线上专栏，以轻量级的线上分享形式，用更及时、更聚焦、更深入的形态，针对某一个具体的技术原理、厂。

场景应用落地方案以及最佳实践进行分享和交流，本次的talking top live呢，我们邀请到了B站的数据库大佬陈阳老师来为我们带来B站大型活动背后的数据库保障。嗯，在陈阳老师开始分享之前呢，请直播间的各位小伙伴们，嗯，大家先进群。在群内呢，我们将会有老师，嗯。在群内呢，我们将会和讲师进行一些轻松的对台，以及活动结束之后，我们也会有两轮最佳手气的抽奖，嗯，一些精彩大家可以不用错过。嗯，接下那接下来呢，我们将会有请陈阳老师来带带展开今天的精彩分享。喂喂，可以听到吗？喂喂，可以听到吗？

喂。哦，可以听到是吧。嗯，OK，那我开始了啊，首先非常感谢乔薇小姐姐的暖场，然后以及talking talk给我们带来这么一个好的分享平台，对，然后我叫陈阳，然后接下来的话呢，我们来一起聊一下，我们B站再去组建一场大型活动的时候，我们数据库团队做会做哪些运维，以及我们的一些支持工作，OK，然后我看一下屏幕，呃，切一下。OK。OK，好，嗯，我先自我介绍一下，我叫陈阳，目前在就职于哔哩哔哩，我大概有13年的数据库运维经验，最开始的时候是在一些大型的一些传统企业进行一些呃传统的数据库运维，比如说Oracle DB two这些这些数据库，对，然后最近五到六年吧，开始转型到互联网行业的，然后进行MYQ的相关的一些互网生态一些数据库的运维，包括有MYSQ，然后red mango，然后以及一些分布式数据库，比如说我们用的比较多的TB，然后还有一些呃，O base的一些调研，对，然后的话呢，自己也做过一些数据库自动化运维，然后以及我之前的话，在数据库自动化运维上还有过一些关于数据库的一些呃专利的一些分享，对，OK，然后我们看我们的后面的内容，呃，首先我们的目录的话是分为几大块，第一块就是我们来看一下我们在不同的活动背后，我们将会有什么样的数据库压力，因为每一种不同的活动，它对于数据。

库的压力，它的类型是会不一样的，对，然后呢，第二点的话呢，就是我们来看一下我们活动前需要做哪些准备的工作，因为我们活动的活动之前的准备工作将会是决定我们整个活动进展的是否顺利的非常重要的一个条件。然后的话呢，第三点就是我们活动期间的保障，活动期间保障的话呢，主要是我们在进行一场大型活动的时候，我们DBA团队的小伙伴一般来说都会在做些什么事情，然后再往后就是我们活动后的一个复盘，我们活动后每一场活动之后我们都会进行一些复盘，我们我们有哪些地方做的不够好，有哪些地方是我们值得去下一次活动继续去发扬，继续去坚持的一些东西。

嗯，首先可以先介绍一下B站，B站的话呢，实际上在很多用户的眼里，它是一个可以用来去看视频，再或者说去看一些番剧，看一些嗯，或者说有一些同学会用它用作一些当做学习的平台，对然后呃，还会有一些还有一些直播的场景，对然后其实在更多人的一些没有没有发现的一些视角下呢，B站还有很多其他的业务属性，比如说我们除了点播之外的话呢，还会有直播业务，直播的话，我们这边将会以呃游戏直播为主，比如说一些英雄联盟的全球总决赛，也是我们去年比较大的一个直播的一个项目，对，然后承接流量，也可以说是整个游戏直播界一个top级的一个流量，对然后接下来在做我们做直播的时候的话呢，实际上我们会面临很多场景，嗯，这些场景对我们DB的压力是不一样的，因为比如说一个，呃，还是拿我们游戏直播来举例，假如说比赛到了某一个比较关键的环节，某一个选手做了一些。

一些比较比较比较比较出色的一些操作，那么这时候呢，可能会出现各种各样的一些弹幕的一些呃弹幕的互动，或者一些送礼的互动，那么这时候瞬间会对我们的DB的造成很大的一些高并发的一些场景的一些压力，对，再或者一些送礼一些呃道具排行榜这些东西，对，那么这时候的话呢，对于数据库来说，它会存在一些热点数据，那么这些热点数据我们怎么来去解决，它也是后面我们将要去分享的东西，然后接下来还会有电商，嗯，电商类的场景的话呢，其实业内我们电商电商的一些呃公司还算比较多，B站的电商还算是在一个刚起步的阶段，但是呃，业务场景大概大概都是一些大同小异的一些东西，如果做过电商的同学，一般来说都会比较了解电商，他对于一些事物的一致性，数据的一致性要求是非常高的，因为电商的一般他的业务逻辑会非常复杂，另外一点的话呢，电商它会有几个比较比较明显的特征，就是平时的时候，它可能它的量也不是特别的高，但是在在一些大型。

活动的时候，比如说电商一般来说都会有一些大促或者说秒杀的一些活动，那么到这些活动的时候，或者数据库的QS会在时达到非常非常的高，那么时候它也会存在一些问题，比如说我秒杀的时候，我们扣减库存。我们的一些热点商品怎么去处理的，然后还有一点就是说是游戏，游戏的话呢，相信如果说有关注过B站财报的同学可以发现，其实游戏在B站整个财报中还是占了非常大的比重的，因为B站有很多有很多一些类似于二次元之类游戏，还是有很多用户受欢迎的，对于游戏来说，嗯，大家玩过游戏的，其实对游戏我觉得最大的体验就是说我的游戏玩的时候不要去卡。

还是拿还是拿一个呃，英雄联盟来说，可能一场团战也就十秒15秒的时间，那假设这时候我的DB卡了两三秒，那么这时候对于整个团战的一个质量影响是非常大的，对，OK，然后的话呢，我们可以看一下我们B站有哪些活动，其实在比较早的时候，B站嗯还没有去被很多用户关注到的时候，B站只会被一些比较呃支撑的二次元用户，那么这时候B站很多用户，其实比较老的一些B站很都知道，B站以前都叫做小破绽，小破站的话，实际上它有几方面原因吧，第一方面就是说它可能B站的确以前的体量的确是比较小，然后另外一点的话呢，就是说他也经常会出问题，因为我们稳定性之前因为比较小，所以的话对于稳定性还没有看得那么重，然后第二点就是说，可能很多用户觉得B站这个社区这个平台很亲切，破也是一种昵称，对，然后的话呢，可以看一下我们B站这些活动，呃，再早的活动我就没有去列出来，因为再早的话其实我还没有来到B站，然后。

而且之前的活动也没有说很多，被很多用户关注到。从一九年之后，其实我们比较。嗯嗯，影响力比较大的一场，就是说我们一九年的B站的跨年晚会，因为一九年欢迎晚会的话呢，当时的反响是相当的好，然后嗯，结束之后会有很多人来去评价，来去转发，对然后对于大家来说，可能这个跨年晚会看起来很爽。但是其实对于我来说，这个欢晚会我过的是非常痛苦的，因为当时我记得很清楚，当时是我们整个组的DBA全部都在去值守这个活动，然后整场活动是报警不断，然后跨年晚会应该是在在呃12点的时候，凌晨12点的时候结束的，然后我们当时我们处理了大概是三点钟才全处理完所有的告警和相关的一些事情才回家，对，所以是过得相当痛苦的一次，然后然后随着后面的话呢，我们就嗯，包括一些我们的呃直播的一些英雄联盟的S10，就英雄联盟S10的全球总决赛，我们从一九年应该是下半年吧，还是二零年上半年，后来是买了呃英雄联盟的全球总决赛的三年的独播权，所以的话呢，我们在每一年的S10的时候也是一个比较大的流量，对。

然后在后面的一些流量中呢，随着我们的一些逐渐的积累，我们逐渐的一些，嗯，基础设施一些提高，我们的一些SOP的一些标准化的一些，嗯，完善化，包括我们的应急预案，然后这些东西准备完善之后的话呢，到后面的话是，呃，在去年的。去年的11月份吧，应该是S11的全球总决赛，就英雄联盟的是，呃，英雄联盟的全球总决赛的时候，那么这时候这个流量相当相相对来说是应该是我们B站直播以来，也是整个应该是整个游戏直播的一个，嗯，游戏直播的一个整个赛事以来，算是top级的一个流量了，当时的话流量是非常非常大，但是当时我们整场下来，我们整场gba，我记得当时我们是应该就三个人在，然后上我们要做的事就是说。

再再看，再看比赛，所以基本上我们已经不需要再去做很多一些各种各种各样应急的一些，嗯，一种应急的一些操作啊，或者一些去出应对一些突发情况这种事情了，对吧？OK，然后接下来我们看一下我们，嗯，在我们不同的背后活动背后，我们会有些哪些地备的一些压力呢？我们可以看对于一些直播来说，其实我们最主要就是一个高并发的一个写入场景和一些读和一些读取的场景，高并发的写入的话呢，实际上来说，我们一般考量就是我们主库的写入能力，以及对于我们重库的复制能力能否对得上，然后的话，另外一点就是说高并发的查询，高频发查询的话，一般来说我也有几种方案，一般就是说缓存，然后分布式缓存，然后再上local，就是我本地的缓存，因为分布式缓存它也会存在热K的问题，对吧，然后接下来就是多级缓存，当我的缓存，嗯，当我的缓存。失失效，或者整个缓存集群出现问题的时候，那么这时候这些流量打到我的DB来，我的DB是不是能够扛得住，那么这时候一方面我们可以通过DB的限流来去做，另一方面的话呢，我们可以通过多级缓缓存来进行一些抗，能扛住一些透过穿缓能穿透的一些场景，对吧？

然后接下来就是对于我们一些嗯实时排序，比如说我们直播会有一些排行榜啊这些东西，这些就是其实还算来说比较好，比较好去做一些优化，就一般来说选用一些嗯，比较合理的一些数据类型，就可以来去解这个事儿，对然后还有另外一点就是说我们会有一些预期外的突发流量，那么这时候我们怎么去进行的快速扩容，我们怎么进行我们队列的消峰，以及我们怎么去来进行的异步化，对然后这在我们后面将会去进行一些详细的介绍，嗯，然后的话，第一个问题就是说我们。在高并发的场景下，我们一般来说，我们怎么去显新我们的数据库，那我们现有的来说，现有的业内的方案，开源的方案就是说如果说我主库写不下了，那么那么就是要么就是进行拆分，分工分表，这我们业内最常用的方案，而现在随着最近几年分布式数据库的一个发展越来越好呢，我们可能多了另外一种选择，就是说选用分布式数据库来去解这个场景，但是对于我们B站来说的话呢，其实我们不论是分布分表还是分布式数据库，我们都有很多的集群或者很大的量在里面，对嗯，拿我们分布式数据库来说，我们现在呃用的最多的是TDB分布式数据库，然后B站的台DB集群在业内也可以说是top提量的，对。

然后，然后我们自己公司内部怎么去选型这个业务，它适合用分布分表还是说是用分布式数据库呢？我们会有几个衡量标准，第一个标准就是说我的数据量的可预估性，嗯，这个这个比较好，比较好来去解释，比如说我一个U表。那么那那么我全球的用户顶多也就70亿，那么这个表它不会扩，扩大到一个完全我没法去考量的一个维度，所以这时候呢，我用分红表可以很轻松的去把这一侧给解掉，但是对于一些其他的场景，比如说嗯。

我们点赞，我们我们一些视频的一些点赞，就B站来说，我们一些点赞的一些数据已经在去年的时候已经突破了千亿的数据量，那么这时候可能这个数据量在我们两年之前是没有考虑到的，而我们点赞之前的话，也是采用买C的分布分表，之前分了102 1024片，但是随着我们的数据量越来越大，发现1024片已经扛不住了，所以我们要需要进行一个二次拆分，而二次拆分的话呢，对于数据库来说也是一个比较大的一个代价，对吧？然后当然业内会有一些方案，或者有一些有一些呃中心件来可以帮我们做一些事儿，比如说it可以来帮我们做一些无感的一些，嗯，以下的一些过程，但是对业务来说也是也是有损的，对，所以这时候的话呢，我们就。在进行一系列评估选移之后，考虑引入了台币，对，那么这时候我们就可以进行一些水平的，对于业务来说可以相对无感内块，虽然虽然说它还会是有那么一些会会有那么一些的业务的感知度，但是它相对于MY的来说，感知度已经小了非常非常多了，对吧？然后的话呢，第二点就是说我的业务的分片件，对于做过MYSQL分工分表同学可能都会了解我的分片件来决定我分工表是否成功，它是一个非常关键的一个点，但如果说我的业务分片件不固定，或者说我有很多个分片件的时候，那么这时候我们就需要做很多业务层的妥协，或者说一些权衡，对，那么这时候的话呢，如果说没有一个好的分辨线，那么们可以考虑使用分布库分分布式数据库，那么这时候我们就可以不用做分布分表，对，这也是我们考量的一个维度，然后第三个维度就是说是分布式数据库。

对于我们业内来说的话呢，有很多有很多分布式的一些proxy可以来帮我们做一些分布分表的场景，但是真正做过分布分嗯分库分表的pro开发同学都了解，分布式事物是我们分布分表pro中最难做的一个点，也是我们很难去处理一个点，因为我们做很多人推到我们要么系统的性能，要么形成一些一致性，要么进行一些嗯柔性事物的一些补偿这些手段，对实际上在我们是如果说我们使用分布式数据库的话呢，那么这时候我们很多东西在分布式数据库的底层或者引擎层，他已经帮你去做好了这些事，所以也有层完全不用考虑这些事情。

然后的话呢，下面一点就是说我们的P999分位的响应时间，嗯，分布式数据库的话呢，它帮我们的确帮我们解决了很多问题，比如说我们的一些水平扩容，我们的一些嗯嗯，快速弹性扩容这些这些东西，但是的话呢，它也引入了一些我们没法去改变的东西，比如说哪现有的分布式数据库开源的来说，一般来说TB或者说base，它的底层都是lsm数的，对对于LM数来说的话呢，有一个不可避免的点，就是说他一定会做，那么他做的时候对于数据层，那么一定是有影响，是有感知的，所以说它的P99有分位的响应时间肯定是没有MYS那么稳定的，以及它的在非常小量的一个数上面的时候，它的一个响应肯定是赶不上MYSQL的这样。

所以的话，这时候我们也需要做一些取舍，一些权衡，看业务侧对于我们数据库的P99分面的感知是什么样的，我能我们能不能接受这些影响，对然后再往下就是弹性扩容，弹性扩容的话呢，实际上它要分成几块，然后嗯，对于MYSQL来说，其实我们很难去做弹性扩容，对于大家大家用过MYSQL都知道MYQL的话。嗯，主要是存储层，你很难去快速的去扩容，而对于一些业内的其他的一些手段，比如说嗯公有云，公有云的一些，公有云那些数据库，嗯拿那个嗯阿里的po DB，然后腾讯云的三，再或者说嗯，Awsr，它都是先把MYQ算给拆分成两层，然后对于计算层我们放在K8S里面去。

这样如果说出现问题的时候，我们可以去快速的来扩容或计算层的能力，但是但是对于存储层来说的话呢，一般都会放到分布式数据库，但是对于一些开源的数据库来说呢，并没有这种实现，所以的话呢，我们也也没有去能够有很好的办法来去去进行一些买课程的一个快速扩容，但是在在我们B站的话呢，我们也会有一些其他的备选方案来去实现这一点我们后面来介绍，然后对于TDB的话呢，算是也是分为两块，如果说是计算节点TDB节点。之间平的话，那么这时候我们也会是比较好的扩容，因为我们也是把它放到KS里面去，然后通过KSHPPV能力来去进行快速的横向扩容，对，然后对于DB节点的话，就对于我们这个KV节点的话呢，这时候可能就不是那么快的能够去快速扩容，因为即使我很快的把一个KV节点扩上去，但是他re balance可能需要几天，甚至说上月这么一个过程，对。OK，然后接下来第二点就是说电商大促，电商的话呢，实际上我们这个考虑的场景就是说我们的一个高性能，假如说我们一个大促，可能也就在这几分钟的时间，我们要把这个活动给干完，秒杀就可能我们就几分钟就秒杀完了，假如说这时候挂了。

然后对MY来说，我们一般业内的通用的一个水平就是大概可能是15秒到20秒之间，只会挂了，然后进行一个切换，那么这时候可能整个活动的影响都会大打折扣，对然后所以他对于高可能对它的是有高可能性是有一个很高的一个要求的，另外一点就是高性能，因为电商在在一些秒杀场景下的话，它就是在极段的时间内要处理非常多的一些事物，对然后第三点的话，对于我们的数据一致性，数据一致性的话，一般来说，嗯。嗯，它包括我们的事物的一致性，以及我们的数据组成复制的一致性，这一点的话，我们都需要进行一些设计和一些嗯优化，对，然后接下来就是说我们的一些秒杀场景，秒杀场景的话呢，实际上我们需要进行一些合适的一些选型，比如说我们有些可以适合放队列，有些适合它适合嗯放到我们的KV，对，然后有些请求的话呢，在我们进行秒杀的时候，我们要把它给设计成最简化，不然的话，整个事物如果说特别复杂的话，那它是不能完成我们的秒杀的。然后对于我们的一些嗯订单库的话呢，常见的一般都是一些人的分离和拆分的一些手段，然后库存的话呢，是我们电商秒杀场景中比较难处理这个环节，一般来说就是说我们再去。

一般增库存不多，一般都是减库存，减库存的场景我们需要考虑很多事，如果说你放在DB的话，那么它会面临个问题，就是说我DB的对于热点商品的一个秒杀，我的行怎么去解决？然后的话呢，如果说你放在缓存的话呢，那么有一个场景需要去解决，就是说我缓存和DB的一致性怎么去处理，如果说不一致的话，那我可能会出现商品超卖的现象，对然后接下来就我们流量的一个校风，以及我们的一个分层的一个策略，对然后对于嗯电商秒杀场景的话呢，我们之前也做过很多的调研和一些优化，比如说我们最初的时候是拿的是嗯那个阿里阿阿里开源的阿里CQL这个分支，然后阿里CQ这个分支的话呢。

它算是在秒杀测MYSQLMYSQL系列分支的一个比较比较非常优秀的一个分支了，但是对于开源版本来说有很久没维护了，而且嗯，现在应该是阿里云上它的那个阿里C的版本会比社区开源阿里斯版本性能会高很多。对，那所以我们当时测的是一个开源版本，所以它的性能也并没有说到一个很优秀的程度，我们当时测下来的话，其实它嗯，它的最高的QPS，当然这这在我们自己的硬件，可能硬件会有一些差异，对，但实际的话，它可以到达99K的QPS，就对于单个商品的一个秒杀，对。然后接下来的话呢，我就我们就开始对于我们自己的一个数据库来进行。有了标杆之，我们就对它进行一些优化，对，然后接下来就我们因为我们整个B站的话，买C使用是买RDB的分支，对，所以的话呢，我们首先测试买DB10.1版本，没有做任何调优之前的性能，发现它对于单个事物的秒杀，它性能是相相对来说是。

相对于阿里CQ来说是相当于大概可能1/3左右的，1/3~1/4左右的一个性能，对这个性能表现可以来说是相当的差了，对，然后接下来就是说我们看了一下，嗯，买了这10.3的版本，那10.3版本的话呢，我们进行哪优化，那么这时候我们进行哪优化呢？这第一个就是我们的线程池的优化，然后第二个就是说我们进行了一些我们的一些其他线程池相关的一些参数的优化，就他在线程池中会有一些我们活跃连接数的一个饱和机制，那这些参数进行优化之后呢，发现它有了一些提升，但是不是那么明显，后来后来，然后我们接着又往下面去。又往下面去研究，然后发现实际上它整个环节的话呢，嗯，在我们单个商品热点商品秒杀的场景下，其实最主要的核心点还是在于MYCQ的一个实锁检测机制，因为MYSQ的话呢，它是有一个实锁检测机制，如果说嗯，它会探测一个事物和其他正在运行的一个事物，它们之间会不会存在思锁的可能，那么为了实现这种特性的话，它就会实现了一个思所队列，那么这时候在每一个事物在开始之前，它会去检查这个队列中是否有和我当前事物可能会出现冲突的事物，如果有的话就立即返回，大家要放这种参数，让你去快速的进行一个死锁的回滚，而不至于等到我的死锁。

等到我锁超时，比如说一般来说可能是十秒，等到十秒之后才会去返回这个15超时。但是呢，这个机制的话呢，在高并发秒发秒杀的场景下，它会带来一些副作用，因为在高并发高并发嗯，高并发秒杀的场景下的话呢，我们的事物队列中会有很多处于等待这的队列，那么这时候的话呢，它需要做一件事，就是每一个每一个事物它都要去检查一次，而这个事物它处于喷进状态的时候的话呢，会把这个死锁队列会拉的非常的长，那么就导致我们的并发越高，到后面我们的那个呃，我们的QPS会变得越低，效率会越来越差，直到我们测试下测到1000的QPS 1000的那个并发的时候，那么它的QPS，然后没有优化之前，只能到了200多的QPS。

对，然后后来的话，我们尝试把它关闭之后发现其实我们在并发升高之后，我们QQPS的损损耗以及我们TPS损耗并没有说像之前那么明显了，但是的话呢，关闭思锁它也会带来其他的问题，关闭思所并不是一个业内通用的做法，因为它会带来很多未知的问题，比如说思所检测机制，本来它就是为了保护我业务中逻辑中可能会出现的未知的一些思锁的逻辑。假设把它关闭，那么时候如果说假设业务不幸中的出现了失误的逻辑，那么这时候他可能会瞬间把我的数据库失力给打崩，对，这就是他带来的非常严重的一个后果，对。

OK，嗯，然后接下来我们看我们电商大促，一般来说我们可以从我们嗯不同的一些架构设计，以及我们的一些嗯不同的一些层级，嗯多层缓存，以及我们的一些嗯数据库的一些拆分，在架构设计上来去减少我们在整个环节中的一些嗯不合理的一些消耗，对，OK，嗯，从上面来看，可以从我们的CDN层，我们必须有我们动态数据和我们的静态CDN数据来保障我们去来去一些强制的页面数据的刷新及回源，然后我们库存的话呢，我们会有一些cash。然后但是看的话，一定他有有多种条件的校验，和我们的一些系统来去校验，保证他能拿到是一个一致性的数据，对，然后包括我们一些订单，然后我们的详情这些东西肯定要进行相关的很多的分分表的一些创建，来去进行达到我们整个数据库的一个，嗯，数据库的事物的一个极简性，对。OK，然后接下来就是说看一下我们的一个压测，压测的话呢，其实对我们整个B站来说，压测是我们每一次大活动非常重要的一个环节，也就是说他他决定了这个活动到底能不能按照我们预期的一个预期的一个呃，期望值能够去顺利的进行，对吧？然后我一般情况我们每一个活动在。

嗯，之前的提前两个月就会开启我们的一轮的压测，我们至少会进行三到五针的压测，对吧，然后在压测初中的话呢，我们会发现各种各样的问题，然后在在我们去尝试去解决这些问题的同时，然后再去去修复我们我们的系统中存在的一些不合理的一些设计，或者说来提高我们系统能够达到一个更高的一个呃，吞吐的一个水平，对。然后的话呢，一般来说其实在，嗯，在前期的话，我们需要去造一些数据，然后包括一些我们的一些水位线的评估，就在压缩之前的话，我们会进行一些我们的数据库的线评估，对我们来说，一般来说我们最常用的评估的，嗯。

指标有这几类，比如说我的物理资源，我的CPU，我CPU使用率，以及我的我的内存使用率，然后包括我的实际的QPS和TPS，是不是在我设定设定的一个合理的预值范围之内，我是不是需要提前对它进行一些库，然后接下来就是我的的响应时间，一般来说我们会拿我们的P99的响应时间，以及我们的慢查询，是否慢查询，那还有我们的一些八块命中率，当然还有也还会有一些其他的一些指标，这里就比较多，我们就不列出来这么多了，对吧？那另外一点的话就是说我们压测数据怎么类，这这个时候的话呢，我们也有几种选择，一种选择就是说我们克隆集群，一般来说常用的方案就是说，可能会基于聚容器快速拉起来一个压测的一个数据库集群，然后进行数据的填充，然后测试，然后另一种呢，就用原集群进行压测，但是的话呢，对于前者克隆集群来说的话呢。它会可能会存在一种问题，就是说我的克隆出的集群和我原机原集群的性能并不能100%的对标，因为因为会存在这么一种可能，因为嗯，大家用过SSD的同学都会了解，SSD的磁盘的性能是和它的它的使用寿命以及它的存储的容量是有关，就是说一个盘你克隆出来一个新的实例，如果它放在一个比较新的机器上，那么它可能性能会比我老机会更高，那么时候可能就会出现一些压测和实际的情况不对的情况，这样。

而且如果说一个活动它涉及的库特别多的话，那么对于我们资源也是非常大的一个消耗，包括我们同步数据也是非常大的一个成本，所以就出现了第二种话，就是说我们在原梯形压测。那么在原集群进行压测，怎么能保证我们不影响到我们线上的数据呢？一般情况我们也是分几种，第一种就是影子库，影子库的话呢，也算是一个比较常见的一个方案，但是它的问题就是说，一个是我需要去，嗯，把我的连数给放大一倍，因为我所有的连接需要在源库连，正常业务是连我正常的业务库，而我压测流量会连的是我压测的影子库，那么这时候我们的连接数是会翻倍的。

嗯，好处就是说比较清真，我不用去，我只要从连接层DSN层，我的连接串就能去判断出来我的流量是将要打到哪里去，然后另外一种方案就是说引子表，引子表的话呢，是我们会在我们的，也是我们B站用的比较多的一种方案，就是说我们会在我们的所有的表前面会克隆出来一个前缀，比如说我们，我们一般会叫做哔哩哔哩杠shadow，然后杠。表明对这样子的一些具有可识别的一些标识的一些前缀表明，那然后同时的话呢，会在我们的基础框架，我们的一些大仓层做一些SDK层的一些改造，那么它可以再通过我们传过来的一些T或者一些标识来去识别这个流量，它是一个压测流量，然后这时候的话呢，他就会把我们流量往我们的压测表里面去打，这时候他就要设计一个功能，就是说我需要进行CQ改写。

把我以前写的A表，那我们需要改写成，假如我们对我们来说就是改写成B哩B哩杠C-A这么一个表，对，然后这一层的话，对我们的基础，基础框架，对我们的架构层也是有一定的要求，对。OK，然后接下来就是我们的流量复制，流量复制的话，其实我们也有可能种方案，不论是开源的还是一些商业的方案，都会有挺多种非常优秀的方案在里面对，然后再往下就我们数据的清理，数据的清理的话呢，一般来说我们都会有一些后台任务来去在任务衔，在业务低峰期的时候进行一些。异步的一些清理，这样去防止去影响到我们线上业务的进行。OK，然后有了这些数据之后的话呢，我们的压测中，我们怎么去发现是哪个环节出现问题，那么这时候我们就需要引用了另外一个比较重要的一个工具了，就是我们的全链路跟踪工具，然后这个截图的话呢，是我们我们基站在用的一个全链路，是我们自研的一款工具，对，嗯，上面可以看出来，可能有些东西被我已经打码掉了，对，但是可以看出有些东西它可以清晰的看到我们是在哪个环节，耗时多少秒，一个请求一个事物，比如说他在MYSQ一个carry肉上面花了0.8毫秒，然后在另一个环节，比如一个get，那花了多少毫秒，这样子的话呢，我们就可以准确的去定位到我们是慢的哪一个环节了，那么这时候的话呢，我们就可以去根据我们慢的那个环节来进行一些有目的性的优化，对，然后所以说这对于我们，对于我们整个压测来说是非常重要的一个问题，我们必须要有这么一个工具来帮助我们去压测，来帮我们快速的去定位到到底是哪个缓解出了问题的，OK，然后接下来在我们压测完之后的话呢。

一个合理压测报告我们应该去包含哪些内容的，也是我们需要去考量的一个东西。对于D来说，我们比较去重点关注指标，也就是它的一个P99围的响应时间，它的客S和TPS，以及它的一个嗯呃，它的一个磁盘的嗯，磁盘的IPS，以及它的一个磁盘用率，然后一些水位线，CPU内存这些指标，它是不是在我们可控的一个范围之内。

然后以及对于我们的一些，嗯，核心的一个C口，它是不是会出现的一些慢查询。对，如果出现的话，我们就进行一轮的优化，直到我们整个压测达到我们所要的预期的目标，那么这时候的话呢，我们就可以认为它是一个合格的压测报告，对，然后再往下来一点的话，就是说我们的应急预演，实际上我们应预演的话，一般来说我们会推荐它在你的压测中进行，而不是在业务低峰期的时候进行。因为如果说一个系统，特别是对于滴滴来说，在高负载下和在低负载下，它发生的异常情况，我们面临的和需要去处理的问题是完全不同的，所以这时候我们需要在最极端的情况下去考虑我们应该去做哪些事，我们应该有哪些我们的一些应急预案，我们哪哪些SOP我们需要去准备，这样子的话才能在我真正的再进行一些大型活动保障中来，去达到一个真实的一个目的，对。

不然的话，如果你在平时去压测的话，其实它量本来就没什么量，可能很快的，拿我们的高空组件来说，它可能很顺利的，比如说在十秒就切换掉了，但是在一些事物的一些比如说成功者时出现了延迟，那么时候可能它的切换时间就比我们预期的要多出很多，那么这候我们需要做做一些其他的一些权衡取舍，是我们是周期到这些事物，还是说等它应用完，还是怎么来去做，对然后接下来一点就是说，嗯，我们还需要去考虑，我们在压测的时候，不应该只考虑我们核心的业务，可能还要考虑我们核心业务所带来的一些附带的一些下游系统，或者说我们其他的业务的一些压力，还作为这一点的话呢，还是我在我们去年去年还是做S11保障之后得出来一点，因为我们在最开始的时候都是在去各种各种压，我们的我们的直播系统，我们的我们的观看平台，我们的各种各种接口是不是符合我们预期。

也就在去年的时候，我们整个活动保障的是非常顺利，然后在我们整个活动完之后，我们开始把自己的东西都已经整好，开始已经准备好了出去吃夜宵，出去玩的时候，那么时候我的告警话响了，对，然后我又不得不去回到我的办公室来，去处理这些告警，然后当时就是因为我们去年是S11的时候，我们嗯，夺冠的是是是中国中国的一个队，然后之前大家对于他的预期是没有预想的，他会夺冠。然后但是嗯，在最终的结果中呢，他发挥的非常的出色，然后最终得断了，然后这时候的话呢，会有很多的用户得到这个消息之后就涌进来，然后去看我们的那个录播，然后各种点赞，各种评论，然后导致我们我们防子最开始最重要的环节，但是没考虑到，就是说在我们夺冠之后产生了这些事情对我们下游系统产生的压力，这一块是我们开始考虑出复到的点，所以导致我们后来又返回办公室处理了半天的事情，对。

OK，然后最后一点就是墨菲定律，就我们再去做一个加测的时候，或者说我们再去评判一个系统的时候，如果我觉得这一点他可能出现问题的话，那么我们一定要去立刻着手去解决它，去把它处理掉，而不能放到侥幸的心理，这一点的话，对于任何不只我觉得不只是做数据库吧，我们做任何一个做技术的人来说都是非常重要的，对，嗯，OK，然后接下来是我们应急预案，应急预案的话呢，实际上是我们在做每一年，呃，每一次大促的时候，我们都会去重新review的一个环节，因为呃，拿我们每次活动来说，比如说我今年上半年做一次，那么这次活动到我们下半年的时候，我们应应急预案是不能够直接拿出来用的，因为我们在上半年做完之后，我们肯定会有更多各种各样的机价的一些提升，一些优化，那么时候包括我们自己自己的一些平台，一些工具链，它都会进行一些升级，那么那么我们这些旧的这些预案，它是不是还是一个可执行的最佳？

那么我们必须要全部把它拿出来，再重新review一遍，对，然后才能确保我们执行的预案。它是一个。它是一个我们嗯最佳的一个决策，对OK，然后我们看下我们有哪些语言，就是说嗯，对于数据库来说的话呢，一般来说就是可能存在几点情况，第一种情况就是说过程，就我比如说假设我主办举办了一场直播活动，我预期的人数是十个人，那么这时候我我来了20个人。那我对于我们来说应该怎么办？当然我们第一手段肯定是在我们的可有资源内快速的扩容，刚刚就讲到就是说我们MYCQ对于业内来说，我们用开源板的话，没有进行存算分离，那我们怎么去快速扩容呢？对于我们这边来说的话呢，我们在MYSQL中会有一些其他机房的一些灾备，比如说我们灾备节点。

以及我们的那个，嗯，我们的一些备份用的节点，或者说我们一些离线的一些数据抽取的一些节点，那么这时候这些节点的话呢，在举办活动的时候，他一般来说，或者说甚至是日常的时候，它都是以闲置状态。那么假设我这时候我的重复的我的毒性就忽然扛不住了，那么之后我们会迅速的把这些可以去拿来去加到我们的负载资源池的这些重复实例，会把它给加入到我们的proxy的负载均衡资源池里面去，对这一系列的话呢，是我们通过XY来去自动进行负载均衡的，OK，如果这时候的话呢，它加进来之后，那么这时候对我重复来说，我的毒性呢，就可以瞬间提升到可以提升一个档次，对，那这样的话可以帮我们去临时的去应急，把我们的一些嗯，突增的一些流量给应急掉，这样。但是对于TDB来说的话呢，它也分为几种情况，存储和计算，计算的话呢，我们TDB计算节点都是放在那个，呃K8S里面去管控的，我们通过K8SHPV能力，然后去进行自动的一个横向的扩容，对，就我们会对CPU进行一些预值的设定，假设它到达我们CPU的意，比如说满到60%了，那么它会自动的去弹性扩容，增加新的节点。

OK，假如他的CPU做完活动之后，他又去降到了10%了，那么说我们会再去弹性的把它给降低几个节点，对这个我们自动弹一扩能力这一系列的话，就不需要我们去手动去干预，只需要去自动的来去它根据负载去调节就可以了。那么另外一点就是说，当我的。计算节点不停的扩容，那么我们存储节点压力将会去逐渐的增大，那么这时候它也不是无限的往上扩的，因为当我存储节点到达一定压力之后，我们会评估不再让它干预，不让它去自动的扩了，那么这时候的话呢，我们需要对存储集团进行扩容，但是对于TDB来说的话呢，存储阶点扩容虽然说是很快的一瞬间的事，但是实际底层的数据平衡，我们的一些region的re balancell和者一些迁移，那么他要根据我们的数据量和我们region的数量来去定，有可能需要很久的时间，所以一般来说存储扩容的效果，它不会在很短期内拿到收益，但是我们能做的是我们可以把我们计算机点能够快速扩了，对。

就是我们现在这是我们现在一些快速扩容的一些方案，对然后期间呢，需要我们的一些，比如说我们一些基础组件的支持，比如说我们的一些pro感知能力扩容，以及我们的迅速的一些嗯，配置的一些服务发现的能力，对这些东西都是我们需要我们有一些完善的技术组件的配套设施来去实现，才能达到我们想要目标，对样，然后接下来就是说，嗯，如果说我扩容。不能解决问题，假设我还是嗯嗯，预计是十个人的直播流量，我来了20个人，但但是我系统现在只能承载的15个人，那么这时候我们就需要做一些取舍的，那么这个问题实际上是我们一定要去做的，因为我们不可能为了去强行。

强行去接纳20个人，而导致现有的15个人也全部不能观看我们的比赛，对吧，这时候我们就需要进行一些限制，现流程的话呢，我们一般来说分为几类啊，第一类就是说我们在SRB层可进行一些业务层的限流。这层的话，我相信在在很多公司都会有，因为这是一个最通用的一个手段，SRB层进入过程的限制，但对于很多一些其他的公司的话，他会觉得就是说嗯嗯，整个下流过程从业务入口侧去线就行，我们DBDB跟着业务走，但实际上我们在我们DB层的话呢，我们B站也是有自己的一个质保的一些手段的，对我们认为就不可能每个环节。不可能依赖别人完全可靠，我们也要去假设别人在不可靠的情况下，我们怎么进行自保的。所以的话呢，我们也会在。DB层会有一些限流的策略，比如说我们的X层，我们会有一些限流的策略和拦截，当这个东西这个流量它超出了我们一些之后，我们在pro层进行一些限制策略的配置，它会进行一些流量拦截，把多余的流量给它拦截掉，直接返回失败对。

或者说SDK层，我们SDK层也会有一些限流以及熔断的一些设置，对这些东西也是来帮助我们在做DB的层面进行一些极端情况一些质保。OK，然后但是对于一些其他一些预案的话，比如说一些嗯，一些非过载的场景，那么时候可能限流和限流和我们的那个扩容，它并不能解决问题，那么这时候可能我们需要一些切流的手段，或者说降级的手段，然后呢，降级的话呢，一般来说我们这边会有一些自动的一些探测机制，比如说我们会有一些后台的一些自动服务，会去探测我存库的延迟，如果说发现我的MYSQ存库发生了延迟。那么这时候系统后台会自动的去自愈服务，自动去降级，我们买机构的刷盘策略，把它从双一刷到双零，如果做过做过DBA的同学都会知道，双一双就是保证我们事物的一次性，就每个事物是否在每一个事物都去刷盘一次这种，嗯，这种机制的话呢，在很大的程度去保证我们事物每个事物不会重复的事物不会丢失，以及我们主库的写入的数据不会因为我的实力或者说我的OS丢失。

但是的话呢，在我们复制场景下，它会给我们复制的一些性能带来很大的一些影响，假设在一些极端情况下，那么这时候的话，我们就会进行一些自动的。把给降成双音，降成双零，这也是我们现在也是它会自动做的一些事情，然后的话呢，当发现它的延迟对象之后，然后又会把它双零，再把它给嗯升级为我们的双一，这样来去最大的保障我们的数据不至于说他再去丢掉的，OK，然后另外一点就是说我们的业务请求教领业务请求的话呢，一般情况就是根据我们呃，这个就跟我们业务关系会比较紧密一些，当然一般情况我们也会跟业务进行一些嗯，一些架构设计，或者是一些从嗯服务治理，或者说产品的一个可靠性角度来去做一些。

做一些宣讲，对，这就是一般来说我们是s re的一些工作内容的，因为s re我们后面可以再讲一下S，因为我们整体的DB也是在在往DB re或者说s re这个方向来去转的，因为在国外的互联网公司，它都是在走这个这个这个方向，对，如果说大家看过，嗯，谷歌或者说或者说Facebook，或者说GI这些公司。他们，他们是没有DBA这个角色的。OK，那S事情我们可以下来再去开展，那我们先先回到我们的一个降级策略上，对，然后接下来就是说我们同时还会有一些实力级别的切入，然后我们对于我们pro来说的话呢，它会去感知我们的实力，它是否健康，如果它不健康会自动把它剔除掉，对我们也会出现一些自动切流的一些手段在里面，同时的话呢，我们也可以人工进行干预，因为我们有些实力多货机，它会分布在多个机房，那我们这时候可能可以通过我们的后台的一些管理。

进行一些指定，比如说让他读上海机房，还是说还是说呃，苏州机房，我们可以进行一些流量的一些调配对。另外就是说当它出现一些故障的情况，就是就是比如说出现了一些非over的一些场景，那么这时候就是由我们高科用组件来进行进行切换的一个场景了，对，然后接下来就是我们的B，就是我们zone，我们的级别的切流，这个切流就会影响就会比较大，一般来说都会从整个整个整个调用链来去进行切，对下面的话我们也会来去看我们在多活场景，我们怎么来去切流的，对然后另外一点的话呢，在数据库层面，其实我们还会有一些通用的一些。在我们的配置参数以及我们的引擎上会有一些通用一些配置限流的，或者说一些优化的一些策略。这样。常用的一般就几个参数，就是那对于上面两个可能大家都会比较熟悉，My mass connection和一个是控制总的因素，另一个控制为用户级的因素，然后对于后面两个参数的话呢，一个是就是说是一个dbrency，就是说是我允许进入到DB层的一个并发的限制。

另外一个就是说in dbcus这个参数的话呢，可能有些同学没有做过专业DB的，可能了解的不是特别多，对这个参数它是用来控制我们每一个进入nno DB层的事物，它和我inno DB交互的一个时间片，或者是我的一个次数，对然后接下来我们来看一下，就是我们nno d并能够有多少多少个线程能够进来和诺DB层进行交互，对然后的话呢，嗯，在比如假如说我们in度DB设是四，OK，那么这时候如果说我并发是100，那剩下的96个它怎么办呢？它会进入一个我们的一个等待队列。等待最低的话也是诺DB层，为了去让这些等待的一些事物，它能够进行一些排序，以及它有一些嗯。

它的一个秩序，以及我们的一些事物，后续的一些事物的，嗯，我们的一个复杂度，以及我们事物的一个代价的检查来去设定的，对吧，它会进行一些随机的sleep，然后进行唤醒，然后再进行尝重新尝试进入的度DB，度DB层，对，然后对于在度DB层的这些事物的话呢，它也不是无限制的一直和印度DB进行交互的。还拿这个图来举例子，假设我n DB con这是四，那么是不是我同时来了四个大事物，每个事物查询一小时，那是不是代表就是这样就可以导致我的数据库100%的数据，其他的线程都处理不了了呢？实际上大家发现并不是，这可能会导致我数据库变得非常的慢，但它并不是说其他的事物完全被堵死。嗯，为什么会这样呢？就是因为no DB层为了防止这种现象，所以有一个参数叫做n DB concurency tickets。

它就是来控制我这些到达DB交互的这些线程，它并不能是无限无休止去进行交互，对，它也需要再进行我的ticket用进之后，它需要退出队列，重新排队啊，所以这个时候的话呢，就需要我们对于DB层的一些我们的一些并发和我们的一些ticket的参数配置有很高的一些要求，就假如说我把我的in dbent ticket调的比较大，那就代表我每个事物可以可以和应度DB层交互的时间片或者超次数会非常的长，那么这种场景的话呢，它会比较更大程度的保护我们的一些大事物，对。对我大事物可以可以更更更多的停留在因DB层和他进行交互，然后可以导致我大事物可以更少的退出我的因格DB层，更少的排，但对小事的话可能会更，但对于一些业务场景的话呢，我可能会想要把的小事，我以小事为主，那么这时的话呢，我们可能会把我们ticket调的比较小。

那么这时候的话呢，就会去让那些大事务你交互完之后，你就出去重新排队吧，你不不至于在那一直站着，对，所以这个机制的话呢，我嗯，我这里会有一些买这个官方文档的一些介绍说明，就我们怎么去权衡我这两个参数来去达到我的一个系统能够达到我们的一个想要的一个，嗯，保护的某种业务的一个目的，对。OK，然后的话，接下来就是我们这个限流算法，我们怎么来限流的话，一般来说限流算法的话呢，我们会有会有会有四种算法，第一种算法就是说我们常这也是最简单的一个算法，就是固定窗口，就在某一个窗口之内到达我们那个值之后，OK，剩下的请求全部卡断，对然后这种算法的话呢，一般来说用的稍微会比较少，因为它比较不太灵活，对然后第二种就是说我们加了一个滑动窗口，在第一种固定窗口的情况下，做了一些改造，加了一个滑动窗口，就是说我是一个可以滑动窗口，而不是一个固定的，那么这时候的话呢，它会对我的一些请求会有一个比较灵活的一个，更平，看起来更丝滑的一个。

一个现象，对，OK，然后然后再往下呢，剩下两种就是我们用的比较多的一些算法了，比如说我们的漏斗算法，漏斗算法就是说它的原理就是说我一直往这个漏斗里滴东西，但是我出去的。第二和初级的速率是一个恒定的速率。这是我们嗯业内用的比较多的算法，但不算最多的算法，因为它它有它一个一些弊端，比如说对于一些突发流量，我还是不能去提高我的瞬间吞吐能力，那么这时候的话呢，如果说我之前一直十正好漏斗可以正好可以处理完，那忽然来了个100，那么这我漏斗时上还是以十的处理，那么这时候对我系统来说，可能感知感知度并没有那么的好。那我们怎么去设计我们能够系统去承载一定量的突发流量呢？那么这时候就引入了一种新的并排统计算法，这种算法也是我们现在在用现状策略中用的最多的一个算法，就是说我们每一个请求，它会有个令牌桶来去分，可以分发这个东西，所以在我们在闲时的时候，它实际上令牌统可以积攒一部分的流量，也就是说在我高业务高峰期的时候，他可以去把我们积攒这一分令牌桶的一部分，这一部分的ticket可以消费掉，这样的话呢，对我们一些，比如说一些嗯，偶尔的一些峰值这么来说的，它可以瞬间来提高我们的，顺便提高我们的销入能力，但是又不至于说一直去无限制的提高，那么这样可以对我们一些可能会出现一些瞬间，偶尔比如五分钟一次，十分钟一次这种请求的话呢，它会有一个比较好的业务层的感知，对。

OK，然后接下来是我们应急预案的熔断策略，熔断策略的话呢，一般来说它是会来保护我们某个服务的下游出现故障而设计的，就是说，嗯，假如说我的下游出现了问题，如果说我不去进行一些熔断，我还继续的调了它，假如拿DB来说，还是DB，就是说假如说我DB出现了慢查询，那么我的服务这时候我还是不停的去调DB，那可能会导致DB加剧，直至雪崩，那么这时候我们必须要有个策略，就要熔断，我们去发现DB层，它是不是能够去正常的去请求它，在一定的单位时间内，它的请求是不是都能够正常的返回给我，是成功的次数还是失败次数达到一定什么样的阈值，那么这时候我我就会把它给开启到一个熔断策略，假设说我们，嗯。

假设我们的每一秒钟失败的次数到达了100次，那么这时候就自动去开启一个打开熔断策略，那么时候我们就不再去调DB的东西了，因为我调它，它已经失败率已经非常的高，那么时候我再去调它，只会导致它出现更坏的一种结果了，对，这时候我们在一定的时间之后的话呢，把我们的熔胀器置为一个半打开的状态，那么时候我们这时候呢，我们就需要去进行一些尝试，就是我不可能永远都关闭掉，那这时候我们需要去隔一段时间之后再去再去看一下，OK，我这个请求是不是恢复正常了，那这时候就是这这个时候的话呢，我就是处于一个半打开的状态。

如果说我们这时候发现它已经恢复了正常，那么时候我们就会再把进入到一个打开的状态，对这些的话呢，也需要我们对于我们的SDK层，或者说我们的层，或者我们技术框架层来去做的一些事情，对我们现在的话呢，也是把它给集成到了我们的一个我们整体的B站的一个技术架构的一个大仓框架里面，对这这嗯，这个PPT的页面就是说是我们在熔断上的一些配置，这里可以看到我们会有一些熔断器的一些开关，包括们一些窗口，包括你8K的一些什么样阈值，到达什么阈值，我们进行一些什么样的一些处理，这个是业务侧再去配置，我们数据库访问的时候可以自由来去配置，可以达到我们对于DB层的一个保护的一个目的。OK，然后嗯，再往下就是聊到多活，嗯，其实多活这个话题是相当大的一个话题，我们这里的话，因为时间的关系，不，嗯只能聊到可能可能聊到比较比较极浅的一方面，可能聊到1/10，甚至1/10都不到，对我们就简单简单的去讲一下我们B站性的一些动货的架构，然后多活的话呢，实际上我们这里是分为同多活和一笔多对同城多活的话，一般来说，其实我们这标就是说像做多活坐标找的那个那个那个阿里支付宝他们的肌肉，就我们从多活一般来说，我会把它往肌肉的一个上面去靠。

经有什么一个对我们这边是什么样的一个架构呢？就是说我们可以看下右边这个图。我们是有两个肉，嗯，这两个任务之间的话呢，它是，嗯，每个任务的请求的独流量都是请求到自己用的自身的，但是对于写流量是请求到这个机群的主库的，也就是说一个数据库的机群它会跨两个肉，主库在某其中的一个肉，而重库会分布在本身的肉和另外一个肉，而对于我们读流量的话呢，我们。

每个用的读流量会读自己用的重库，但是写流量需要进行一些跨解方，因为我们为什么叫做机肉呢，而且为什么叫做同城多活呢？因为我们在同城的情况下，我们认为我们的专线主城，我们的跨地方的代价不是那么的高，所以一般来说很多业务还是可以接受的，一般情况可能会对我们同城来说，我们这个机动呢，一般来说会在三毫秒左右，所以三毫秒对于一个业务请求来说，跨机方还不至于说不能接受啊，所以的话呢，在这种场景下的话呢，我们会。如果说我们一个机房出现了故障啊，先说我们的服务器，如果一个服务器级别出现故障，那么这时候实际上就这个就依赖我们高可能组件的切换，对我们高可能组件切换，然后如果是服务器主库出现了故障，那么切换重复去，如果重复出现故障，那么会自动通过我的爬去自动探活机制，自动进行降级，降到了其他的一个，其他的一个任务的一个重复上去，对。然后对于机房级别的故障的话呢，那么这时候我们又分为两种场景，一种场景就是说我们的一致性优先，比如说我们的一些呃，一些金融的，或者说我们一些支付类的一些场景，那么这时候的话呢，我们可能会会优先把我的我的数据一致性。

对于可用性的话，我可以短暂的要求他变降级为只读，对对于用户来说，可能我的钱我宁愿他不能的去写，也不让他去出现了一些读错的一些场景，或者说我的钱变少了，我给你转了一个账，然后我的钱丢了，但是用户所不能接受的，对，所以对于一次性的业务的话呢，我们会让他业务降低只读，但是不会去把主库强行切位，因为跨肉虽然说他他可以去，嗯达到很小的一个试验，但是我们跨动是做的一不负责，所以他不可能去保证事物100%的一致性，对。然后另外一种业务的话呢，就我们的可用性优先，比如说我们的一些视频或视频页，那么这时候对于绝大多数用户来说，我我更关注的是我能不能还能还能不能看。

而不是说我看到第十秒了，它一下子给我跳到第九秒，在机房的出现故障的时候，我们更多的时候是期望它的一个可能性，对那么这时候的话呢，我们就可以进行让它自动进行跨机房的切换，这也是我们高可能组件会做的事情，对，当一个机房的，当一个机房的那个嗯，节点全部失效的时候，那么这个它会去切到另外一个地方，对，然后的话呢，嗯，高空组件这一侧的话，这里倒没有去。这次讨论都没有去做一个详细的分享，因为我们高空组件的话也会有一些有一些嗯，不同机房之间的一些嗯，专线抖音的判断，因为高空组件既然你要做跨机房，因为业内做高空组件跨机房的，据我所了解并不是特别多，因为有一个问题，就是因为机房之间的网络专线可能会抖动，那么抖动这一侧如果说处理不好的话，它可能会导致你的高可能组件误器，对，所以我们高空能组件的话，也是做了很多一些一些改造啊，一些权衡，来去来去探测，发现它是一个灾难，它是一个专心的抖动的判断，对。

OK，然后的话，接下来就是我们地多多核的话呢，实际上就依赖于我们的一个双向同步组件DT了，因为多它的一般来说可能就是一些嗯，超过我们业务普通业务所能容忍的一个范围了，对OK，然后的话呢，对一罗喉的话呢，我们一般都是读写在本个本个单元内进行了闭环，他要求我们做很多事儿，其实印多活动话，远远它的架构远远不止这么一点，它需要前期业务层做很多一些单元化。业务单元化，流量单元化，数据单元化，这些东西都需要业务来去做，并且我们双向双向组件复制还需要一些我们的全局发号器的能力，就比如说我们因为我们进行双向同步，所以我们要一定要避免我的数据的双向回环，以及我的全局递增ID是不是，是不是，嗯，快到了，我们的递增是不是会出现冲突的现象，对，那么说我们需要引入一个全局发射器的这一服，对。

OK，然后的话，嗯，再往下就是我们应急的一些多货切流的一些预案，其实多货切流的话呢，整体的应急预案就是如果对于我们数据一次性的话，出于一次性要求比较高的业务的话呢，我们会做一些嗯进写的一些策略，但其实对于我们正常很多业务来说，可能用不上进写，我们对一次性对于我们的可用性要求会更高一些，对。OK，然后的话，对于嗯，一次性要求高的话，我们一般来说我们切入流程是这样的，就是首先我们从管控平台进行提交一个切流请求，然后的话呢，管播平台息发切入请求之后的话呢，我们的DTS组件又是我们的数据同步组件，会针对我们的同步数据打开一些流量实时同步同步的队列，因为这样会防止我们的一些流量因为机房切换中间的出现的一些中间态丢失掉。对另外一点就是说我们需要去进行一些单元的进写，便于我们后面的一些数据如果出现了异常，我们需要进行根据对列一些数据进行一些数据的校正以及修复，对，然后但我们单元开始进写之后的话呢，我们的DTS会检查复制的延迟，OK，如果说等到复制没有延迟的时候，那么这时候确认旧单元是不是还有流量，如果没有流量，OK，这时候我们就从上游进行一些切流，然后这时候确认OK没问题之后，然后再取消我们单元的进行，然后进行一些健康检查就术，对，这是我们一个切流的一个。

流程的一个减速。嗯，OK，然后再回来，回回到后面我们看我们对于一些典型的长期应用的一些策略，对于我们，嗯，点接素打满的话呢，这个其实对于我们数据库来说是一个非常正常的一个。一个正常的一个情况，对，然后一般来说手段就是说我去限制我的用户最大连接数，然后max connection性max user connection以及连接数，有时候它并不是因为用户发起的连接数真的那么多，而是因为我们的数据库请求变慢了。

再慢了，那么它处理的速度就下降了，那么就会造成我的速堆积，然后进进一步可能造成我连速打满，对。所以这时候的话呢，我们需要去根据各种不同的场景来去定位它是真的因为我们的科S突发增了很多，还是因为我们的数据库的性能变码，然后再去进行一些在一些不同的一些预案处理SOP的OK，第二点就是组成复制延迟。嗯，这种的话，一般来说就是说像我们刚刚说的，我们会有一些自动的一些自愈的手段来去处理这个事儿，如果说嗯，假设我们自己没有能处理掉，比如说我们刷盘降级了之后，它还是会出现延迟，那么时候我们可能会接入一些人工接入去处理去看，如果说真的是。出于一些，嗯，比如说这个实例，它出现了一些bug，对于我们，因为我我们用的版本在病因复制下，还是采过不少的病因复制的B，对会有这种情况，那么这时候最快的手段就是说我们进行切流，切到一个比较健康的一个层框上去，对，然后的话就是缓存计算，缓存计算的话，这一侧的话呢，实际上最更多的我们应该是在设计层面来去避免这个问题，比如说缓存机算的话，我们会有很多策略，比如说多级缓存，再或者说对于一些空缓存的一些预防策略，然后真的是达到DB这层啊，那我们能做的事情就是只能先扩容，扩容到一定程度我们承受不了的话，那么就限流，对，只有这么两种手段。

OK，接下来就是慢长导致雪崩，慢长导致雪崩的话，实际上嗯，这一侧的话呢，也是我们D最常遇到的一个问题，其实在雪崩的时候，对于DBA来说，最重要的一个能力是如何能去快速的去判断哪一个或者哪一类慢查询是根源。因为在血崩时候，很多你会你的漫长日志会出现很大的很很大的一个量，有可能会到达几十兆，或者说甚至说上百兆的一个慢长日志，那么这里面有各种各样的原先本来不慢的CQ也它会被影响的嘛，那么这时候的话呢，我们需要怎么去分析根源的话，我们这里也有一系列的一些自动去分析诊断的工具，它会根据我们的查询，嗯，C根据我们首先根据我们的CQ做一个指纹的一个归类，指纹归类之后的话呢，再对这类指纹的一个CQ平均响应时间，以及它的平均省的行数。

以及他在我的，他在我的那个呃，事务表中最先开始的时间，这些各种各样的因素来去共同进行一系列的判断，然后去容的帮我们去推荐出来我的这时候DB出现了问题，那么可能出现的因是哪一类C口。然后帮我们出现一些，帮我们再进行一些人工的，嗯决人工的辅助决策，对对我们来说这样去，这是我们最快的一个方案，不然如果说这是我们人才去分析，那么很可能一个活动一半的时间都会去处理这个事去了，我们需要是尽快的让我们的。让我们的嗯，系统能够帮我们去做一些把人工的一些经验，做出一些辅助的决策，让我们去人工更快的进行一些切入的预案，或者说一些其他预案的执行。

嗯，OK，然后接下来就是意外，意外宕机的话，实际上这点就没什么可说了，就是我们的一些我们的一些高空组件的能力，我们这边的话也是有自己自研的一些高空组件来去对我们进行一些嗯，对异常情况进行一些非over，对OK，然后接下来我们再看嗯，整个活动的流程，整个活动流程的话呢，嗯，在这里就会比较简单，如果你前期的工作做的都非常的好了，那么整个活动流程一般来说将会是。非常愉快的过程，对，像我们最近几次的话，我们活动基本上都是一边看直播，然后隔个半个小时一个小时去同步一下，我们当前的状态是否都正常，然后就OK了，然后的话呢，一般来说，我们会肯定需要一个整体的一个大盘去显，去显示我们的一些响应时间，我们的在线人数，我们的系统压力是不是是什么样，然后以及我们要根据这些这些数据来去做我们的下一步的决策判断。假如说。

在线人数它已经达到了我们的百，我们饱和度人数的80%，那么这时候我们就需要去进行下一步预测，预预预测决策，我们是不是要开始去扩容，对，以及我们的系统压力，是不是有出现什么异常问题，需要去调用我们更多的人力来去去迅速去处理这个问题，对然后一般来说我们都会带一个作战室，做一个保障作战室，对，因为这样的话呢，一个就是我们人的响应其实会非常的快，不用去通过我们的一些线上的聊天工具，直接马上搬几个电脑就坐在一起，就可以迅速把这个问题给最高效的处理掉，对，然后的话呢。嗯，接下来就是说我们对异常情况就假设，虽然我们前期做了很多各种各样的一些。呃，一些压测，各种各样的一些优化，但是意外它肯定是会发生的，在我们发生意外的时候，我们怎么去快速的处理，怎么快速去处理这些问题，其实也是是很有讲究的一个，对对于我们新手和老司机来说，其实在处理一些大大促或者说一些大型活动的时候，他的表现是非常不一样的，因为这我也见过很多新手和老司机，很多新手的话呢，他一般来说就是出现两种情况，一种就是说，哎，在重大活动面前，老板领导往后面一站，他可能马上就松了，他可能就就是他会，他会就是大脑已经不知道怎么做了，他可能就会。

大脑中一片空白，他平时能做的东西，他现在也做不出来了，这是一种情况，所以说我我觉得做DBA另另一个比较重要的一点就是说，一定要有强大的心理素质，因为你一定会出现那么一天的，不要存在侥人心里一定会存在那么一天的，你的背后站的是一堆老板，或者是一堆一堆领导，等着你赶紧把这个东西给我修好，就或者说这个数据丢了，你赶紧给我还原回来，对，一定会有这么一天的，一定要把自己的心理素质属性锻炼的比较强大，对，然后第二点就是说。

对于一些可能脱离了第一阶段的同学的话呢，他可能哎，我看到哎系统出出出问题了，然后就是我赶紧赶紧去分析，然后分析哎这个可能是那个问题，然后我赶紧分析那个问题，然后底层为什么会出现这个问题，我赶紧分析原因。但实际上的话呢，在我们真正的一场大型活动中出现异常情况，我们应该考虑的是我们应该怎么去快速的去止损，这就涉及到我们s re的一个系统的方法论，其实对我们，对我们B站来说，我们出现一场大大型事故的故障，或者说任意非活动期间出现了一场大型线上的故障，我们一定会有至少三个人来加入这场故障，DBA3个DBA来加入这个故障，第一个人他是会处理我们。眼前当前这个事物，这个事情他的嗯处理这个事情，对第一处理的他会进行一些嗯判断，然后处理第二个人的话呢，它对于一些决策性，比如说A判断出来，呃，我现在数据库出现了宕机，那我但是我的高空组件没有自动的切换，那这时候我应该怎么办，我是应该嗯，我是应该去嗯人工的切换掉，还是说去修我的高空组件去看什么原因，那么这个人第二个人呢，还会进行一些决策，因为他需要进行，他需要更更全局的一些思考的角度，他因为他还要去收集其他系统的一些信息，比如说宕机这个库，它影响到了我们的核心的一些用户在用的一些东西，那么这时候我们需要第一时间做出一些牺牲掉一些其他一些东西的一些决策，快速帮我们系统去恢复。

那么这时候对于排查故障那个人，他是没时间去跟各个系统进行交流以及沟通，然后说哎，你系统因为我的DB出现了什么问题没有，然后我应该去怎么做才是最最优的一个决策，对，所以一定要第二个人他去进行一些决策，他需要和外部进行一些。搞沟通，和周边系统的交流，我这个DB的出现在故障影响到什么东西，OK，然后第三个人的话呢，他一般来说会做什么事呢？他会进行一些信息的一些同步，因为我们所有的故障，一旦是出现了滴滴故障，那么还可能还会影响到很多环节，对于其他环节的一些人呢，就是比较明确的，还算算是比较清晰的，他们还算比较好发现的问题，哎，一眼看起来，哎是DB的问题，OK，好，那我们就赶紧联系DB看一下，就是有些系统的话，可能他就是不是那么的，如果不是那么完善，那么之后他第一反应，哎，我系统是不是我把系统给搞炸了，我是不是在发版什么东西导致的，那我赶紧去。

去重启我的应用，去修我的东西，然后这时候可能会把我的问题会越搞越复杂，所以第三个人他一定要对对外进行一个故障的通报，通通通报和同步对。告诉大家我哪个数据库出现了什么问题，然后我们正在做什么样的东西，然后预计大概可能会是需要是一个什么样的一个时间，然后现在以及有什么样的影响，对，让大家去同步到这些东西，所以这个S的方法论，所以说我们一定要去，嗯，在第一时间能够去把我们的问题去缩小，然后评估，然后去。

判，判断出来我当前应该去使用哪一种止损的方案是最优的。所以说在一个老司机再去出现这些问题的时候，永远第一时间就是去先去看他影响了哪些东西，然后再去判断我应该怎么去快速的去止损，而不是这时候去调查我的这个cos，我的根因是什么，一定是先去恢复我的系统，对所以问题定位方法论的话，这里的话也是我们会根据谷歌S的方法论来去进行一系列的一些理论加以实践，对然后这里的话一般来说就是通过自己的一些反复的。排查一些假设，排除这么一个过程，对，然后其实我们整体的B站来说，我们整体的DBA组也是在往s SE re的一个方向去转，或者DB re的个方向去转，就我们正常情况下可能会我们所有的DBA会有50%的时间用做一些安的处理，就我们会有个安廓池，然后每周的话呢，会有一半人进入到安池里面进行一些日常的运维的安，就是响应我们的研发的问题，有些人的话呢，是会处理一些我们嗯，我们的一些告警，对有些同学就是处理一些某一模块的研发反馈来问题，或者一些一些日常的需求，这。

然后另外50%的人的话呢，他会拿出来时间放在他的一些项目研发上，因为我们每个人，对我们的B站来说，我们的每一个高级级别都必须具备至少两种数据库的运维能力和一种语言的开发能力，就是我们有很多平台，包括我们的一些工具都是我们自己来去开发的，那么在他去非常库的时间，那么他就要进行这些这些事情的一些开发迭代，对，这也是我们整个B站的整个DB。它的一个转换的一个过程，对。OK，嗯，然后接下来最后就是我们活动之后的一个复盘，活动之后的一个复盘的话呢，嗯，一般来说就是我们会把我们的活动的监控数据给长期保留下来，然后嗯，比如说我们下次活动，上次活动假设是100个人的预估量，下次活动根据市场部的预计，我们可能会达到200个人，那么我们就可能会把上一次活动的一些监控数据给算出来，对比一下，假设我们100个人的时候，系统是一个什么样的水位评价，然后200个人我需要做一些什么样的初步的资源的协调判断，当然真正的真正的实际的数据肯定是会以我们的压测为准。

但我们会有一些初步的判断，在我们上一次活动多少人的时候出现了什么情况，以及上次我们出现什么异常情况，然后我们是不是需要进行一些调整，对，然后第二点的话就是根据数据分析本次活动的优点与不足，这是也是我们每一次活动之后必做的一项环节，我们每一个系统，每一个嗯组件都会出这么一个。活动的一个总结报告就对，不只是我们DB，包括我们的假如DB，然后或者说嗯，CDN，或者说是SRB，这些每一个组件都会出关于自己的一些在这种活动中我们做到哪些好的地方，以及我们哪些不足的地方，还有我们哪些可以优化的地方，这样的话就能去让我去在下一次的活动中能够挑战我们更大的一个流量。我们B站也是从一。