隨著企業(yè)業(yè)務(wù)發(fā)展，以及微服務(wù)化大趨勢(shì)下單體服務(wù)的拆分，服務(wù)間的通信交互越來(lái)越多。與單體服務(wù)不同，微服務(wù)間的數(shù)據(jù)往往需要通過(guò)額外的手段來(lái)保障一致性，例如事務(wù)消息、異步任務(wù)補(bǔ)償?shù)?。除了從機(jī)制上最大程度保障以外，如何觀測(cè)并及時(shí)發(fā)現(xiàn)數(shù)據(jù)不一致也非常重要。

本文介紹 Shopee Financial Products 團(tuán)隊(duì)設(shè)計(jì)和開發(fā)的 實(shí)時(shí)核對(duì)系統(tǒng)（Real-time Checking System） ，它接入簡(jiǎn)單，只需根據(jù)核對(duì)需求配置對(duì)應(yīng)的核對(duì)規(guī)則，實(shí)現(xiàn)了規(guī)則熱加載，并能在不侵入業(yè)務(wù)的前提下對(duì)系統(tǒng)數(shù)據(jù)進(jìn)行實(shí)時(shí)監(jiān)測(cè)對(duì)比，及時(shí)發(fā)現(xiàn)數(shù)據(jù)的不一致。系統(tǒng)落地至今，已在 Shopee 多個(gè)產(chǎn)品線推廣使用，幫助不同團(tuán)隊(duì)快速發(fā)現(xiàn)線上數(shù)據(jù)不一致問(wèn)題，為數(shù)據(jù)保駕護(hù)航。

1. 背景

1.1 系統(tǒng)數(shù)據(jù)的不一致性

在日常的開發(fā)迭代中我們能發(fā)現(xiàn)，系統(tǒng)的數(shù)據(jù)有時(shí)并不按照我們?cè)O(shè)想的那樣進(jìn)行變更。常見(jiàn)的場(chǎng)景如：用戶進(jìn)行了還款（Repay），系統(tǒng) A 收到了還款請(qǐng)求后調(diào)用系統(tǒng) B，將已凍結(jié)的賬戶進(jìn)行解凍，但因?yàn)槟承┰颍ㄈ缦到y(tǒng)故障、網(wǎng)絡(luò)分區(qū)等），解凍的請(qǐng)求沒(méi)有抵達(dá) B，或者解凍成功的響應(yīng)沒(méi)有返回給 A，此時(shí)會(huì)出現(xiàn)已經(jīng)確定收款但未解凍，或未確認(rèn)收款卻已解凍的情況，從而引起用戶投訴或資金損失。

Fig1. Data Inconsistency

造成這類問(wèn)題的原因通常有：代碼邏輯 Bug、并發(fā)場(chǎng)景處理不當(dāng)、基礎(chǔ)組件（網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、中間件）故障、跨系統(tǒng)間缺乏原生的一致性保障等等。隨著業(yè)務(wù)擴(kuò)展，企業(yè)內(nèi)的應(yīng)用越來(lái)越多，且有許多 單體應(yīng)用 （Monolithic Application）向 微服務(wù) （Microservices）拆分轉(zhuǎn)型，分布式的場(chǎng)景下丟失了數(shù)據(jù)庫(kù)事務(wù)的支持，需要解決數(shù)據(jù)一致性的問(wèn)題。

保障數(shù)據(jù)一致的方案有很多種，在單體服務(wù)且缺少不同組件間（例如跨 Database、不同存儲(chǔ)中間件）事務(wù)支持的場(chǎng)景下，可以使用本地事務(wù)表 + 補(bǔ)償任務(wù)的組合，將主表數(shù)據(jù)與檢查任務(wù)通過(guò)事務(wù)寫入，再通過(guò)異步任務(wù)不斷檢查目標(biāo)數(shù)據(jù)是否一致并進(jìn)行補(bǔ)償，可實(shí)現(xiàn)最終一致性；在跨服務(wù)場(chǎng)景下，Saga 模式通過(guò)可靠消息及服務(wù)提供回滾事務(wù)的能力，來(lái)實(shí)現(xiàn)分布式事務(wù)。

