文章目錄
- 一、業務介紹
- 二、技術實作
- 1、總覽
- 2、監控
- 2.1 業務名額監控
- 2.2 技術名額監控
- 2.3 資料邏輯巡檢
- 2.4 異常監控
- 3、賽程/金牌榜資訊
- 4、任務完成入賬
- 5、資料藏品兌換
- 6、數字藏品兌換模拟
- 7、前端兜底配置
- 三、團隊協作
- 1. 會議需要主持人
- 2. 多部門的資訊及時交流
- 四、回顧總結
一、業務介紹
引用自産品文檔：
結合冬奧營銷節點，抓準冬奧期間國民對于冰雪運動的高關注度，主打小紅書的内容差異化優勢，在11月底-2月初期間，産出一系列品牌傳播物料，并進行線上線下的整合營銷活動，對外建構“玩冰雪，上小紅書”的品牌認知，提升運動垂直人群對小紅書的好感度，全網使用者對小紅書運動的認知度。
二、技術實作
(以下隻提一些有意思的點，而不會全盤介紹整個技術實作内容，純業務内容也沒啥好介紹)
1、總覽
1.1 技術調研
- 确定某些功能設計能否實作、如何實作、耗時多少。比如要在app端搞個冬奧活動的挂件，因為目前沒有現成或者類似的，是以就要和用戶端團隊聊聊能不能實作。
- 和依賴方确認，能否抗住冬奧帶來的新增流量。比如冬奧活動頁面需要查詢筆記資訊，那麼需要和筆記團隊确認，新增的這部分活動流量能否支撐的住。
1.2 技術方案設計
在這個環節，需要很細緻的把所有需要開發的功能點都羅列出來，針對每個功能點，需要：技術實作方案、流程圖、風險點等等。
之是以要做的這麼細緻，主要原因是活動很重要，是以務必要把該考慮的地方都考慮到，避免開發中返工耽誤進度，或者上線出問題；次要原因則是，在技術評審時，衆多大佬在場，不能出纰漏。
1.3 技術評審
這個環節就是衆多大佬在場，一起審驗你的技術方案是否完善，風險點處理是否妥當。
在評審之前，技術方案最好就要做的完善點，到了評審上，就基本不要出問題了，畢竟大佬當面，留下壞印象可不好。
1.4 資源評估與保障
- 自己：評估下qps大概是多少，需要多少機器資源
- 依賴方：
- mysql、redis等存儲服務：具體到每個sql和操作指令，資料量是多少、qps是多少，需要申請什麼配置（是否使用讀寫分離，要多少執行個體等）
- 第三方應用服務：冬奧流量下，需要增加多少機器配置才能扛得住
因為臨近春節，一來大家都在做活動，對于雲伺服器的需求比較旺盛，二來因為過年放假，雲服務的人也放假去了，是以量大的機器資源要在過年前提前敲定好，最好不要臨時去采購。
2、監控
2.1 業務名額監控
專門建了一個報數群，定時播報業務名額資訊，樣例如下：
獎品兌換情況：
抽獎券: 前15分鐘兌換x, 總兌換：xxx
數字藏品: 前15分鐘兌換x, 為什麼要專門建立一個群，在群裡播報消息，而不是給每個人單獨發消息？
主要是因為，如果對于資料有問題，那麼相關人員可以直接在群裡就地讨論，但是給每個人單發消息的話，就沒有這麼友善了。
2.2 技術名額監控
需要監控的技術名額，比如每個表的資料量、接口qps等等
這個直接私發給所有開發人員的，示例如下：
[2022-02-21 00:05:01] 資料庫表資料量統計
--olympics_xxxx: xxxx
--olympics_xxxx: xxxx
--olympics_xxxx: xxxx
[2022-02-21 00:05:03] 主要作用是為了在技術側，對業務發展進度心裡有個譜，防止出現業務發展太快，目前的技術設計無法支撐的情況。
次要作用，則是做彙報的時候挑些好看的資料裝逼用（裝逼是人類的永恒需求）。
2.3 資料邏輯巡檢
主要作用是校驗資料邏輯的正确性，及時發現問題并修正，比如檢測使用者賬戶的碎片總額，與任務完成明細是否比對等。
示例如下：
[2022-02-21 00:41:41] 累計擷取碎片數與任務完成明細不一緻的使用者數:xxx
使用者采樣:[xxxx] (ps：實際業務運作中，這個資料邏輯巡檢，确實也發現存在資料不比對的異常情況，還好影響範圍不大)
2.4 異常監控
在關鍵邏輯（比如任務完成入賬）出現異常時，直接企微消息發送異常資訊給相關人員（不過要控制頻率，不要就成資訊轟炸了）。
主要目的，是為了在關鍵邏輯出現異常時，能更快速的感覺并排查、修複。在實際業務運作過程中，也确實發現了一些奇奇怪怪的問題，還好影響都不大。
示例如下：
冬奧活動異常通知:
--異常類型:xxxx
--異常次數:xxxx
--異常資訊:xxxx
--上次觸發異常時間:yyyy-MM-dd HH🇲🇲ss 3、賽程/金牌榜資訊
這部分資料是和第三方平台直播吧對接，從直播吧擷取資料的。采用的方案如下：
為什麼使用redis緩存？為了與第三方服務不做強依賴。
直接從直播吧查詢并傳回，如果直播吧挂了，那我們豈不是也要涼涼？風險太高。
作為程式猿，公司裡的自己人都要抱着懷疑的态度去審視，更别說這種外部公司提供的資料接口了。
在實際運作過程中，與直播吧的互動确實也暴露出兩個問題：
- 後期時，直播吧接口偶爾會出現調不通的情況
- 在冬奧最後一天時，直播吧那邊資料下線比小紅書這邊冬奧活動定的時間更早，他們提前下線查不到資料了
4、任務完成入賬
後端記錄任務完成與獎勵入賬，一共需要用到兩把鎖，依次加鎖，然後再逆序解鎖。
- 使用者-任務關聯鎖：避免并發情況下，使用者重複完成任務。雖然從業務流程上來講，重複完成任務應該不存在，但是實際上，因為網絡延遲、前端邏輯等，在後端是可以監控到少量重複任務完成請求的。
- 使用者賬戶鎖：避免對使用者賬戶進行并發更改，導緻資料錯亂。使用者兌換獎品等業務場景，也會影響到到使用者賬戶碎片總額的變化，是以在這些場景中，也都必須要獲得使用者鎖之後才能對賬戶進行操作。
5、資料藏品兌換
5.1 為啥要先扣總額，再去領取數字藏品？
因為領取數字藏品這個操作，是調用第三方服務的，無法復原，但是總額扣減是資料庫操作，可以在數字藏品領取失敗後復原。
5.2 為什麼不用藏品鎖？
- 數字藏品的庫存總額，都是提前配置好儲存在redis中，而不是每次從第三方接口中查詢。
- 數字藏品的庫存是一定滿足使用者領取需求的，是以在設計方案時，可以直接先redis扣減庫存，如果庫存不足或者調用第三方接口失敗，就把扣減的庫存加回去就好了（庫存加回去失敗了怎麼辦？可以承受一定限度的浪費，是以問題不大）。
- 為什麼不采用藏品鎖的方案？如果采用藏品鎖，每個藏品一把鎖，那麼藏品兌換的并發度就要受限，在高峰期可能很多人都兌換不了，如果一個藏品多把鎖，并發度的問題倒是能解決一些，但是複雜了。綜合看下來，就把藏品鎖的方案pass了。
- 為什麼不先查詢庫存總額，判斷是否有庫存，再進行扣減，而是使用decrBy，發現庫存不夠還要再加回去？要保證庫存扣減是個原子操作，不然可能存在查詢到是有庫存的，但是扣減的時候已經沒庫存了。
6、數字藏品兌換模拟
數字藏品氛圍精品款和基礎款，精品款的發放會受到掉率和每日發放上限的限制，在未獲得精品款的情況下，随機獲得一個基礎款。
之前我們在測試的時候，隻測試了藏品是否能正常兌換，還是産品和營運提出，希望能模拟一下目前藏品配置，每日x次兌換的情況下，藏品發放的情況。
之前我覺得這個模拟沒啥意義的，事實證明我想岔了。
第一版的藏品兌換邏輯大緻是這樣的：
List[String] ids = [精品款1，精品款2，精品款3，精品款4，基礎款1]
// 精品款擷取
int index = (int) (System.currentTimeMillis() % ids.size());
for (int indexInc = 0; indexInc < ids.size(); indexInc++) {
String id = ids[(index + indexInc) % ids.size()];
if (該id對應數字藏品不是精品款) {continue;}
if (擷取該數字藏品成功) {return；}
}
// 基礎款擷取
index = (int) (System.currentTimeMillis() % ids.size());
for (int indexInc = 0; indexInc < ids.size(); indexInc++) {
String id = ids[(index + indexInc) % ids.size()];
if (該id對應數字藏品不是基礎款) {continue;}
if (擷取該數字藏品成功) {return；}
} 從左向右的第一個基礎款，命中機率要比其他基礎款高很多，因為隻要随機到的起始index落在精品款上，那麼必然最終會選到向右的第一個基礎款。同樣的道理，第一個位置的精品款，也有這個問題，會比其他精品款的掉率高不少。
第二版的方案，與第一版差不多，差別在于，将精品款id和基礎款id拆分成兩個數組了，并沒有放在同一個數組當中。
是以，測試還是要全面呀。
7、前端兜底配置
這個是前端同僚提出來的，讓營運提供一份預設配置，在後端接口異常時，前端展示這份預設配置。
這個設計方案是真的驚豔到我了，之前我做的所有技術方案中，出現問題的兜底方案都是直接展示空就完了，還沒想到過可以提前準備一份預設配置的。
當然，這個方案的實施，也要看具體業務場景能否适用。
三、團隊協作
1. 會議需要主持人
-
主持人有什麼用？
把控整個會議的進度，保證高效的達成會議目标，常見作用比如：
- 在出現争執時及時拍闆下結論，避免一直争論下去導緻會議其他議題沒聊完
- 會議跑偏的時候，及時把大家拉回來
- 對每個比較大的議題，在讨論結束時，做總結，并和所有成員确認總結結論無異議
- 。。。
ps：為啥我專門提這個點呢？因為開會效率真的有夠低的，開了一周多了，要是不及時制止，可能還要開更長。可是這個活動是有明确的deadline的，在期限之前必須完成上線，現在開會浪費的時間，都需要我後面加班加點的補回來，我當然坐不住了。
- 列舉下我遇到的，開會過程中的存在的一些問題
-
已經拍闆确定的問題，反複拿出來讨論
典型場景就是這樣的：
上一次的會議，已經和支援部門的人，讨論過針對某個功能點的對接方案，當時有方案A/B/C可選，最終拍闆定下采用A方案。
然後在下一次和支援部門的人開會讨論時，話題突然聊到上次聊過的功能點，然後就又開始讨論有哪些實作方案，要怎麼選擇。
我作為一個兩次開會都在的人，給我的感覺就像是陷入輪回不停穿越一樣。
-
已經開會讨論得到的結論，可以再次确認下，也可以提出新的質疑，但是完全一副上次沒開會重新再讨論一遍的架勢，就過分了，尤其是讨論的人裡面有上次開過會的。
這個時候，就需要有個人站出來，直接制止他們的讨論，然後明确的告訴他們：這個問題上次讨論過了，結論是xxx，你們覺得有啥問題嘛？
-
在拉了很多人的會議上，過分讨論一些無意義的細節
比如需要某個支援部門，提供一份資料，資料量不大，完全可以人工從資料庫手動擷取的。隻需要讨論下，資料需求能否支援就可以了，至于怎麼提供這個資料，就完全沒有必要在會上聊，會下的時候相關方自己去對一下就行了。
資料量這麼小，特殊操作一下就完事了，沒必要那麼正經的還讨論下http接口、rpc接口、資料庫下載下傳等等一堆方案哪個好點，浪費時間。
-
暫時無法得到結論的争議，先擱置
比如某個功能點實作，需要依賴其他部門，但是其他部門能否支援、可以支援到什麼程度還沒結論。
這個功能點實作，就完全可以先擱置，等依賴部門有結論了或者到我們必須做決定的期限了，再讨論怎麼實作。可以提前簡單聊下各種實作方案，但沒必要去争論，更沒必要提前花時間去做技術方案，純屬浪費時間。
2. 多部門的資訊及時交流
四、回顧總結
- 重要的活動，要專門做運維支援，根據業務發展情況，随時會有各種需求産生。
- 異常監控确實很有必要，及時發現了問題。主會場配置，營運承諾配置修改後都會去線上check一下，實際上并沒有嚴格遵守，而且也确實出現線上配置錯的情況，還是後端開發看到監控去通知他們改的。
- 活動關鍵時間點，最好選在上班時間，不然就得要麼熬夜，要麼早起，太難了。