一、業(yè)務(wù)場(chǎng)景

在開(kāi)始講解之前，我先為大家介紹一下B站的業(yè)務(wù)場(chǎng)景。B站的業(yè)務(wù)大體上可以分為以下幾類(lèi)：

1、點(diǎn)播類(lèi)業(yè)務(wù)

點(diǎn)播類(lèi)業(yè)務(wù)就是大家經(jīng)常看的視頻以及稿件之類(lèi)相關(guān)的業(yè)務(wù)，這類(lèi)數(shù)據(jù)使用場(chǎng)景的特點(diǎn)有：

• 數(shù)據(jù)一致性要求較高
• 耗時(shí)敏感
• 流量大
• 可用性要求高

2、直播類(lèi)業(yè)務(wù)

直播類(lèi)業(yè)務(wù)對(duì)應(yīng)B站的S12、跨晚、拜年祭等，有以下幾個(gè)特點(diǎn)：

• 數(shù)據(jù)一致性要求較高
• 熱點(diǎn)數(shù)據(jù)，如S12的主播房間
• 平時(shí)流量中等，大型直播流量會(huì)呈現(xiàn)爆炸性增長(zhǎng)
• 可用性要求高

3、游戲類(lèi)業(yè)務(wù)

• 數(shù)據(jù)一致性要求較高
• 耗時(shí)敏感
• 流量大
• 可用性要求高

4、電商類(lèi)業(yè)務(wù)

如B站本身的會(huì)員購(gòu)，這類(lèi)業(yè)務(wù)的要求如下：

• 數(shù)據(jù)一致性要求較高
• 熱點(diǎn)數(shù)據(jù)，集中在秒殺場(chǎng)景及熱門(mén)番劇
• 平時(shí)流量中等，熱門(mén)番劇及商品會(huì)呈現(xiàn)爆炸性增長(zhǎng)
• 可用性要求高

5、支付類(lèi)業(yè)務(wù)

• 數(shù)據(jù)一致性要求極高
• 可用性要求高
• 流量不大

二、架構(gòu)演進(jìn)

介紹完B站的業(yè)務(wù)場(chǎng)景之后，接下來(lái)是B站整體數(shù)據(jù)庫(kù)的架構(gòu)演進(jìn)歷史。

1、1.0階段

1.0階段對(duì)于所有互聯(lián)網(wǎng)公司而言，其實(shí)都有類(lèi)似的架構(gòu)——簡(jiǎn)單的主從，所有流量集中在一個(gè)主庫(kù)上。另外，與以前使用的商業(yè)數(shù)據(jù)庫(kù)類(lèi)似場(chǎng)景——單實(shí)例多庫(kù)。這種架構(gòu)在公司剛起步的時(shí)候是比較方便的，便于業(yè)務(wù)的快速迭代，但是隨著流量的增長(zhǎng)，會(huì)出現(xiàn)以下幾個(gè)問(wèn)題：

1）單機(jī)的性能瓶頸

服務(wù)器的CPU、內(nèi)存、存儲(chǔ)的限制我們不可能一直垂直升級(jí)，從而出現(xiàn)了我們第一個(gè)架構(gòu)演進(jìn)的小版本——讀寫(xiě)分離和一主多從，此場(chǎng)景有兩個(gè)核心要求：

• 數(shù)據(jù)一致性要求較低
• 數(shù)據(jù)敏感度要求較低

滿足以上兩個(gè)要求的場(chǎng)景可以很好地規(guī)避因MySQL主從復(fù)制存在的延遲所帶來(lái)的問(wèn)題，同時(shí)又可以滿足業(yè)務(wù)快速增長(zhǎng)帶來(lái)的流量壓力。

2）各業(yè)務(wù)互相影響

隨著業(yè)務(wù)的發(fā)展，各個(gè)業(yè)務(wù)之間的互相影響推動(dòng)了我們架構(gòu)的第二個(gè)小版本出現(xiàn)——按照業(yè)務(wù)庫(kù)進(jìn)行遷移拆分。

