類似問(wèn)題也是電商等業(yè)務(wù)常見(jiàn)場(chǎng)景，而米大師的經(jīng)驗(yàn)是，除了通過(guò)架構(gòu)將支付系統(tǒng)按場(chǎng)景、業(yè)務(wù)、流量進(jìn)行解耦，利用云的彈性(和云的冗余資源池)，在活動(dòng)時(shí)快速自動(dòng)的部署業(yè)務(wù)服務(wù)器。并區(qū)分業(yè)務(wù)單元域(SET)部署，前置調(diào)度，做分流和異常隔離和緩存外，采用支持水平拆分的分布式架構(gòu)的數(shù)據(jù)庫(kù)。

因?yàn)閿?shù)據(jù)庫(kù)本身無(wú)法像邏輯層一樣做隔離請(qǐng)求，而將幾張大表水平拆分(分表)。能夠讓數(shù)據(jù)庫(kù)可以隨時(shí)橫向擴(kuò)展，因此平時(shí)只需要在性能方面預(yù)留一定冗余，確保偶發(fā)性小峰值并不影響整個(gè)數(shù)據(jù)庫(kù)性能。如果遇到可預(yù)見(jiàn)的超高峰值，例如年度大促、春節(jié)活動(dòng)等，由業(yè)務(wù)部門決定是否進(jìn)行水平擴(kuò)容。當(dāng)然，分布式數(shù)據(jù)庫(kù)的原來(lái)使得水平擴(kuò)容十分簡(jiǎn)單，而且通過(guò)自動(dòng)再均衡方案，擴(kuò)容可以僅影響集群中的少數(shù)節(jié)點(diǎn)，而其他節(jié)點(diǎn)可以在擴(kuò)容時(shí)仍然正常運(yùn)行不會(huì)受到影響。

熱點(diǎn)更新技術(shù)，從容應(yīng)對(duì)秒殺等場(chǎng)景：

“秒殺”場(chǎng)景下，大量的用戶在極短的時(shí)間內(nèi)請(qǐng)求少量商品。在數(shù)據(jù)庫(kù)中，一個(gè)商品是一行存儲(chǔ)，所以秒殺會(huì)導(dǎo)致大量的線程來(lái)競(jìng)爭(zhēng)InnoDB行鎖，當(dāng)并發(fā)度越高時(shí)等待的線程也會(huì)越多，導(dǎo)致TPS下降RT上升。這會(huì)導(dǎo)致什么問(wèn)題呢?要么秒殺時(shí)，搶購(gòu)一個(gè)商品但整個(gè)平臺(tái)出故障;要么就出現(xiàn)100個(gè)庫(kù)存賣出去105個(gè)等各類異常。

當(dāng)然，業(yè)內(nèi)也有一些從數(shù)據(jù)庫(kù)層面的解決方案，例如：把熱點(diǎn)商品放到單獨(dú)的熱點(diǎn)庫(kù)中;通過(guò)緩存系統(tǒng)(如Redis/消息隊(duì)列等)緩存熱點(diǎn)請(qǐng)求;或讓業(yè)務(wù)層將lastmodifytime修改的多條SQL合并減少update。

而騰訊熱點(diǎn)更新功能，是通過(guò)一個(gè)全局HASH表存儲(chǔ)有INSERT/UPDATE請(qǐng)求的熱點(diǎn)對(duì)象，制定熱點(diǎn)SQL請(qǐng)求過(guò)來(lái)時(shí)，先查找HASH表中有無(wú)對(duì)應(yīng)的熱點(diǎn)對(duì)象，有就獲取lock，會(huì)被阻塞;沒(méi)有該熱點(diǎn)對(duì)象，那么創(chuàng)建該熱點(diǎn)對(duì)象的方式進(jìn)行。這種方案通過(guò)簡(jiǎn)單擴(kuò)展SQL語(yǔ)法和參數(shù)，使得業(yè)務(wù)不改變架構(gòu)，僅需修改幾行SQL的情況下，便可以快速應(yīng)對(duì)秒殺等場(chǎng)景(原理如下圖)。當(dāng)然，配合緩存使用，可以進(jìn)一步為業(yè)務(wù)提高性能，減少擊穿的概率

根據(jù)測(cè)試，我們發(fā)現(xiàn)應(yīng)用和不應(yīng)用的熱點(diǎn)更新技術(shù)會(huì)的效果差異非常明顯(測(cè)試數(shù)據(jù)如下圖)。