但是，對(duì)于重要的業(yè)務(wù)，不管使用何種一致性方案， 提供額外的檢查、核對(duì)、兜底手段都是必要的 ，由此衍生出了很多的業(yè)務(wù)核對(duì)、對(duì)賬的需求。服務(wù)間通過(guò)特定手段保障數(shù)據(jù)一致性，并設(shè)計(jì)無(wú)侵入的旁路系統(tǒng)進(jìn)行數(shù)據(jù)核對(duì)和校驗(yàn)，是微服務(wù)架構(gòu)下的典型搭配。

Fig2. Data Consistency Insurance

1.2 離線核對(duì)的缺陷

常見(jiàn)的離線數(shù)據(jù)核對(duì)可以通過(guò)定時(shí)任務(wù)， 按照一定的篩選條件，從不同數(shù)據(jù)源中獲取特定數(shù)據(jù)，再進(jìn)行比較 。這種方案的偽代碼如：

func Check() {
    // 獲取上游 update_time 落在 [a, b) 的數(shù)據(jù)行
    upstreamRows := QueryUpstreamDB(a, b)

    for uniqueKey, sourceData := range upstreamRows {
        // 為每個(gè)上游數(shù)據(jù)查找對(duì)應(yīng)的下游數(shù)據(jù)
        targetData := QueryDownstreamDB(uniqueKey)

        // 對(duì)比上下游數(shù)據(jù)
        Compare(sourceData, targetData)
    }
}

時(shí)效性低是這類查表方案的通病。核對(duì)操作通常放在異步任務(wù)中定時(shí)執(zhí)行，執(zhí)行時(shí)間和離數(shù)據(jù)變更時(shí)間有一定延遲，且定時(shí)任務(wù)的查詢條件也會(huì)對(duì)核對(duì)目標(biāo)造成影響。當(dāng)出現(xiàn)異常數(shù)據(jù)時(shí)，不能及時(shí)發(fā)現(xiàn)問(wèn)題，只能等待下次定時(shí)任務(wù)執(zhí)行后才能發(fā)現(xiàn)。

引入了 額外的掃表開銷 同樣是個(gè)不容忽視的問(wèn)題。在數(shù)據(jù)量較大，尤其是存在大量 ??INSERT?? 操作的場(chǎng)景下，想要核對(duì)就需要 ??SELECT?? 出上下游的目標(biāo)數(shù)據(jù)。為了在不影響正常業(yè)務(wù)的情況下及時(shí)處理完核對(duì)任務(wù)，開發(fā)者可通過(guò)將查詢轉(zhuǎn)移到從庫(kù)，甚至引入核對(duì)任務(wù)獨(dú)占的從庫(kù)，但此類查表核對(duì)方案在資源使用和實(shí)現(xiàn)復(fù)雜度方面都不夠理想。

同時(shí)，由于查表得到的結(jié)果只是當(dāng)前的數(shù)據(jù)版本，在兩次檢查之間，數(shù)據(jù)可能發(fā)生了多次變更， 定時(shí)任務(wù)無(wú)法感知和觀測(cè)到每個(gè)狀態(tài)變更 ，在數(shù)據(jù)被頻繁 ??UPDATE?? 的場(chǎng)景下也存在一定的核對(duì)和檢測(cè)難度。

因此，要實(shí)現(xiàn)更好的數(shù)據(jù)核對(duì)，我們需要考慮以下幾點(diǎn)目標(biāo)：

• 實(shí)現(xiàn)秒級(jí)核對(duì)。
• 盡量減少數(shù)據(jù)庫(kù)查詢。
• 核對(duì)數(shù)據(jù)變更，而非核對(duì)數(shù)據(jù)快照。
• 簡(jiǎn)單靈活的接入方式。

2. 實(shí)時(shí)數(shù)據(jù)核對(duì)

為了更好地發(fā)現(xiàn)數(shù)據(jù)不一致的情況，Shopee Financial Products 團(tuán)隊(duì)在 2021 年中設(shè)計(jì)并實(shí)現(xiàn)了 Real-time Checking System （實(shí)時(shí)核對(duì)系統(tǒng)，RCS）。RCS 具有以下核心優(yōu)勢(shì)：

• 秒級(jí)數(shù)據(jù)核對(duì)。
• 對(duì)業(yè)務(wù)邏輯無(wú)侵入。
• 可配置化接入。

從上線至今，RCS 幫助團(tuán)隊(duì)及時(shí)檢測(cè)到了多次數(shù)據(jù)問(wèn)題，可以將原因歸納為以下幾個(gè)方面：