基于讀寫(xiě)分離和業(yè)務(wù)庫(kù)維度的拆分還是無(wú)法避免各個(gè)功能模塊的互相影響。在這種情況下，架構(gòu)1.0階段的第三個(gè)小版本應(yīng)運(yùn)而生——基于業(yè)務(wù)的功能維度進(jìn)行拆分，將一個(gè)X庫(kù)拆分為n個(gè)庫(kù)，拆分完之后分布在不同的實(shí)例。在每個(gè)不同的實(shí)例下，我們會(huì)有不同數(shù)量的從庫(kù)支撐業(yè)務(wù)的流量增長(zhǎng)，以滿足大部分場(chǎng)景的業(yè)務(wù)需求。現(xiàn)在B站也有很多業(yè)務(wù)采用類(lèi)似的架構(gòu)，通過(guò)進(jìn)行垂直業(yè)務(wù)拆分滿足我們的業(yè)務(wù)增長(zhǎng)。

2、2.0階段

架構(gòu)2.0階段——水平拆分。成熟、穩(wěn)定、定制的Proxy是水平拆分的利器，而一個(gè)符合要求的Proxy是需要時(shí)間進(jìn)行打磨。為滿足業(yè)務(wù)的快速發(fā)展，我們選擇在業(yè)務(wù)層實(shí)現(xiàn)，也就是我們?cè)诖a層實(shí)現(xiàn)路由，雖然配置時(shí)會(huì)比較繁瑣，但能夠滿足大部分業(yè)務(wù)場(chǎng)景，很多互聯(lián)網(wǎng)公司也有類(lèi)似的階段。在業(yè)務(wù)側(cè)進(jìn)行水平拆分之后，我們其實(shí)面臨著一個(gè)新的問(wèn)題——跨實(shí)例查詢(xún)。

3、3.0階段

1）第一個(gè)階段

進(jìn)入B站演進(jìn)的3.0階段，我們引入了TiDB，將之前業(yè)務(wù)層面的分片數(shù)據(jù)通過(guò)TiDB本身的DTS同步到TiDB集群，從而滿足了大部分業(yè)務(wù)的查詢(xún)需求。同時(shí)我們?cè)诓糠謭?chǎng)景的業(yè)務(wù)下直接嘗試使用TiDB。

引入TiDB之后，基于B站的特點(diǎn)，我們對(duì)其進(jìn)行了本地化定制。由于TiDB Server是無(wú)狀態(tài)的，而官方對(duì)于如何路由到每個(gè)節(jié)點(diǎn)也沒(méi)有一個(gè)通用的解決方案。因此我們結(jié)合 B站的基礎(chǔ)平臺(tái)能力，將TiDB Server全部在PaaS上進(jìn)行容器化，同時(shí)把我們的服務(wù)發(fā)現(xiàn)能力和TiDB Server進(jìn)行整合，并對(duì)相應(yīng)語(yǔ)言的SDK進(jìn)行改造，從而實(shí)現(xiàn)了TiDB Server的負(fù)載均衡，解決了TiDB Server本身的瓶頸，如：故障切換、業(yè)務(wù)快速感知節(jié)點(diǎn)變化、連接數(shù)等。

2）第二個(gè)階段

到了3.0的第二個(gè)階段，我們已經(jīng)把Proxy打磨為一個(gè)很成熟的產(chǎn)品，同時(shí)為滿足支撐了異地多活的場(chǎng)景，我們還定制了DTS，把我們數(shù)據(jù)庫(kù)的部署從同城多活直接做到了異地多活，也就是兩地三中心的架構(gòu)。

首先，在DTS方面，我們也基于B站本身技術(shù)棧的特點(diǎn)做了大量的定制，與其它公司開(kāi)源的組件有部分不同。例如沖突檢測(cè)，我們提供了多種可選擇的規(guī)則，包括基于特定字段的以及全字段匹配的，同時(shí)對(duì)于沖突字段數(shù)據(jù)的R數(shù)據(jù)處理，我們一般會(huì)有兩種途徑：

• 一是直接沖突的場(chǎng)景，將不重要的數(shù)據(jù)直接打入到我們的隊(duì)列里，也就是我們公司之前的Data Bus里；
• 二是業(yè)務(wù)方可以基于打到Data Bus里的數(shù)據(jù)做沖突數(shù)據(jù)處理，通過(guò)DTS提供一個(gè)接口將數(shù)據(jù)回寫(xiě)到特定的機(jī)房，因?yàn)楫?dāng)需要把數(shù)據(jù)重新寫(xiě)入數(shù)據(jù)庫(kù)時(shí)，也是需要做防回環(huán)的處理，所以我們DTS上提供一個(gè)接口供業(yè)務(wù)使用。

