大家好，我是小林。

這一周都在帶大家免費(fèi)領(lǐng)取一年阿里云服務(wù)器的活動(dòng)，現(xiàn)在已經(jīng)超 1000 人購買了，昨晚我就開始在部分群陸陸續(xù)續(xù)返現(xiàn)，幾萬塊，刷一秒就沒了，場面很壯觀。

還沒返現(xiàn)的群，稍等一下，這周都會(huì)一起搞完的。

這次阿里云服務(wù)器，我和小北組隊(duì)了，因?yàn)槲覀冎?6 月份搞過一次阿里云白領(lǐng)活動(dòng)，所以擔(dān)心一個(gè)人搞的話，帶不到大家白piao，因?yàn)楫?dāng)拉新用戶到一定數(shù)量，阿里云才會(huì)給我們獎(jiǎng)金，比如 1500 人的獎(jiǎng)金是9W，這樣我們才可以給 1500 人返現(xiàn) 60 元，也就是把獎(jiǎng)金全部返現(xiàn)了。

活動(dòng)最重要，也是最麻煩的環(huán)節(jié)就是返現(xiàn)環(huán)節(jié)，這次我們是通過一個(gè)鏈接收集大家支付寶賬號(hào)，然后進(jìn)行支付寶批量轉(zhuǎn)賬。

但是這個(gè)工作看起來很簡單，其實(shí)有很多東西需要留意的，因?yàn)樯婕暗藉X，最基本的要保證冪等性。

什么是冪等性呢？用戶對于同一操作發(fā)起的一次請求或者多次請求的結(jié)果是一致的，不會(huì)因?yàn)槎啻吸c(diǎn)擊而產(chǎn)生了副作用。比如這次返現(xiàn)活動(dòng)，在收集大家支付寶信息的時(shí)候，不管用戶提交了幾次信息，最終只轉(zhuǎn)賬一次。

返現(xiàn)的程序是由小北實(shí)現(xiàn)的，他在實(shí)現(xiàn)的過程中，差點(diǎn)就因?yàn)檫@個(gè)事情差點(diǎn)虧了點(diǎn)錢。

以下是小北對這次返現(xiàn)的復(fù)盤：

不是組織了一場新用戶免費(fèi)領(lǐng)取一年阿里云服務(wù)器的活動(dòng)了，現(xiàn)在已經(jīng)超過1000人購買，750 人收到了返現(xiàn)，不禁發(fā)出還得是北哥的感嘆！

但是在短時(shí)間內(nèi)給近1000人返現(xiàn)，并且還要保證它們都是符合返現(xiàn)條件的，就不太容易，今年 6.18 我們是寫了一個(gè)檢測工具，自己檢測后截圖給我們，我們拉群，滿100人發(fā)紅包。

這樣會(huì)浪費(fèi)整整周六一天的時(shí)間，最近了解到支付寶有批量轉(zhuǎn)賬能力，于是我就發(fā)了個(gè)問卷向大家收集一波阿里云ID、支付寶賬號(hào)用于返現(xiàn)。

這樣直接用阿里云每天導(dǎo)給我的訂單數(shù)據(jù)做校驗(yàn)，看哪些用戶購買了，有資格返現(xiàn)。

本來非常簡單，所以就讓小老弟去幫我寫代碼，結(jié)果怎么著，小老弟的代碼一小時(shí)就寫完了，而且用得很爽！

于是前天晚上我就回去看了下小老弟的代碼，結(jié)果一看嚇一跳，差點(diǎn)讓我虧幾千上萬都有可能??！

簡單來說支付寶批量轉(zhuǎn)賬，需要生成一個(gè) csv，每一行是：支付寶賬號(hào)，姓名，轉(zhuǎn)賬金額，備注 這樣的信息。

小老弟的代碼是這樣寫的：

users?=?get_user_info_from_file()?//??從騰訊問卷下載的大家提交的返現(xiàn)信息?csv文件導(dǎo)入

order_map?=?get_order_map()?//?從阿里云導(dǎo)出的訂單數(shù)據(jù)生成一個(gè)?map，key是用戶的阿里云ID，value是訂單信息

for?user?in?users:

??if?user.aliyun_id?in?order_map:

?????csv_file.writeline(xxxxxxxx)??//??有購買記錄的讀者信息寫入csv文件，用于批量轉(zhuǎn)賬

然后這個(gè)產(chǎn)生的 csv 文件就可以傳到支付寶 PC 端的批量轉(zhuǎn)賬接口中進(jìn)行轉(zhuǎn)賬。

這代碼完全能正常工作，也能完成返現(xiàn)！

但是?。?！

小老弟沒有考慮到異常場景，以及應(yīng)對各種羊毛黨或者用戶的錯(cuò)誤操作

比如說，假如一個(gè)用戶在填問卷的時(shí)候填了多次信息，上面的代碼是不是就會(huì)導(dǎo)致多次轉(zhuǎn)賬？

當(dāng)然，這樣的用戶不多，但是總有大意的讀者多點(diǎn)了一次提交之類，后來我就發(fā)現(xiàn)了：

當(dāng)然，這樣的讀者比例不多，但是 1000 個(gè)用戶，十幾個(gè)還是有的，你就得多返現(xiàn)幾百上千。

（PS：讓我想起了后端不能相信前端，不能相信用戶輸入的數(shù)據(jù)

如果面對更多的讀者，或者你讀者里有羊毛黨，他就是惡意多次提交，你是不是就得虧死？

這個(gè)返現(xiàn)，不是一次就搞完的，是分批的，訂單數(shù)據(jù)一天導(dǎo)出一次，每天晚上我都會(huì)運(yùn)行這個(gè)腳本進(jìn)行返現(xiàn)。

那如果是昨天已經(jīng)返現(xiàn)的同學(xué)，今天又來提交一次，這種又該怎么辦呢？這個(gè)問題實(shí)際上是怎么做冪等、去重。

因?yàn)檫@個(gè)訂單數(shù)據(jù)不是實(shí)時(shí)的，一天導(dǎo)出一次，但是讀者隨時(shí)可能去填表單。

那如果讀者今天買今天填寫返現(xiàn)表單，但是今晚去處理的時(shí)候查不到購買記錄沒法返現(xiàn)怎么辦？

難道讓讀者明天再填一次？

總之就是為了處理這些異常的 case 以及郵件通知等，我前天晚上下班后到家肝了一波，徹底堵死了這些漏洞，畢竟打工人的錢也不是好賺的~

從昨晚開始陸續(xù)返現(xiàn)， 中間也發(fā)現(xiàn)很多之前考慮到的異常 case，也有些異常場景還沒考慮到，及時(shí)補(bǔ)上就行。

總之，我覺得工作后很多時(shí)候?qū)懘a，一半以上的時(shí)間都是在為了補(bǔ)償各自異常場景，比如參數(shù)校驗(yàn)、邊界值、掉單、網(wǎng)絡(luò)問題、超時(shí)、重入等等。

尤其是涉及到錢，這是一分都不能差的。

跟以前在學(xué)校寫代碼基本只寫成功的路徑完全不一樣。

好了，今天就寫到這里吧。具體云服務(wù)器能做什么，可以看我這篇介紹：云服務(wù)器能做什么？

現(xiàn)在還有一些名額，需要免費(fèi)領(lǐng)取的可以在公眾號(hào)后臺(tái)回復(fù)「服務(wù)器」