• 代碼邏輯 Bug：包括冪等處理、并發(fā)問(wèn)題、業(yè)務(wù)邏輯錯(cuò)誤等。
• 系統(tǒng)運(yùn)行環(huán)境：DB 異常、網(wǎng)絡(luò)抖動(dòng)、MQ 異常等。

Fig3. Types of spotted bugs

本節(jié)主要介紹 RCS 的實(shí)現(xiàn)，包括系統(tǒng)架構(gòu)和核對(duì)流程、核對(duì)性能優(yōu)化、消息通知機(jī)制等。

2.1 系統(tǒng)架構(gòu)與核對(duì)流程

在系統(tǒng)設(shè)計(jì)上，我們將 RCS 分為了三層：

• 變更數(shù)據(jù)獲?。―ata Fetching Layer）
• 數(shù)據(jù)核對(duì)（Data Checking Layer）
• 核對(duì)結(jié)果處理（Result Handling Layer）

Fig4. System Layers

2.1.1 變更數(shù)據(jù)獲取

實(shí)時(shí)核對(duì)，顧名思義需要著重關(guān)注“實(shí)時(shí)”和“核對(duì)”兩個(gè)要點(diǎn)。Data Fetching Layer 負(fù)責(zé)達(dá)成實(shí)時(shí)的目標(biāo)，通過(guò)對(duì)不同 CDC（Change Data Capture，變更數(shù)據(jù)抓?。┓桨傅恼{(diào)研，我們使用了 Log-Based 的方案來(lái)提供時(shí)效性保障。

擴(kuò)展閱讀

CDC 模式用于感知數(shù)據(jù)變更，主要可以分為以下 4 類：

• Timestamps，基于 update_time 或類似字段進(jìn)行查詢來(lái)獲取變更數(shù)據(jù)。
• Table Differencing，獲取完整數(shù)據(jù)快照進(jìn)行比對(duì)。
• Triggers，為 DDL、DML 設(shè)置 Trigger，將變更內(nèi)容用額外的操作記錄至數(shù)據(jù)庫(kù)。
• Log-Based，典型例子為利用 MySQL binlog 和 MongoDB oplog。

其中，Timestamps 方案和 Table Differencing 均由定時(shí)任務(wù)驅(qū)動(dòng)，時(shí)效性較弱。Timestamps 方案無(wú)法感知被刪除的數(shù)據(jù)，使用時(shí)需要由軟刪除代替；Table Differencing 方案彌補(bǔ)了這個(gè)缺點(diǎn)，但是多次獲取完整數(shù)據(jù)會(huì)讓整套方案顯得非常笨重。

Triggers 方案和 Log-Based 方案獲取到的均為數(shù)據(jù)變更而非數(shù)據(jù)快照，但 Triggers 感知后以特定的語(yǔ)句將其記錄下來(lái)，本質(zhì)上是一次寫操作，仍給數(shù)據(jù)庫(kù)帶來(lái)了額外的負(fù)擔(dān)。

當(dāng) MySQL 產(chǎn)生數(shù)據(jù)變更時(shí)，高可用的 binlog 同步組件會(huì)獲取到對(duì)應(yīng) binlog，并將其投遞至 Kafka 中，以此獲取變更數(shù)據(jù)的數(shù)據(jù)值用于核對(duì)。

Fig5. Data Fetching Layer

在實(shí)際使用中，需要核對(duì)的數(shù)據(jù)可能并非都存在于 MySQL 中，例如我們也需要核對(duì) MySQL 與 MongoDB 的數(shù)據(jù)、MySQL 與 Redis 的數(shù)據(jù)。為此，業(yè)務(wù)系統(tǒng)也可以通過(guò)自行投遞特定格式的 Kafka 消息來(lái)接入，從而保證接入的靈活性。

2.1.2 數(shù)據(jù)核對(duì)

Data Checking Layer 負(fù)責(zé)處理接收到的數(shù)據(jù)流，包括獲取特定的核對(duì)規(guī)則，接收到數(shù)據(jù)時(shí)進(jìn)行暫存或比對(duì)。RCS 對(duì) binlog 數(shù)據(jù)進(jìn)行抽象，提煉了一套通用的可配置化的核對(duì)規(guī)則。用戶只需要填寫對(duì)應(yīng)的規(guī)則，即可實(shí)現(xiàn)自助接入。規(guī)則定義示例如下：

Fig6. Config Example

不難想象，不同系統(tǒng)間數(shù)據(jù)的變更是有先后的，且變更的消息被 RCS 接收到也會(huì)有先后順序。因此，先抵達(dá)的數(shù)據(jù)需要被存儲(chǔ)下來(lái)作為后續(xù)比對(duì)的目標(biāo)，后抵達(dá)的數(shù)據(jù)則按照規(guī)則與已有數(shù)據(jù)進(jìn)行比對(duì)。

Fig7. Check Flow

為了便于描述，這里先定義幾個(gè)名稱：

• 數(shù)據(jù)上游：先到達(dá) RCS 的數(shù)據(jù)為上游。
• 數(shù)據(jù)下游：后到達(dá) RCS 的數(shù)據(jù)為下游。
• 核對(duì)項(xiàng)：某個(gè)數(shù)據(jù)核對(duì)需求，包括上游數(shù)據(jù)和下游數(shù)據(jù)。例如：System A 與 System B 核對(duì)用戶資金狀態(tài)的需求。

Fig8. Kafka Data Check Flow

以下面這一次核對(duì)為例，它需要判斷數(shù)據(jù)是否在 10 秒達(dá)成一致，整體的核對(duì)流程可以簡(jiǎn)要描述為：

比對(duì)數(shù)據(jù)到達(dá)，進(jìn)行核對(duì)，并刪除 Redis key；

比對(duì)數(shù)據(jù)未到達(dá)，判斷延遲隊(duì)列中的數(shù)據(jù)。

• （圖 8）核對(duì)項(xiàng)的上游數(shù)據(jù)到達(dá)，暫存 Redis 和延遲隊(duì)列。
• （圖 8）RCS 等待核對(duì)項(xiàng)的下游數(shù)據(jù)：
• （圖 9）延遲隊(duì)列到達(dá)時(shí)間后，再次查詢?cè)?Redis 中是否有對(duì)應(yīng)數(shù)據(jù)：
• 存在，則超過(guò)核對(duì)時(shí)間閾值，發(fā)送異常告警，刪除 Redis key；
• 不存在，則已核對(duì)。