其次，在主從切換的時(shí)候，由于兩地三中心要保證數(shù)據(jù)可以進(jìn)行來(lái)回切換，切換期間雖然是全局進(jìn)行，但是一些邊緣場(chǎng)景下仍然會(huì)存在數(shù)據(jù)沖突的問(wèn)題。所以我們也提供了一個(gè)在主從切換下數(shù)據(jù)沖突以及相關(guān)信息的打撈隊(duì)列，實(shí)現(xiàn)二次處理的功能，這也是我們中間 DTS提供的一個(gè)能力。

Proxy的能力與各家主流的功能是類(lèi)似的，都能夠支持讀寫(xiě)分離、分庫(kù)分表、限流、黑白名單等。對(duì)于Proxy的部署，我們采取了兩種方案：

• 一是集中式部署，類(lèi)似于大家常說(shuō)的網(wǎng)關(guān)模式，能夠便捷地進(jìn)行統(tǒng)一的限流及資源的調(diào)控；
• 二是Sidecar模式，應(yīng)用層在使用方面比較簡(jiǎn)單，直接配置本地IP即可，但是同時(shí)已帶來(lái)其他問(wèn)題，如全局的管控（限流、連接等）、成本等。

三、架構(gòu)設(shè)計(jì)

接下來(lái)為大家介紹的是B站對(duì)于不同數(shù)據(jù)量的場(chǎng)景的架構(gòu)設(shè)計(jì)理念。

1、大型直播活動(dòng)

整體概括起來(lái)有以下四種類(lèi)型：

1）高并發(fā)寫(xiě)入

高并發(fā)寫(xiě)入考驗(yàn)的是主庫(kù)的寫(xiě)入能力和從庫(kù)的復(fù)制能力。

2）高并發(fā)查詢(xún)

高并發(fā)查詢(xún)一般都會(huì)引入緩存的能力，緩存主要涉及以下幾種：

• 分布式緩存主要解決容量的問(wèn)題；
• Local Cache在應(yīng)用層提供能力，在應(yīng)用本地可以緩存部分?jǐn)?shù)據(jù)，但是數(shù)據(jù)可能存在不及時(shí)的問(wèn)題；
• 多級(jí)緩存能夠緩解爆炸性增長(zhǎng)的流量帶來(lái)的壓力。

3）實(shí)時(shí)排序

實(shí)時(shí)排序最直觀的場(chǎng)景就是觀眾在直播間刷禮物的時(shí)候展示出來(lái)的名次，為保證時(shí)效性以及順序，我們一般會(huì)采用Redis有序集合。

4）預(yù)期外突發(fā)流量

預(yù)期外突發(fā)流量對(duì)于我們而言考驗(yàn)的主要是應(yīng)用層的快速擴(kuò)容以及如何對(duì)流量進(jìn)行削峰，同時(shí)保證數(shù)據(jù)庫(kù)比較平穩(wěn)地寫(xiě)入，也就是異步寫(xiě)入的場(chǎng)景。今年最明顯的預(yù)期外突發(fā)流量場(chǎng)景是佩洛西事件，比我們平常的流量大了將近5倍。

2、電商大促

整體上歸納下來(lái)有以下幾個(gè)特點(diǎn)：

1）秒殺場(chǎng)景

秒殺場(chǎng)景主要涉及合適的選型和請(qǐng)求最簡(jiǎn)化。基于公司的基建進(jìn)行定制，才可以實(shí)現(xiàn)最好的性能和體驗(yàn)。

2）訂單

訂單有很明顯的冷熱數(shù)據(jù)特征。一般情況下，我們的訂單會(huì)被進(jìn)行一年前、兩年前以及實(shí)時(shí)訂單的不同拆分。這塊對(duì)于數(shù)據(jù)庫(kù)而言考驗(yàn)的是數(shù)據(jù)的歸檔及查詢(xún)能力。

3）庫(kù)存

庫(kù)存與秒殺場(chǎng)景存在一定關(guān)聯(lián)，但并不是完全相關(guān)。秒殺場(chǎng)景會(huì)涉及到庫(kù)存，但是庫(kù)存在平常也會(huì)一直使用，因此兩者不能進(jìn)行強(qiáng)掛鉤。

