代碼寫錯,差點虧了幾萬!
活動最重要,也是最麻煩的環(huán)節(jié)就是返現(xiàn)環(huán)節(jié),這次我們是通過一個鏈接收集大家支付寶賬號,然后進行支付寶批量轉賬。但是這個工作看起來很簡單,其實有很多東西需要留意的,因為涉及到錢,最基本的要保證冪等性。什么是冪等性呢?用戶對于同一操作發(fā)起的一次請求或者多次請求的結果是一致的,不會因為多次點擊而產(chǎn)生了副作用。比如這次返現(xiàn)活動,在收集大家支付寶信息的時候,不管用戶提交了幾次信息,最終只轉賬一次。返現(xiàn)的程序是由小北實現(xiàn)的,他在實現(xiàn)的過程中,差點就因為這個事情差點虧了點錢。
以下是小北對這次返現(xiàn)的復盤:不是組織了一場新用戶免費領取一年阿里云服務器的活動了,現(xiàn)在已經(jīng)超過1000人購買,750 人收到了返現(xiàn),不禁發(fā)出還得是北哥的感嘆!但是在短時間內(nèi)給近1000人返現(xiàn),并且還要保證它們都是符合返現(xiàn)條件的,就不太容易,今年 6.18 我們是寫了一個檢測工具,自己檢測后截圖給我們,我們拉群,滿100人發(fā)紅包。這樣會浪費整整周六一天的時間,最近了解到支付寶有批量轉賬能力,于是我就發(fā)了個問卷向大家收集一波阿里云ID、支付寶賬號用于返現(xiàn)。這樣直接用阿里云每天導給我的訂單數(shù)據(jù)做校驗,看哪些用戶購買了,有資格返現(xiàn)。本來非常簡單,所以就讓小老弟去幫我寫代碼,結果怎么著,小老弟的代碼一小時就寫完了,而且用得很爽!于是前天晚上我就回去看了下小老弟的代碼,結果一看嚇一跳,差點讓我虧幾千上萬都有可能??!簡單來說支付寶批量轉賬,需要生成一個 csv,每一行是:支付寶賬號,姓名,轉賬金額,備注 這樣的信息。小老弟的代碼是這樣寫的:
users?=?get_user_info_from_file()?//??從騰訊問卷下載的大家提交的返現(xiàn)信息?csv文件導入
order_map?=?get_order_map()?//?從阿里云導出的訂單數(shù)據(jù)生成一個?map,key是用戶的阿里云ID,value是訂單信息
for?user?in?users:
??if?user.aliyun_id?in?order_map:
?????csv_file.writeline(xxxxxxxx)??//??有購買記錄的讀者信息寫入csv文件,用于批量轉賬
然后這個產(chǎn)生的 csv 文件就可以傳到支付寶 PC 端的批量轉賬接口中進行轉賬。這代碼完全能正常工作,也能完成返現(xiàn)!但是?。?!小老弟沒有考慮到異常場景,以及應對各種羊毛黨或者用戶的錯誤操作比如說,假如一個用戶在填問卷的時候填了多次信息,上面的代碼是不是就會導致多次轉賬?當然,這樣的用戶不多,但是總有大意的讀者多點了一次提交之類,后來我就發(fā)現(xiàn)了:當然,這樣的讀者比例不多,但是 1000 個用戶,十幾個還是有的,你就得多返現(xiàn)幾百上千。(PS:讓我想起了后端不能相信前端,不能相信用戶輸入的數(shù)據(jù)如果面對更多的讀者,或者你讀者里有羊毛黨,他就是惡意多次提交,你是不是就得虧死?這個返現(xiàn),不是一次就搞完的,是分批的,訂單數(shù)據(jù)一天導出一次,每天晚上我都會運行這個腳本進行返現(xiàn)。那如果是昨天已經(jīng)返現(xiàn)的同學,今天又來提交一次,這種又該怎么辦呢?這個問題實際上是怎么做冪等、去重。因為這個訂單數(shù)據(jù)不是實時的,一天導出一次,但是讀者隨時可能去填表單。那如果讀者今天買今天填寫返現(xiàn)表單,但是今晚去處理的時候查不到購買記錄沒法返現(xiàn)怎么辦?難道讓讀者明天再填一次?總之就是為了處理這些異常的 case 以及郵件通知等,我前天晚上下班后到家肝了一波,徹底堵死了這些漏洞,畢竟打工人的錢也不是好賺的~從昨晚開始陸續(xù)返現(xiàn), 中間也發(fā)現(xiàn)很多之前考慮到的異常 case,也有些異常場景還沒考慮到,及時補上就行。總之,我覺得工作后很多時候寫代碼,一半以上的時間都是在為了補償各自異常場景,比如參數(shù)校驗、邊界值、掉單、網(wǎng)絡問題、超時、重入等等。尤其是涉及到錢,這是一分都不能差的。跟以前在學校寫代碼基本只寫成功的路徑完全不一樣。好了,今天就寫到這里吧。具體云服務器能做什么,可以看我這篇介紹:云服務器能做什么?現(xiàn)在還有一些名額,需要免費領取的可以在公眾號后臺回復「服務器」