偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

數(shù)據(jù)一致性檢測的應(yīng)用場景與實(shí)踐

大數(shù)據(jù)
隨著業(yè)務(wù)規(guī)模的擴(kuò)張,企業(yè)系統(tǒng)變得越來越復(fù)雜,在這種復(fù)雜的分布式系統(tǒng)架構(gòu)下,難免會(huì)出現(xiàn)遠(yuǎn)程調(diào)用失敗,消息發(fā)送失敗,并發(fā) bug 等等問題,這些問題最終會(huì)導(dǎo)致系統(tǒng)間的數(shù)據(jù)不一致,導(dǎo)致用戶體驗(yàn)受損,用戶利益受損,對平臺來說就是產(chǎn)生資損。

 [[283136]]

隨著業(yè)務(wù)規(guī)模的擴(kuò)張,企業(yè)系統(tǒng)變得越來越復(fù)雜,在這種復(fù)雜的分布式系統(tǒng)架構(gòu)下,難免會(huì)出現(xiàn)遠(yuǎn)程調(diào)用失敗,消息發(fā)送失敗,并發(fā) bug 等等問題,這些問題最終會(huì)導(dǎo)致系統(tǒng)間的數(shù)據(jù)不一致,導(dǎo)致用戶體驗(yàn)受損,用戶利益受損,對平臺來說就是產(chǎn)生資損。因此如何持續(xù)保障系統(tǒng)的業(yè)務(wù)穩(wěn)定性對于企業(yè)來說是一個(gè)很重要的課題,本文旨在介紹一些常見業(yè)務(wù)應(yīng)用場景下的業(yè)務(wù)數(shù)據(jù)一致性保障最佳實(shí)踐。

離線or在線,事前or事后

應(yīng)對業(yè)務(wù)數(shù)據(jù)不一致問題的常規(guī)操作是,配置定時(shí)任務(wù),在每個(gè)固定時(shí)間點(diǎn)去拉取歷史一段時(shí)間的數(shù)據(jù)出來進(jìn)行比對,判斷是否有數(shù)據(jù)故障出現(xiàn),比如利用hadoop做一些批處理MapReduce作業(yè),這種離線計(jì)算的方式時(shí)效性比較差,對于電商系統(tǒng)或者對于實(shí)時(shí)性要求較高的系統(tǒng)來說,問題發(fā)現(xiàn)的越晚損失也就越大,所以我們需要一種在線的校驗(yàn)?zāi)J絹韺?shí)時(shí)發(fā)現(xiàn)數(shù)據(jù)不一致問題。

在線的校驗(yàn)?zāi)J街傅氖敲砍霈F(xiàn)一筆數(shù)據(jù)就進(jìn)行一次比對,這種比對方式還可以分為事前和事后比對。

  • 事前比對是一種業(yè)務(wù)強(qiáng)耦合的校驗(yàn)方式,我們在業(yè)務(wù)系統(tǒng)代碼中進(jìn)行類似 AOP 的操作,橫插一段校驗(yàn)代碼,如果校驗(yàn)發(fā)現(xiàn)問題,則阻斷這次業(yè)務(wù)操作,這種模式雖然時(shí)效性很高,能夠保證每一筆數(shù)據(jù)的正確性,但是因?yàn)楹蜆I(yè)務(wù)耦合的太重,很容易出現(xiàn)一些災(zāi)難性的問題,比如校驗(yàn)代碼的性能差或者異常處理不正確,會(huì)直接導(dǎo)致業(yè)務(wù)操作受阻,影響正常業(yè)務(wù)活動(dòng)。
  • 事后校驗(yàn)嚴(yán)格上來說不能算是實(shí)時(shí)校驗(yàn),因?yàn)樾r?yàn)的時(shí)間點(diǎn)滯后于真實(shí)的業(yè)務(wù)動(dòng)作發(fā)生時(shí)間點(diǎn),這算是一種準(zhǔn)實(shí)時(shí)校驗(yàn),這種校驗(yàn)的好處在于,可以和業(yè)務(wù)解耦,不阻斷業(yè)務(wù)的正常進(jìn)行,還能較為"實(shí)時(shí)"的發(fā)現(xiàn)數(shù)據(jù)不一致問題,并且在一些特殊場景下(比如異步業(yè)務(wù),下面會(huì)介紹)只能使用事后校驗(yàn),缺點(diǎn)也很明顯,就是時(shí)效性相比于事前校驗(yàn)來說會(huì)比較差。