庫(kù)存場(chǎng)景主要在于保證減庫(kù)存的準(zhǔn)確性，以及減少用戶(hù)端在訪問(wèn)時(shí)可能存在的沖突，另外是一致性的問(wèn)題，也就是在秒殺和減庫(kù)存時(shí)不能出現(xiàn)超賣(mài)的情況，避免對(duì)商家造成虧本。

4）流量削峰

流量削峰與大型直播賽事遇到的突發(fā)流量是不同的，因?yàn)檫@一部分流量是我們已知的，已經(jīng)預(yù)估好會(huì)有多少流量，因此我們一般會(huì)進(jìn)行隊(duì)列處理以及做分層。

前面介紹了大型直播賽事和電商大促兩個(gè)典型場(chǎng)景，我們做了一部分?jǐn)?shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)以及與應(yīng)用端的聯(lián)動(dòng)。下面介紹我們真正進(jìn)行數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)時(shí)，需要考慮哪些關(guān)鍵點(diǎn)。

3、數(shù)據(jù)

首先需要考慮數(shù)據(jù)，按照我們數(shù)據(jù)類(lèi)型的使用場(chǎng)景，我們可以將數(shù)據(jù)分為以下三種：

1）配置型

配置型類(lèi)似于我們的數(shù)據(jù)字典以及一些權(quán)限配置，特點(diǎn)包括：

• 量小
• 幾乎無(wú)事務(wù)依賴(lài)
• 讀多寫(xiě)少

如果需要對(duì)配置型數(shù)據(jù)進(jìn)行高并發(fā)訪問(wèn)，只需要加緩存即可，不需要做過(guò)多處理。

2）日志型

日志型數(shù)據(jù)包括交易流水、訂單狀態(tài)等，我認(rèn)為日志型數(shù)據(jù)也可以稱(chēng)為流水型數(shù)據(jù)，特點(diǎn)包括：

• 量大：無(wú)法避免，因?yàn)槲覀冃枰涗浿虚g各部狀態(tài)；
• 無(wú)事務(wù)依賴(lài)：我們后續(xù)進(jìn)行的更多是查詢(xún)而很少更改；
• 寫(xiě)多讀少：讀的比例一般是寫(xiě)的幾十分之一。

3）狀態(tài)型

• 數(shù)據(jù)量：與業(yè)務(wù)有關(guān)，狀態(tài)型數(shù)據(jù)可以理解為我們的訂單，以及直播場(chǎng)景里刷禮物的扣減情況；
• 事務(wù)強(qiáng)依賴(lài)：必須保證用戶(hù)下單成功之后的庫(kù)存扣減，以及用戶(hù)給主播打賞之后平臺(tái)的扣減和主播收到的禮物；
• 讀多寫(xiě)多：與用戶(hù)的進(jìn)程掛鉤，寫(xiě)和讀的場(chǎng)景都比較多。

綜上所述，對(duì)于數(shù)據(jù)一般通過(guò)數(shù)據(jù)量、事務(wù)和讀寫(xiě)請(qǐng)求三個(gè)維度進(jìn)行判斷，從而對(duì)數(shù)據(jù)進(jìn)行規(guī)整和梳理，對(duì)比上述我列出的三種數(shù)據(jù)類(lèi)型，可以得出數(shù)據(jù)的特定類(lèi)型。有了數(shù)據(jù)類(lèi)型之后，我們就可以考慮進(jìn)行下一個(gè)階段，即業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)的要求。

4、業(yè)務(wù)

業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)選型的要求相對(duì)而言比較多，包括事務(wù)、性能、擴(kuò)縮容、高可用、遷移。

1）事務(wù)

對(duì)事務(wù)的要求需要基于數(shù)據(jù)類(lèi)型進(jìn)行判斷。

2）性能

一些業(yè)務(wù)對(duì)耗時(shí)比較敏感，也就是性能要求比較高，要求必須在多少毫秒以?xún)?nèi)將數(shù)據(jù)結(jié)果反饋回來(lái)。那么在進(jìn)行數(shù)據(jù)庫(kù)選型時(shí)，我們需要考慮該數(shù)據(jù)庫(kù)能否承載這么高的性能反應(yīng)。

3）擴(kuò)縮容

