? ?最近忙活完一個需求，記錄下。需求是我們的項目在App Store中有個會員自動訂閱的功能。由于會員系統(tǒng)不是我們這邊做的，所以之前所有的流程由會員部門的人跟進(jìn)。我們只負(fù)責(zé)將記錄發(fā)送到對方提供給我的API中。但是對方之前C++出身，所以對IOS的開發(fā)特性并不熟悉，所以并未處理會員訂閱回調(diào)的事情。關(guān)于這個可以參考https://help.apple.com/itunes-connect/developer/#/dev0067a330b這個。所以聽說他們那邊是沒過3個小時會去掃描一次隊列，查看某個用戶該月是否有扣費但是還未進(jìn)行續(xù)期，如果存在則續(xù)期。雖然運行起來沒什么問題，但是3個小時，用戶體驗實在太差。我在之前處理數(shù)據(jù)時，有看到用戶反饋的數(shù)據(jù)。一大票人在吐槽錢扣了，但是會員沒加上是什么鬼。

以上為背景，所以領(lǐng)導(dǎo)讓我處理下自動訂閱的回調(diào)。除了實時記錄推送過來的數(shù)據(jù)以外，還應(yīng)該根據(jù)事情類型實時通知到會員那邊，讓他們立刻處理。需求是很簡單的需求，但是要考慮的事情還是有些的，簡單說下思路。

1.因為提供的API沒有簽名機制所以，在拿到數(shù)據(jù)后應(yīng)該第一時間去蘋果那邊校驗，只有校驗通過的數(shù)據(jù)才能進(jìn)行下一步

2.需求隨時都有可能發(fā)生改變，所以程序也隨時都有可能重啟，但是這種牽涉到支付的程序還是要謹(jǐn)慎些。所以我建了一張緩存隊列表，在數(shù)據(jù)校驗通過后，第一時間插入到緩存表中。然后返回200的狀態(tài)碼。這樣一旦程序中斷，請求必然超時，蘋果明確有說如果返回4XX或者5XX會在一段時間內(nèi)重試的

3.程序在起來時一定會去緩存表中取出未處理的訂單放置到工作隊列中去

4.后臺有個線程不停的從工作隊列中獲取訂單

5.當(dāng)然會員的3小時輪詢機也必然繼續(xù)沿用下去，作為輔助。畢竟天有不測風(fēng)雨，總要有plan B 不是

通過以上我便不用擔(dān)心程序在重啟時丟單的問題了