這里在啰嗦一句,可能讀到這里,有些人會(huì)問,既然是業(yè)務(wù)動(dòng)作發(fā)生之后再進(jìn)行校驗(yàn),它的意義還有多大呢?的確相比于事前校驗(yàn)來說,他并不能保證每一筆數(shù)據(jù)都正確,但是在實(shí)際操作中,像電商這種場景下,我們進(jìn)行業(yè)務(wù)功能迭代,會(huì)經(jīng)過日常環(huán)境 -> 預(yù)發(fā)環(huán)境 -> Beta測試 -> 線上環(huán)境的流程,尤其是在預(yù)發(fā)環(huán)境和 Beta 測試的情況下,一般會(huì)進(jìn)行一些線上引流或者模擬數(shù)據(jù)測試,特點(diǎn)是量小,即使發(fā)生問題也只是局部不會(huì)引起災(zāi)難,那在這種場景下,事后校驗(yàn)的意義就顯得很大,可以提前驗(yàn)證功能和數(shù)據(jù)的正確性,又不會(huì)對線上造成強(qiáng)耦合的影響;在功能完全上線后,事后校驗(yàn)的作用在于及時(shí)發(fā)現(xiàn)數(shù)據(jù)不一致問題,避免問題的進(jìn)一步擴(kuò)散。

綜上所述,對于業(yè)務(wù)數(shù)據(jù)校驗(yàn)時(shí)效性不是那么高的場景下,離線校驗(yàn)是一種比較合適的方式,開發(fā)接入成本都較低,對于業(yè)務(wù)數(shù)據(jù)校驗(yàn)時(shí)效性有一些要求的場景下,事后校驗(yàn)是一種比較適合的方式,對于業(yè)務(wù)校驗(yàn)時(shí)效性要求非常嚴(yán)格,并且能夠投入較多資源的情況下,事前校驗(yàn)比較適合。

數(shù)據(jù)一致性檢測實(shí)踐案例

案例一、會(huì)員系統(tǒng)

某店鋪會(huì)員入會(huì)業(yè)務(wù),需要結(jié)合店鋪系統(tǒng)、打標(biāo)系統(tǒng)、會(huì)員系統(tǒng)進(jìn)行入會(huì)退會(huì)操作,如下圖所示:

 

在這個(gè)業(yè)務(wù)場景中,買家在店鋪會(huì)員頁發(fā)起入會(huì)申請,入會(huì)成功對外發(fā)送會(huì)員入會(huì)metaq消息,下游業(yè)務(wù)系統(tǒng)根據(jù)這個(gè)metaq消息,為該用戶打上一個(gè)標(biāo)簽,用戶在下單的時(shí)候就根據(jù)這個(gè)標(biāo)簽判斷是否有優(yōu)先購買的權(quán)利。既然有入會(huì)就有退會(huì),退會(huì)同樣發(fā)起metaq消息給用戶進(jìn)行去標(biāo)操作。所以不管入會(huì)還是退會(huì),業(yè)務(wù)上要求店鋪系統(tǒng)的會(huì)員狀態(tài)(入會(huì)還是退會(huì))必須和用戶系統(tǒng)的標(biāo)簽狀態(tài)一致(有或者沒有),一旦發(fā)現(xiàn)數(shù)據(jù)不一致,一個(gè)已經(jīng)退會(huì)的用戶如果還有用戶會(huì)員標(biāo)簽,該用戶就可以購買這個(gè)限購商品,這樣就會(huì)造成商家資損。因此必須有對賬業(yè)務(wù)對數(shù)據(jù)一致性進(jìn)行強(qiáng)保證,一旦發(fā)現(xiàn)數(shù)據(jù)不一致,必須要通知相關(guān)人員進(jìn)行數(shù)據(jù)核對,如有問題則進(jìn)行數(shù)據(jù)訂正。

這個(gè)案例在對賬系統(tǒng)的選擇上有如下幾個(gè)要求:

  1. 實(shí)時(shí):必須當(dāng)天盡快處理。
  2. 可以報(bào)警
  3. 必須支持不同領(lǐng)域模型。
  4. 接口調(diào)用需要有一定的延遲,以便下游系統(tǒng)處理完所有流程之后再校驗(yàn)。
  5. 由于入會(huì)、退會(huì)metaq可能會(huì)有丟失或者亂序的情況,因此不可以根據(jù)該消息進(jìn)行對賬。

在這個(gè)業(yè)務(wù)場景下,我們可以看到,業(yè)務(wù)是異步的,會(huì)員系統(tǒng)發(fā)起入會(huì)操作后,并不是立刻就能在用戶系統(tǒng)打標(biāo)的,所以實(shí)時(shí)的事前校驗(yàn)并不適合這個(gè)場景,因?yàn)樵跁?huì)員系統(tǒng)發(fā)起入會(huì)操作的時(shí)候在用戶系統(tǒng)中還查不到這個(gè)打標(biāo)狀態(tài),需要延遲一段時(shí)間去查,所以只能用事后校驗(yàn)來做。