如果業(yè)務(wù)要上一個(gè)新業(yè)務(wù)，要考慮滿足一年至兩年的增長(zhǎng)的需求，因此數(shù)據(jù)庫(kù)的擴(kuò)縮容能力非常重要。如果之前申請(qǐng)的數(shù)據(jù)量比較大，但是業(yè)務(wù)發(fā)展沒(méi)有達(dá)到預(yù)期，那么數(shù)據(jù)庫(kù)需要縮容，所以這一方面對(duì)于數(shù)據(jù)庫(kù)選型也是有要求的。

4）高可用

高可用需要進(jìn)行取舍，如果要保證數(shù)據(jù)的強(qiáng)一致性，以及性能的穩(wěn)定性，必須舍棄一部分東西，具體要與業(yè)務(wù)溝通和協(xié)調(diào)，從而保證實(shí)際效果符合業(yè)務(wù)要求。

5）遷移

遷移不僅是業(yè)務(wù)代碼的改造，從A類(lèi)數(shù)據(jù)庫(kù)遷到B類(lèi)數(shù)據(jù)庫(kù)還需要考慮數(shù)據(jù)庫(kù)的遷移成本，以及能否支撐同構(gòu)和異構(gòu)。對(duì)于業(yè)務(wù)而言，業(yè)務(wù)更多考慮的是遷移帶來(lái)的業(yè)務(wù)改造成本，一般業(yè)務(wù)會(huì)比較喜歡協(xié)議無(wú)變更、基礎(chǔ)操作語(yǔ)法不變的平滑遷移。

5、數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)我們要考慮的關(guān)鍵點(diǎn)有：

1）事務(wù)

如果你想要強(qiáng)事務(wù)依賴(lài)，可以用傳統(tǒng)型數(shù)據(jù)庫(kù)，以及現(xiàn)有的NewSQL，比如TiDB、OceanBase等。如果不考慮事務(wù)，數(shù)據(jù)庫(kù)選擇會(huì)更多，比如Redis、MongoDB，主要取決于具體的使用場(chǎng)景和數(shù)據(jù)庫(kù)要承擔(dān)的能力。

2）性能

每一種數(shù)據(jù)庫(kù)的性能不同，以關(guān)系型數(shù)據(jù)庫(kù)和非關(guān)系型數(shù)據(jù)庫(kù)為例，MongoDB和MySQL兩者的性能差別是很大的，依然取決于數(shù)據(jù)庫(kù)要承擔(dān)的能力。

3）擴(kuò)縮容、高可用

擴(kuò)縮容和高可用不需要進(jìn)行過(guò)多的解釋?zhuān)驗(yàn)楦呖捎檬荄BA選擇數(shù)據(jù)庫(kù)的硬性要求。

4）遷移

這一部分的遷移與業(yè)務(wù)的遷移存在差異，業(yè)務(wù)的遷移主要考慮業(yè)務(wù)改造成本，數(shù)據(jù)庫(kù)的遷移需要考慮以下三點(diǎn)：

• 數(shù)據(jù)是否一致
• 數(shù)據(jù)遷移時(shí)是否有增量
• 數(shù)據(jù)遷移會(huì)對(duì)業(yè)務(wù)產(chǎn)生什么影響

如果業(yè)務(wù)允許直接一刀切，那么方案則比較簡(jiǎn)單；如果業(yè)務(wù)要求無(wú)損，那么如何評(píng)估方案也是需要大家進(jìn)行考量的。

5）備份/還原

如果可能出現(xiàn)數(shù)據(jù)需要恢復(fù)的場(chǎng)景，則必須考慮備份/還原的能力。我們一般會(huì)更傾向于做物理備份，因?yàn)槲锢韨浞葸€原比較快，但是一些數(shù)據(jù)庫(kù)沒(méi)有提供物理備份的能力，如MongoDB。Redis我們也不會(huì)做持續(xù)化的備份，因?yàn)闀?huì)導(dǎo)致性能的嚴(yán)重下降。

6）容災(zāi)

容災(zāi)是第一部分B站數(shù)據(jù)庫(kù)架構(gòu)演進(jìn)我們提到的兩地三中心和同城多活需要具備的一個(gè)能力。

7）穩(wěn)定性

數(shù)據(jù)庫(kù)的要求是能夠平穩(wěn)地對(duì)外提供服務(wù)，因此穩(wěn)定性非常關(guān)鍵。

8）成本