Fig9. DelayQueue Check Flow

2.1.3 消息通知機(jī)制

RCS 的目標(biāo)是及時(shí)發(fā)現(xiàn)數(shù)據(jù)不一致的問(wèn)題，因此，在 Result Handling Layer 中接入了 Shopee 企業(yè) IM（SeaTalk）的機(jī)器人進(jìn)行告警。未來(lái)告警接口也會(huì)進(jìn)行開放，便于擴(kuò)展和讓其它消息應(yīng)用進(jìn)行接入。

我們?cè)O(shè)計(jì)了四種消息通知機(jī)制：

• Mismatch Notice
• Aggregated Notice
• Recovery Notice
• Statistical Notice

Mismatch Notice 應(yīng)對(duì)一般場(chǎng)景下的核對(duì)失敗，及時(shí)通知到對(duì)應(yīng)的業(yè)務(wù)負(fù)責(zé)人，便于快速定位問(wèn)題原因并修復(fù)數(shù)據(jù)。但當(dāng)大量數(shù)據(jù)出現(xiàn)不一致時(shí)，Aggregated Notice 會(huì)取而代之，將告警進(jìn)行聚合發(fā)送，避免影響到值班人員的正常閱讀。

RCS 也會(huì)將核對(duì)失敗的數(shù)據(jù)持久化，因而具備恢復(fù)感知的能力。當(dāng)異常數(shù)據(jù)恢復(fù)時(shí)，Recovery Notice 會(huì)發(fā)送消息告知使用者何種不一致已經(jīng)恢復(fù)，間隔了多少時(shí)間。

最后，Statistical Notice 會(huì)向使用者報(bào)告常規(guī)的統(tǒng)計(jì)數(shù)據(jù)，包括 DB 主從延遲、當(dāng)日核對(duì)成功率等。

2.2 核對(duì)功能演進(jìn)

系統(tǒng)上線至今，接入或自行部署使用 RCS 的團(tuán)隊(duì)越來(lái)越多，對(duì)應(yīng)的業(yè)務(wù)場(chǎng)景也各不相同，早期的核對(duì)規(guī)則難以滿足不同團(tuán)隊(duì)的核對(duì)需求。在 2021 年末，Shopee Financial Products 研發(fā)團(tuán)隊(duì)又對(duì) Data Checking Layer 進(jìn)行了一系列的擴(kuò)展，目的是減少維護(hù)成本，以較為通用的方式支持不同團(tuán)隊(duì)的使用。