故障是常態(tài)，重要的是如何應(yīng)對(duì)故障：

如果您的業(yè)務(wù)是規(guī)模比較大，那么無(wú)論是網(wǎng)絡(luò)、硬件、軟件或人為的故障都是難以避免。因此，數(shù)據(jù)庫(kù)系統(tǒng)必須做到以下幾點(diǎn)，才能盡可能小的影響業(yè)務(wù)

只有保障數(shù)據(jù)強(qiáng)一致了才能保證故障切換的時(shí)候數(shù)據(jù)不錯(cuò)不丟。

故障能不能影響全局，且盡量做到業(yè)務(wù)無(wú)感知。

支持同城雙活、兩地三中心等架構(gòu)

立體組合的監(jiān)控系統(tǒng)，能快速判斷故障，定位問(wèn)題。

必須要有風(fēng)險(xiǎn)控制策略等措施保證數(shù)據(jù)安全

而騰訊分布式數(shù)據(jù)庫(kù)DCDB發(fā)展了13年，早已默認(rèn)數(shù)據(jù)強(qiáng)同步復(fù)制，任何節(jié)點(diǎn)故障，只要是已應(yīng)答均可保證數(shù)據(jù)不錯(cuò)不丟。也可設(shè)置多種同步方案，不同的業(yè)務(wù)數(shù)據(jù)庫(kù)采用不同復(fù)制策略以求在業(yè)務(wù)邏輯和數(shù)據(jù)一致性之間平衡。

分布式架構(gòu)，也使得DCDB任意節(jié)點(diǎn)故障，并不會(huì)影響全局，且每個(gè)從節(jié)點(diǎn)都可用做只讀訪問(wèn)。在某些僅軟件故障的場(chǎng)景， DCDB的保持連接技術(shù)，可用軟件故障，確保邏輯層(TProxy)和數(shù)據(jù)庫(kù)連接不斷開(kāi)，且自動(dòng)重發(fā)失敗請(qǐng)求。此時(shí)業(yè)務(wù)是來(lái)說(shuō)，感受就是某個(gè)請(qǐng)求時(shí)間稍長(zhǎng);即使是數(shù)據(jù)庫(kù)事務(wù)，或自動(dòng)回滾，或直接報(bào)錯(cuò)，數(shù)據(jù)不會(huì)錯(cuò)亂的。

由于DCDB的設(shè)計(jì)之初就是應(yīng)用于騰訊內(nèi)部金融支付類業(yè)務(wù)，因此同城雙活、年底三中心對(duì)其來(lái)說(shuō)早已成熟，常用方案如下圖：

通過(guò)對(duì)系統(tǒng)從硬到軟、從模塊到流程、從系統(tǒng)升級(jí)到常規(guī)運(yùn)維的立體化監(jiān)控，并結(jié)合 “自愈”能力，可讓99%常見(jiàn)故障自動(dòng)解決，僅1%的故障需要人工干預(yù)，自動(dòng)化的流程極大提高了故障修復(fù)響應(yīng)效率。

當(dāng)然，DCDB也是騰訊首個(gè)將完整的信息安全要求和風(fēng)控體系做到整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)中的產(chǎn)品之一。包括業(yè)務(wù)和運(yùn)維系統(tǒng)，我們提供惡意打擊、稽核、實(shí)時(shí)風(fēng)控等能力;在數(shù)據(jù)庫(kù)層面，也提供了安全審核平臺(tái)，數(shù)據(jù)庫(kù)防火墻等一系列安全能力。

此外，成本控制是互聯(lián)網(wǎng)企業(yè)成功的要素之一，如果是采用商業(yè)數(shù)據(jù)庫(kù)，先互聯(lián)網(wǎng)這種體量成本將是天價(jià)。而采用基于開(kāi)源協(xié)議的分布式數(shù)據(jù)架構(gòu)DCDB和騰訊云服務(wù)，按需使用且無(wú)高昂的license費(fèi)用，將極大的節(jié)省業(yè)務(wù)使用數(shù)據(jù)庫(kù)成本。

目前，作為支撐了騰訊內(nèi)外超過(guò)100億以賬戶，200億以上的交易流水和海量的虛擬交易的數(shù)據(jù)庫(kù)，騰訊云分布式數(shù)據(jù)庫(kù)DCDB已經(jīng)廣泛應(yīng)用在銀行、保險(xiǎn)、理財(cái)、電商、O2O等核心系統(tǒng)中。

songjy