我們不可能為了保證性能無(wú)限地往數(shù)據(jù)庫(kù)里加機(jī)器，因?yàn)槌杀緯?huì)很高。同時(shí)需要考慮開(kāi)源數(shù)據(jù)庫(kù)和商業(yè)數(shù)據(jù)庫(kù)的選擇，在一定程度上商業(yè)數(shù)據(jù)庫(kù)的性能比同等規(guī)格的開(kāi)源數(shù)據(jù)庫(kù)更好，但是需要考慮維護(hù)成本和二次定制化能力的成本。

9）定制化

商業(yè)數(shù)據(jù)庫(kù)有時(shí)不會(huì)讓我們做更多的定制化開(kāi)發(fā)，但是這會(huì)給我們的上下游依賴(lài)帶來(lái)一個(gè)問(wèn)題，因?yàn)榇蟛糠謭?chǎng)景我們會(huì)依賴(lài)于類(lèi)似MySQL的binlog，下游的刷緩存能力以及大數(shù)據(jù)的實(shí)時(shí)數(shù)倉(cāng)能力都需要依靠binlog去往下游，也就是CDC能力。那么這一方面也是數(shù)據(jù)庫(kù)選型需要進(jìn)行評(píng)估的重要能力。

6、策略

1）多維度綜合考慮

數(shù)據(jù)庫(kù)架構(gòu)選型并不是從一個(gè)維度考慮的，每個(gè)數(shù)據(jù)庫(kù)有自身的使用場(chǎng)景和特點(diǎn)，因此數(shù)據(jù)庫(kù)架構(gòu)選型需要從多個(gè)維度綜合考慮，包括數(shù)據(jù)的維度、業(yè)務(wù)的真實(shí)訴求、DBA團(tuán)隊(duì)能提供的數(shù)據(jù)庫(kù)能力，以及公司對(duì)于數(shù)據(jù)庫(kù)的支撐能力，主要是公司其他團(tuán)隊(duì)如開(kāi)發(fā)和平臺(tái)類(lèi)支撐。

2）滿足未來(lái)三到五年需求

數(shù)據(jù)庫(kù)架構(gòu)例如擴(kuò)縮容能力，必須滿足未來(lái)3～5年的需求，而不是頻繁地迭代和更新，否則對(duì)業(yè)務(wù)而言是有損的。

3）穩(wěn)定為主

數(shù)據(jù)庫(kù)需要平穩(wěn)運(yùn)行，而不是天天宕機(jī)，因此數(shù)據(jù)庫(kù)架構(gòu)選型需要以穩(wěn)定為主。

上圖的右側(cè)是目前B站的數(shù)據(jù)庫(kù)團(tuán)隊(duì)使用的數(shù)據(jù)庫(kù)占比，可以看出：

• Redis、MySQL分別占比第一和第二；
• 占比第三的是MC，因MC無(wú)高可用，這一方面需要從業(yè)務(wù)層進(jìn)行設(shè)計(jì)，如MC異常后的回源能力；
• 其他數(shù)據(jù)庫(kù)相對(duì)數(shù)量較少。

總體來(lái)說(shuō)，B站的數(shù)據(jù)庫(kù)特點(diǎn)是Redis和MySQL為主，其它數(shù)據(jù)庫(kù)主要是基于我們的使用場(chǎng)景進(jìn)行選擇和提供。

四、穩(wěn)定性

今天主要是想向大家介紹B站萬(wàn)億級(jí)數(shù)據(jù)庫(kù)選型與架構(gòu)設(shè)計(jì)實(shí)踐，所以需要考慮數(shù)據(jù)庫(kù)如何提供穩(wěn)定性能力。

1、高可用

在提供穩(wěn)定性方面，主要是如何保證數(shù)據(jù)庫(kù)高可用。BRM是我們基于B站的業(yè)務(wù)特點(diǎn)自研的MySQL高可用組件，在該架構(gòu)上我們提供了兩個(gè)功能節(jié)點(diǎn)Leader和Follower，能夠?qū)簝?nèi)的所有節(jié)點(diǎn)進(jìn)行管理和探活。不管在哪個(gè)節(jié)點(diǎn)進(jìn)行注冊(cè)，我們都可以將其注冊(cè)到整個(gè)集群。因?yàn)閮?nèi)部有一個(gè)網(wǎng)關(guān)會(huì)把所有請(qǐng)求轉(zhuǎn)發(fā)到主節(jié)點(diǎn)，同時(shí)再分發(fā)到剩下的Follower節(jié)點(diǎn)上。

