一次全量數(shù)據(jù)對(duì)比工具發(fā)現(xiàn)問題的過程與思考
如果沒有這次全量數(shù)據(jù)對(duì)比工具,那么也許這個(gè)歷史問題會(huì)繼續(xù)隱藏著,直到發(fā)生線上事故才暴露出來,畢竟人工抽樣驗(yàn)證發(fā)現(xiàn)的概率只有「5.8%」
背景是發(fā)票系統(tǒng)有18500個(gè)電子發(fā)票訂單被財(cái)務(wù)系統(tǒng)駁回了,駁回原因是財(cái)務(wù)系統(tǒng)上線了全電發(fā)票需求,上線后電子發(fā)票枚舉被誤刪,無法處理電子發(fā)票。需要我們發(fā)票系統(tǒng)對(duì)這18500電子發(fā)票訂單,重新觸發(fā)提票,讓發(fā)票能正常開出來。也就是,我們需要刷數(shù)。刷數(shù)是個(gè)高危操作,極易引發(fā)線上問題。
經(jīng)驗(yàn)教訓(xùn)告訴我們,刷數(shù)雖然是一種處理線上問題的方法,但是也特別容易引起二次事故。對(duì)于刷數(shù),我們需要像新需求一樣對(duì)待,經(jīng)過完備的需求分析、設(shè)計(jì)評(píng)審、代碼評(píng)審。主要考慮以下3點(diǎn):
- 刷數(shù)范圍,怎么篩選問題數(shù)據(jù),評(píng)審過濾條件;
- 刷數(shù)程序,怎么修復(fù)問題數(shù)據(jù),評(píng)審代碼邏輯;
- 驗(yàn)證方法,怎么驗(yàn)證修復(fù)數(shù)據(jù),分析測(cè)試場(chǎng)景;
在刷數(shù)實(shí)施前,群里報(bào)備,周知相關(guān)方及相關(guān)人員。先試刷,驗(yàn)證無問題后,再全刷,最后驗(yàn)證問題數(shù)據(jù)已經(jīng)得以修復(fù)。這一套刷數(shù)流程,通過加強(qiáng)前期評(píng)審,能很好地預(yù)防缺陷,增強(qiáng)刷數(shù)成功的信心。但是人工評(píng)估可能遺漏場(chǎng)景,可能對(duì)真實(shí)數(shù)據(jù)情況把握不全,刷數(shù)的關(guān)鍵還在于最后的數(shù)據(jù)驗(yàn)證。
抽樣驗(yàn)證還是全量驗(yàn)證,這是一個(gè)問題。抽樣驗(yàn)證是人工隨機(jī)挑幾個(gè)數(shù)據(jù)進(jìn)行驗(yàn)證,我們通常傾向于使用抽樣驗(yàn)證,一是抽樣驗(yàn)證是一種科學(xué)的有效的驗(yàn)證方法,雖然它存在一定概率的遺漏,但是很多時(shí)候是可以接受的風(fēng)險(xiǎn);二是抽樣驗(yàn)證也是無奈之舉,找不到辦法進(jìn)行全量驗(yàn)證。我們遇到的困難是,數(shù)據(jù)存在ES中,批量把所有數(shù)據(jù)查出來很麻煩,也無法直接編寫校驗(yàn)邏輯,全量驗(yàn)證似乎是不可能的。
全量驗(yàn)證有2個(gè)思路:
- 如果能直連庫(kù),那么先提數(shù),再寫程序?qū)Ρ龋?/li>
- 如果只能WEB頁面查數(shù),那么使用Python爬蟲提數(shù),再寫程序?qū)Ρ龋?/li>
后者適用于我們的情況。ES能通過WEB頁面查詢數(shù)據(jù),只要是WEB頁面,即使有Cookie,也能爬取到接口數(shù)據(jù)。F12抓包到查詢接口的URL、Cookie、入?yún)⒑螅褂肞ython的requests庫(kù)可以爬取查詢結(jié)果數(shù)據(jù):
url = 'http://xxx'
headers = {
'Cookie': 'xxx',
'Content-Type': 'application/json'
}
response = request('get', url=url, headers=headers)
result = response.json()
我們使用這種方式,傳入訂單號(hào),查詢到了申請(qǐng)單數(shù)據(jù),以便進(jìn)行對(duì)比校驗(yàn)邏輯。而訂單號(hào),研發(fā)打在了日志里,需要下載日志文件后,進(jìn)行解析,可以使用Python切片:
orders = set()
with open('some.log') as f:
for line in f.read().splitlines():
if 'xxx' in line:
orders.add(line[line.index('orderId='):line.index(',已執(zhí)行')].replace('orderId=', ''))
print(len(orders))
with open('orders.txt', 'w') as f:
f.writelines(','.join(orders))
.index可以定位到關(guān)鍵詞的索引,然后[:]切片獲取指定內(nèi)容。
日志解析訂單號(hào)+爬蟲獲取申請(qǐng)單+編寫對(duì)比校驗(yàn)邏輯,全量數(shù)據(jù)對(duì)比工具就完成了??墒?8500單,上萬級(jí)別數(shù)據(jù),要全部對(duì)比完,至少要幾個(gè)小時(shí)。是時(shí)候使用多線程了。
多線程第一步,拆解數(shù)據(jù),將18500單拆成以100單為一組的列表:
def split_list(lst, size):
"""
將列表 lst 拆分成每份 size 個(gè)元素的子列表,并返回一個(gè)包含所有子列表的列表。
"""
return [lst[i:i + size] for i in range(0, len(lst), size)]
多線程第二步,隊(duì)列提數(shù),讓多個(gè)線程依次從列表中取出數(shù)據(jù),每個(gè)線程每次取不同的數(shù)據(jù):
import threading
# 待處理的數(shù)據(jù)列表
data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
# 創(chuàng)建鎖對(duì)象
lock = threading.Lock()
# 定義線程函數(shù)
def process_data():
global data
while True:
# 加鎖
lock.acquire()
# 如果列表為空,說明所有數(shù)據(jù)已被處理完畢,退出循環(huán)
if len(data) == 0:
lock.release()
break
# 取出列表中的第一個(gè)數(shù)據(jù)
num = data.pop(0)
# 釋放鎖
lock.release()
# 對(duì)數(shù)據(jù)進(jìn)行處理
print("Processing data:", num)
# 創(chuàng)建多個(gè)線程
threads = []
for i in range(5):
t = threading.Thread(target=process_data)
threads.append(t)
# 啟動(dòng)所有線程
for t in threads:
t.start()
# 等待所有線程結(jié)束
for t in threads:
t.join()
print("All data processed.")
阻塞隊(duì)列是通過加鎖來實(shí)現(xiàn)的,每個(gè)線程在取數(shù)前先加鎖,然后pop(0)取出列表中的第一個(gè)數(shù)據(jù),再釋放鎖。上述程序修改①data②數(shù)據(jù)處理邏輯③線程數(shù)即可使用。
對(duì)比工具使用多線程后,運(yùn)行時(shí)間從小時(shí)級(jí)別降到了分鐘級(jí)別。當(dāng)天研發(fā)本來以為要跑很久,準(zhǔn)備第二天再來看,就先撤了。我執(zhí)著了一下多線程實(shí)現(xiàn),在ChatGPT幫助下,很快就把結(jié)果跑出來。趕緊打電話搖人,讓研發(fā)回來看問題,研發(fā)那時(shí)剛到家,掏出鑰匙把門打開。在全量對(duì)比前,我們也都做了一輪抽樣驗(yàn)證,均沒有發(fā)現(xiàn)任何問題。18500單全量對(duì)比,發(fā)現(xiàn)有1064單存在問題,能抽樣發(fā)現(xiàn)的概率只有5.8%。
總結(jié),分析這些問題原因:
- 遺漏了1種數(shù)據(jù)情況,評(píng)估不到位
- 未考慮到刷數(shù)環(huán)境影響,在預(yù)發(fā)環(huán)境刷數(shù),上下游環(huán)境都是預(yù)發(fā),可能跟線上版本不一樣,尤其是做寫操作時(shí),格外需要注意
- 刷數(shù)程序本身缺陷,這個(gè)缺陷隱藏在一段用了很多次刷數(shù)的歷史代碼里面,不是100%會(huì)導(dǎo)致問題
可以發(fā)現(xiàn),大數(shù)據(jù)量驗(yàn)證,人工無法百分百保證數(shù)據(jù)準(zhǔn)確性,抽樣檢查,94.2%概率發(fā)現(xiàn)不了問題。最穩(wěn)妥的辦法,還是全量對(duì)比,讓每條數(shù)據(jù),都經(jīng)過對(duì)比規(guī)則的檢驗(yàn)。