我們在這個(gè)場景的做法是:拉取店鋪會(huì)員數(shù)據(jù)庫的實(shí)時(shí)binlog日志數(shù)據(jù),給到校驗(yàn)系統(tǒng),校驗(yàn)系統(tǒng)解析日志數(shù)據(jù)拿到要打標(biāo)的會(huì)員id,并且延時(shí)一段時(shí)間后去會(huì)員系統(tǒng)查詢這個(gè)會(huì)員的入會(huì)狀態(tài),和日志中的狀態(tài)進(jìn)行一致性比對,發(fā)現(xiàn)不一致則進(jìn)行告警。

案例二、新老庫遷移

當(dāng)新老系統(tǒng)需要進(jìn)行更替的時(shí)候,經(jīng)常會(huì)涉及到數(shù)據(jù)遷移,由于數(shù)據(jù)量非常大,而且不允許停機(jī),所以遷移一定是一個(gè)循序漸進(jìn)的過程,整個(gè)過程會(huì)分成兩個(gè)部分,第一個(gè)部分是雙寫,保證新增數(shù)據(jù)兩邊同步。第二步是開始做存量數(shù)據(jù)遷移,通過后臺任務(wù)慢慢跑。在這個(gè)過程中可能會(huì)出現(xiàn)部分字段沒有同步,更新數(shù)據(jù)順序錯(cuò)亂導(dǎo)致數(shù)據(jù)內(nèi)容不一致的問題,所以需要對遷移進(jìn)行數(shù)據(jù)的一致性檢查,及時(shí)發(fā)現(xiàn)數(shù)據(jù)問題進(jìn)行訂正或者bug修復(fù)。

由于我們的目的是將數(shù)據(jù)遷移到新系統(tǒng),所以數(shù)據(jù)校驗(yàn)觸發(fā)條件就是新系統(tǒng)有數(shù)據(jù)寫入,這里可能有人會(huì)問如果老系統(tǒng)同步失敗呢,那么新系統(tǒng)就不會(huì)有數(shù)據(jù)寫入,就觸發(fā)不了校驗(yàn)。這里就存在校驗(yàn)邊界的問題,即我們假設(shè)同步系統(tǒng)是一定會(huì)同步成功的,如果同步失敗的話不允許跳過會(huì)一直嘗試重試同步,所以這里如果發(fā)生同步失敗,同步會(huì)暫停并且打印出同步錯(cuò)誤日志,這個(gè)就不是校驗(yàn)系統(tǒng)的問題了,我們會(huì)通過同步的進(jìn)度或者同步日志來觀察到這個(gè)現(xiàn)象。

所以我們在這個(gè)場景的做法是:接收新庫的數(shù)據(jù)庫變更binlog日志數(shù)據(jù),解析日志內(nèi)容,通過這條數(shù)據(jù)id去查詢舊庫的對應(yīng)數(shù)據(jù),進(jìn)行數(shù)據(jù)內(nèi)容的比對。由于雙寫的存在,一條數(shù)據(jù)可能會(huì)變更多次,這里就要求我們的校驗(yàn)必須是較為實(shí)時(shí)的進(jìn)行,否則就會(huì)出現(xiàn)拿到的日志數(shù)據(jù)內(nèi)容是舊的(這條數(shù)據(jù)又發(fā)生了更新),導(dǎo)致查詢老庫的數(shù)據(jù)出現(xiàn)不一致的問題,其實(shí)算是一種誤報(bào)。

 

責(zé)任編輯:武曉燕 來源: 云棲社區(qū)
相關(guān)推薦

2023-12-01 13:51:21

數(shù)據(jù)一致性數(shù)據(jù)庫

2025-03-27 03:00:00

2024-12-19 21:09:38

2009-06-18 09:18:08

Oracle檢索數(shù)據(jù)數(shù)據(jù)一致性事務(wù)恢復(fù)

2025-03-27 08:20:54

2023-06-07 08:10:29

2024-12-26 15:01:29

2023-09-07 08:11:24

Redis管道機(jī)制

2021-12-05 21:06:27

軟件

2021-10-18 10:30:59

流計(jì)算阿里云

2021-10-13 09:55:11

流計(jì)算引擎數(shù)據(jù)

2024-07-04 12:36:50

2017-08-25 10:16:00

2021-12-14 07:15:57

MySQLRedis數(shù)據(jù)

2024-08-20 16:13:52

2022-02-17 21:04:27

數(shù)據(jù)庫MysqlRedis

2023-05-26 07:34:50

RedisMySQL緩存

2023-11-22 12:55:59

微服務(wù)架構(gòu)數(shù)據(jù)庫

2019-01-15 17:58:03

微服務(wù)架構(gòu)數(shù)據(jù)

2019-12-17 08:40:33

微服務(wù)架構(gòu)數(shù)據(jù)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號