Leader和Follower都參與投票決策，用以規(guī)避因網(wǎng)絡(luò)抖動(dòng)問(wèn)題導(dǎo)致BRM誤判數(shù)據(jù)庫(kù)不可用，然后由Leader節(jié)點(diǎn)根據(jù)投票結(jié)果判斷該節(jié)點(diǎn)到底是否宕機(jī)。

整體概括起來(lái)，我們自研的BRM會(huì)有以下六個(gè)核心功能：

• 多節(jié)點(diǎn)部署：解決MHA單點(diǎn)風(fēng)險(xiǎn)；?

• 支持跨機(jī)房：跨機(jī)房部署解決因網(wǎng)絡(luò)異常引起的誤切風(fēng)險(xiǎn)；

• 支持權(quán)重：B站的數(shù)據(jù)庫(kù)有單機(jī)房、同城多活和異地多活,如何保證切到想要的節(jié)點(diǎn)上。通過(guò)對(duì)不同節(jié)點(diǎn)設(shè)置權(quán)重，實(shí)現(xiàn)類(lèi)似MongoDB一樣的基于權(quán)重的選主能力；

• 多節(jié)點(diǎn)投票決策：通過(guò)多個(gè)BRM節(jié)點(diǎn)對(duì)同一個(gè)實(shí)例探測(cè)，滿足多數(shù)節(jié)點(diǎn)一致才判定實(shí)例不可用；?

• 專(zhuān)線抖動(dòng)誤切預(yù)防：通過(guò)多機(jī)房多節(jié)點(diǎn)部署我們可以預(yù)防因?qū)＞€抖動(dòng)導(dǎo)致的主節(jié)點(diǎn)誤切，也可以避免跨機(jī)房專(zhuān)線異常造成的誤判；

• 熔斷機(jī)制：如果出現(xiàn)機(jī)房宕機(jī)的情況，我們可以先切一部分，查看故障發(fā)生的原因，確認(rèn)沒(méi)有問(wèn)題之后再把熔斷機(jī)制放開(kāi)。

2、預(yù)警

保證系統(tǒng)的平穩(wěn)運(yùn)行，也涉及到預(yù)警的能力。對(duì)于數(shù)據(jù)庫(kù)的預(yù)警，真正比較具有可預(yù)測(cè)性和可觀察性的是慢查詢(xún)。數(shù)據(jù)庫(kù)的CPU和IO之類(lèi)的也可以作為參考，但是會(huì)存在一定的誤判，所以我們的方案是針對(duì)慢查詢(xún)，并且做了一套慢查詢(xún)預(yù)警體系。

首先對(duì)于DB層的慢查詢(xún)，我們做了流式的采集上報(bào)和實(shí)時(shí)分析。在實(shí)時(shí)分析之后，可能會(huì)存在誤報(bào)的情況，因?yàn)槿绻涸诔B(tài)情況下，每天固定某個(gè)時(shí)刻都會(huì)出現(xiàn)比如100條慢查詢(xún)，那么此時(shí)是否該報(bào)，其實(shí)這本身是一個(gè)業(yè)務(wù)某個(gè)時(shí)間點(diǎn)的特定行為，不會(huì)影響整體行為，所以需要將其屏蔽。針對(duì)這一方面，我們引入多次線性回歸，通過(guò)多次線性回歸實(shí)現(xiàn)了對(duì)偶發(fā)性的抖動(dòng)的過(guò)濾，不同業(yè)務(wù)級(jí)別環(huán)比倍數(shù)、持續(xù)性增長(zhǎng)（未到閾值倍數(shù)，但持續(xù)增長(zhǎng)或存在）慢查詢(xún)的預(yù)警，并且基于規(guī)則引擎實(shí)現(xiàn)自定義處理。

3、Proxy

通過(guò)對(duì)Proxy的大量使用，我們可以實(shí)現(xiàn)針對(duì)某個(gè)數(shù)據(jù)庫(kù)、某個(gè)服務(wù)、某類(lèi)SQL指紋進(jìn)行攔截、限流、熔斷，以阻止某些異常流量打崩數(shù)據(jù)的場(chǎng)景，也可以做比較輕松狀態(tài)下的讀寫(xiě)分離。