2.2.1 等值 / 映射核對(duì)

在最早上線的版本中，RCS 系統(tǒng)包含了等值和狀態(tài)映射核對(duì)的功能，是針對(duì)組內(nèi)實(shí)際面臨的場(chǎng)景設(shè)計(jì)的，滿足日常的使用需求。

核對(duì)系統(tǒng)主要處理的是上下游系統(tǒng)之間金額數(shù)值、狀態(tài)的變化，通常我們能獲取到的 binlog 核心字段示例和核對(duì)邏輯如下：

Fig10. Equivalence Check

假設(shè)先接收到 System A 的 binlog 消息，暫存 Redis，規(guī)定時(shí)間內(nèi)也接收到了 System B 的 binlog 消息：

??loan_amount?? 為 200，需要找到一條對(duì)應(yīng)的 System A 的 binlog，且 ??order_amount?? 需與之匹配；

??loan_status?? 為 4，需要找到一條對(duì)應(yīng)的 System A 的 binlog，且 ??order_status?? 需為 2。

• 根據(jù) System B 這條 binlog 的特征，發(fā)現(xiàn)配置有兩條核對(duì)規(guī)則：

對(duì)于不同系統(tǒng)間產(chǎn)生的單條記錄變更的核對(duì)，等值和映射檢查能覆蓋到大部分場(chǎng)景。但是因?yàn)檫@兩種核對(duì)的邏輯都是固定下來(lái)的，所以業(yè)務(wù)方如果有不同的核對(duì)需要，則需要新的代碼邏輯實(shí)現(xiàn)。為此，研發(fā)團(tuán)隊(duì)考慮 將核對(duì)邏輯交給使用方來(lái)描述 ，因而催生出了表達(dá)式核對(duì)的功能。

2.2.2 表達(dá)式核對(duì)

如果我們考慮以下的 binlog 示例，不同系統(tǒng)間的數(shù)據(jù)模型設(shè)計(jì)并不一致，字段非一一對(duì)應(yīng)。

Fig11. Expression Check

System A 記錄了 訂單的金額為 100 ，而 System B 記錄了訂單的 已支付金額為 30，借貸金額為 70 ，需要核對(duì)的是 System A ??order_amount?? 是否等于 System B ??paid_amount + loan_amount?? ，原有的設(shè)計(jì)無(wú)法支持。

為此，我們引入了表達(dá)式求值的方案，當(dāng) binlog 抵達(dá)時(shí)， 使用方通過(guò)一個(gè)返回值為布爾類型的表達(dá)式來(lái)描述自己的核對(duì)邏輯 ，如：

??a.order_amount == b.loan_amount??

??a.order_status == 2 && b.loan_status == 4??

• 判斷 2.2.2 中求和場(chǎng)景： ??a.order_amount == b.paid_amount + b.loan_amount??
• 兼容判斷 2.2.1 中場(chǎng)景：

在表達(dá)式核對(duì)方案下，兩個(gè)系統(tǒng)間的幾乎所有的單條數(shù)據(jù)核對(duì)場(chǎng)景都能進(jìn)行覆蓋，且這種方案的好處在于研發(fā)團(tuán)隊(duì)不用再費(fèi)心思提供新的計(jì)算、映射、與或非邏輯實(shí)現(xiàn)的支持，大大減少了維護(hù)成本。

2.2.3 動(dòng)態(tài)配置數(shù)據(jù)核對(duì)

在電商和金融的場(chǎng)景中，存在一些動(dòng)態(tài)數(shù)據(jù)，例如費(fèi)率、活動(dòng)優(yōu)惠折扣等，會(huì)隨著業(yè)務(wù)和運(yùn)營(yíng)計(jì)劃發(fā)生實(shí)時(shí)變化。這類數(shù)據(jù)通常存儲(chǔ)在配置表中，因此通過(guò)簡(jiǎn)單的表達(dá)式無(wú)法進(jìn)行定義，而不同業(yè)務(wù)系統(tǒng)中的配置表結(jié)構(gòu)設(shè)計(jì)也不一樣，很難在核對(duì)系統(tǒng)代碼中進(jìn)行聲明。

