跨城實(shí)踐中，騰訊如何應(yīng)用 Apache Pulsar

本篇文章為大家展示了跨城實(shí)踐中，騰訊如何應(yīng)用 Apache Pulsar，內(nèi)容簡明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

平臺(tái)承載了公司每天數(shù)億收入大盤，為 180+ 個(gè)國家（地區(qū)）、萬級(jí)業(yè)務(wù)代碼、100W+ 結(jié)算商戶提供服務(wù)，托管賬戶總量 300 多億，是一個(gè)全方位、一站式計(jì)費(fèi)平臺(tái)。

作為一個(gè)千億級(jí)在線支付平臺(tái)，騰訊計(jì)費(fèi)（米大師）需要在以下方面進(jìn)行重點(diǎn)優(yōu)化和升級(jí)。

計(jì)費(fèi)場景要求不能丟掉任何數(shù)據(jù)，這是最基本的訴求。畢竟屬于金融資產(chǎn)類，雖然有的是虛擬賬戶，但還是用真金白銀進(jìn)行交易的。通過提取 SQL 來保證數(shù)據(jù)層面高可靠性、高一致性。

平臺(tái)的操作流程跟一些電商平臺(tái)的支付流程有些相似，即加入購物車、下單、發(fā)貨。不同的是，大多數(shù)電商平臺(tái)需要用戶自己手動(dòng)參與這些流程，而騰訊計(jì)費(fèi)則是用戶在后臺(tái)點(diǎn)擊便可自動(dòng)完成。

尤其是對(duì)于一些免付費(fèi)的項(xiàng)目，對(duì)整體可用性會(huì)有更高的要求。需具備容災(zāi)能力，在異常情況下能夠自動(dòng)修復(fù)。

在邏輯層面，因?yàn)檎麄€(gè)系統(tǒng)覆蓋 300 多個(gè)不同的業(yè)務(wù)產(chǎn)品，在面臨海量增長的數(shù)據(jù)時(shí)，對(duì)性能的穩(wěn)定性就有著極高的需求。

對(duì)于騰訊業(yè)務(wù)的量級(jí)情況，在容災(zāi)的效果期望上至少是城市級(jí)別的。在騰訊內(nèi)部有上萬個(gè)業(yè)務(wù)，這些業(yè)務(wù)部署在各地，計(jì)費(fèi)平臺(tái)的服務(wù)基本是部署在深圳和上海兩個(gè)地方。在這里就需要提供「異地多活」的服務(wù)。

當(dāng)然在多數(shù)情況下，我們會(huì)保持在同城部署服務(wù)。在進(jìn)行業(yè)務(wù)請(qǐng)求時(shí)，選擇就近的網(wǎng)關(guān)，可以減少不必要的情況。當(dāng)然異地情況下，也要保證快速切換的狀態(tài)。

在容災(zāi)層面，按照地域可以分為「同城多活」和「異地多活」。在邏輯層面，兩種狀態(tài)下都比較容易操作，比較困難地是在數(shù)據(jù)層面。

同城多活狀態(tài)下，在數(shù)據(jù)層會(huì)有多個(gè)副本構(gòu)成，采用跨機(jī)房或 IDC 部署。如果出現(xiàn)問題，可以立即切換到其他機(jī)房/IDC 進(jìn)行部署，達(dá)到無損切換。雖然這種方式操作比較簡單，但是它避免不了跨城市之間、一些極端情況的出現(xiàn)。

異地多活情況下，在部署方面就需要跨城多地進(jìn)行。當(dāng)一個(gè)城市的服務(wù)器宕機(jī)時(shí)，另一個(gè)城市可以繼續(xù)支撐產(chǎn)品，來減少損失。

但是想要做到完全無損是非常困難的，除非是每一步操作后都同步到異地并操作成功，才能保證任何時(shí)刻數(shù)據(jù)都是一致的。但是這樣性能方面，效率就大大下降了。

在整體性的表現(xiàn)上，異地多活更適用于騰訊計(jì)費(fèi)的產(chǎn)品模式。

>> 異地單活與異地多活

在之前，騰訊計(jì)費(fèi)采用的是異地單活的模式。當(dāng)時(shí)的業(yè)務(wù)沒有現(xiàn)在這么多元復(fù)雜，大部分請(qǐng)求都在主城市/主數(shù)據(jù)庫完成。對(duì)于數(shù)據(jù)庫的讀取，可以根據(jù)不同產(chǎn)品的不同需求，在主城或備城讀取。

這種架構(gòu)的好處是，數(shù)據(jù)是強(qiáng)一致性的，不會(huì)出錯(cuò)，因?yàn)樗械臄?shù)據(jù)都是集成在同一地方去寫入。缺點(diǎn)就是一旦出現(xiàn)城市級(jí)網(wǎng)絡(luò)災(zāi)難，就沒有設(shè)備進(jìn)行寫入操作。

隨著騰訊業(yè)務(wù)的擴(kuò)展和豐富，異地多活成為必然的選擇，用來提供高質(zhì)量、高穩(wěn)定的服務(wù)。這就涉及到兩個(gè)數(shù)據(jù)中心的同步問題。

目前業(yè)界主流的是 CDC 異步模式，可以通過消息隊(duì)列來應(yīng)用到消息層面。不僅可以利用 MQ 的海量堆積能力來存放操作流水，還可以利用多消費(fèi)處理能力來支撐數(shù)據(jù)復(fù)制的效率。

對(duì)于 MQ 的部署，同樣也可以采用同城或者跨城的部署。

同城：在 DB 中心單獨(dú)部署一個(gè) MQ 集群。生產(chǎn)時(shí)，在同城的 MQ 進(jìn)行，消費(fèi)時(shí)，則交叉地進(jìn)行數(shù)據(jù)讀取。這樣做的好處是生產(chǎn)效率高，缺點(diǎn)是消費(fèi)時(shí)需要進(jìn)行跨省訪問，本身不具備「跨省」的能力。

跨城：MQ 采用同城部署，具備跨省能力，能夠進(jìn)一步減少數(shù)據(jù)丟失。缺點(diǎn)是生產(chǎn)配置時(shí)，需要進(jìn)行跨城市的數(shù)據(jù)調(diào)用，以及消費(fèi)副本需要綁定在多地。

日常使用中多采用第二種方式，因?yàn)樾枰M可能減少數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

所以騰訊計(jì)費(fèi)系統(tǒng)對(duì)分布式消息隊(duì)列的要求如下：

• 一致性要求：計(jì)費(fèi)場景要求數(shù)據(jù)一條不能丟，這是最基本的訴求。

• 高可用要求：需具備容災(zāi)能力，在異常情況下能夠自動(dòng)修復(fù)。

• 海量存儲(chǔ)需求：在移動(dòng)互聯(lián)網(wǎng)時(shí)代，產(chǎn)生大量的交易數(shù)據(jù)，需要具備海量堆積能力。

• 快速響應(yīng)要求：在億級(jí)支付場景下，要求 MQ 能提供平滑的響應(yīng)時(shí)間，盡可能控制在 10ms 內(nèi)。

 

因?yàn)橹蛔x broker 和 broker 是采用隔離部署的，需要去把 topic 元數(shù)據(jù)從寫入的 broker 上同步過來，這樣就知道 topic 對(duì)應(yīng)的 ledger 集合有哪些，就可以分辨數(shù)據(jù)讀取了。

2. 如何讀取最近的數(shù)據(jù)？

上述內(nèi)容就是跨城實(shí)踐中，騰訊如何應(yīng)用 Apache Pulsar，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。