我們也可以做多機(jī)房路由，將機(jī)動(dòng)架構(gòu)下的數(shù)據(jù)流量轉(zhuǎn)發(fā)到主庫(kù)，同時(shí)能夠動(dòng)態(tài)發(fā)現(xiàn)拓?fù)浣Y(jié)構(gòu)的變化，新增或刪除從庫(kù)以及節(jié)點(diǎn)的變化都比較易于發(fā)現(xiàn)。

同時(shí)我們可以去做更精細(xì)化的Sidecar模式，從而減少業(yè)務(wù)技術(shù)與能力，通過(guò)Sidecar模式使用Proxy，可以滿足大家在大量場(chǎng)景下的能力。

4、多活

多活是為了保證在一個(gè)機(jī)房掛掉之后，我們可以有另外的機(jī)房支撐這一方面的能力，我前面講到的Proxy、BRM以及DTS等都是用于滿足多活的訴求。通過(guò)多活我們可以保證最大能力的冗災(zāi)，同時(shí)對(duì)用戶(hù)的影響達(dá)到最小，當(dāng)一個(gè)機(jī)房掛掉之后，影響的用戶(hù)可能只有一部分，快速將用戶(hù)全部導(dǎo)流到另外一個(gè)機(jī)房可以為用戶(hù)提供平穩(wěn)的使用體驗(yàn)。

五、效率

最后是自動(dòng)化效率的問(wèn)題，不管是TiDB這種原生的分布式數(shù)據(jù)庫(kù)還是我們基于Proxy和業(yè)務(wù)層自研的分布式數(shù)據(jù)庫(kù)能力，同時(shí)比如Redis這種超大規(guī)模集群，我們現(xiàn)在經(jīng)常會(huì)超過(guò)Redis本身的上限，因gossip通信機(jī)制，如果節(jié)點(diǎn)數(shù)量過(guò)大會(huì)導(dǎo)致節(jié)點(diǎn)間的心跳請(qǐng)求將帶寬占滿，所以我們的自動(dòng)化如何提供效率？以下是自動(dòng)化運(yùn)維演進(jìn)的方向：

當(dāng)前我們?nèi)匀惶幱谧詣?dòng)化運(yùn)維的階段，自動(dòng)化平臺(tái)能力的核心有四個(gè)方面，分別是資源管理研發(fā)自助、運(yùn)維操作和風(fēng)險(xiǎn)管理。

自動(dòng)化運(yùn)維平臺(tái)

1、資源管理

資源管理簡(jiǎn)單理解就是資源如何進(jìn)行分配，有多個(gè)維度：

• 主機(jī)管理；
• Operator管理：無(wú)論是否上k8s都要提供Operator的管理能力；
• 資源池管理：涉及到如何提高機(jī)器使用度的問(wèn)題；
• 資源報(bào)表：涉及到賬單能力，通過(guò)賬單可以明確告訴業(yè)務(wù)哪個(gè)地方使用不合理，哪個(gè)成本可以節(jié)省，以及哪個(gè)架構(gòu)可以調(diào)整。

2、研發(fā)自助

日常情況下，研發(fā)有很多事情需要做，例如查詢(xún)、導(dǎo)入、加字段以及健康檢查等。資源申請(qǐng)指的是我們辦了一些比較簡(jiǎn)單的常規(guī)業(yè)務(wù)，他們可以基于我們前面講到的策略進(jìn)行匹配后選擇數(shù)據(jù)庫(kù)。到DBA審核的時(shí)候，我們會(huì)評(píng)估他們寫(xiě)入的內(nèi)容是否合理，保證不會(huì)出現(xiàn)由于架構(gòu)設(shè)計(jì)失敗引發(fā)重構(gòu)的問(wèn)題。

3、運(yùn)維操作

集群管理、實(shí)例管理和數(shù)據(jù)管理是一些比較日常的運(yùn)維操作，整體上由平臺(tái)化進(jìn)行支撐，大部分可以通過(guò)自動(dòng)化解決，不需要人工進(jìn)行管理。

4、風(fēng)險(xiǎn)管理

風(fēng)險(xiǎn)管理包括監(jiān)控與告警、健康度報(bào)表以及接入信息脫敏和存儲(chǔ)信息脫敏。B站涉及到電商和支付方面，需要對(duì)一些數(shù)據(jù)和用戶(hù)信息進(jìn)行大量的脫敏，通過(guò)數(shù)據(jù)掃描保證數(shù)據(jù)的合規(guī)。

以上就是我們自動(dòng)化平臺(tái)的能力。