為了滿足這種場(chǎng)景，RCS 引入了對(duì)業(yè)務(wù)系統(tǒng) SQL 查詢的支持，當(dāng)獲取到新的 binlog 時(shí)，檢查這條 binlog 滿足的核對(duì)規(guī)則，使用方在核對(duì)規(guī)則中會(huì)配置需要執(zhí)行的 SQL 語(yǔ)句，以及分庫(kù)分表規(guī)則，由核對(duì)系統(tǒng)執(zhí)行并得到比對(duì)的內(nèi)容，再進(jìn)行表達(dá)式核對(duì)：

• binlog 中獲取到當(dāng)前訂單的費(fèi)率 ??order_rate?? 為 0.5。
• 根據(jù)配置信息執(zhí)行 ??SELECT?? 語(yǔ)句查詢實(shí)時(shí)的費(fèi)率 ??rate?? 。
• 執(zhí)行表達(dá)式核對(duì) ??a.order_rate == rate?? 。

除此之外，RCS 也能支持 JSON 串核對(duì)，譬如 System A 需要核對(duì) ??order_rate?? ，但是存儲(chǔ) ??order_rate?? 信息是一個(gè) JSON 串， ??rate_info = {"decimal_base":"10000", "order_rate":"0.5"}?? ?？梢栽?RCS 的核對(duì)規(guī)則中，自定義 JSON 解析表達(dá)式，提取真實(shí)需要核對(duì)的字段。

3. 性能表現(xiàn)

RCS 系統(tǒng)的性能主要取決于 Data Fetching Layer 和 Data Checking Layer。

Data Fetching Layer 的性能代表實(shí)時(shí)獲取變更數(shù)據(jù)的能力，受 binlog 解析（CPU 密集型任務(wù)）及 Kafka 的消息持久化（I/O 密集型任務(wù)）影響。 業(yè)務(wù)團(tuán)隊(duì)可根據(jù)需要選擇對(duì)應(yīng)的硬件搭建 CDC 模塊 ，以我們使用場(chǎng)景為例，每秒可投遞的消息數(shù)量超過(guò) 20K 。

Data Checking Layer 則負(fù)責(zé)進(jìn)行數(shù)據(jù)核對(duì)，為了測(cè)試 RCS 的性能極限，Data Fetching 采用 Kafka 發(fā)送源數(shù)據(jù)，核對(duì)系統(tǒng)采用單機(jī)部署。測(cè)試結(jié)果表明， RCS 每秒可完成核對(duì) 10K+ 次 ，詳細(xì)數(shù)據(jù)如下：

從壓測(cè)結(jié)果分析，RCS 的性能瓶頸主要取決于 Redis 集群的性能，單次核對(duì)耗時(shí)約為 0.5ms。當(dāng)然，RCS 支持集群部署，做為 Kafka 的消費(fèi)者，可以利用 Kafka consumer group 的 Rebanancing 機(jī)制，從而實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)/縮容的機(jī)制。

4. 總結(jié)

Shopee Financial Products 團(tuán)隊(duì)在 2021 年落地的 RCS 目前在多個(gè)產(chǎn)品線推廣和使用，主要解決傳統(tǒng) T+1 式離線數(shù)據(jù)核對(duì)延遲高、業(yè)務(wù)耦合緊密，且隨新業(yè)務(wù)上線還帶來(lái)額外的開發(fā)負(fù)擔(dān)的問(wèn)題。

RCS 通過(guò)靈活的核對(duì)規(guī)則配置化、表達(dá)式場(chǎng)景覆蓋以及 Log-Based 的 CDC 方案，提供近實(shí)時(shí)的數(shù)據(jù)核對(duì)解決方案，最大程度地降低數(shù)據(jù)不一致導(dǎo)致的資金、信息安全等風(fēng)險(xiǎn)。我們也歡迎不同的用戶和團(tuán)隊(duì)接入或部署使用，在后續(xù)的更新迭代中，RCS 會(huì)進(jìn)一步提升核對(duì)的性能，以支撐業(yè)務(wù)量增長(zhǎng)帶來(lái)的核對(duì)需求。

本文作者

Yizhong、Songtao，后端研發(fā)工程師。來(lái)自 Shopee Financial Products 團(tuán)隊(duì)。

Jiekun，后端研發(fā)工程師，熱衷于分布式系統(tǒng) & Kubernetes。來(lái)自 Shopee Off-Platform Ads 團(tuán)隊(duì)。