背景

多數的移動端APP都會有做任務領取獎勵的功能模塊，這類需求的目的是培養用戶使用習慣，提升用戶活躍性，用戶完成任務獲得積分獎勵，通過積分兌換商品或者充值話費，微信體現等。

擬定需求場景(如圖↓)，概要：APP底部導航中新增小任務Tab，點擊Tab可查看任務完成進度和領取情況，點擊去完成跳轉到做任務的業務界面，當用戶完成任務並且滿足領取條件的時候，任務Tab需要紅點提醒用戶當前有獎勵可領取，用戶領取後並且當前沒有待領取獎勵小紅點消失，任務完成進度和領取狀態僅保持當天，隔天刷新。

業務分析

在開發前需要對需求進行整理，對細節進行確認，然後設計解決方案，預估開發時間，這裏將對於業務中核心的內容進行梳理：

1. 用戶想要完成任務，需要去操作其他業務功能，如：評論成功後需要完成每日評論任務，關注主題後完成關注新手任務，這裏就涉及核心問題， 任務需要依賴於其他業務

2. 爲了保障後續拓展性， 任務需要支持後臺管理 ，配置任務名，描述，任務類型（每日，新手，活動），完成次數，獎勵積分數量，去完成跳轉uri 等

3. 用戶完成任務後不用自動領取獎勵，需要進入到任務列表點擊領取操作，可領取時導航Tab需要小紅點提醒，和產品確認任務的完成和提醒的用戶體驗 可以接受短時間延遲

4. 用戶多次操作業務，或者出現重複操作（惡意併發請求刷積分），保證任務只能完成一次並且只能領取一次獎勵， 需要保證冪等性

方案設計

核心目標：

1. 任務依賴其他業務，需要進行解耦，不影響其他業務的功能和性能
2. 設計後臺可管理，便於後續拓展
3. 抽象任務模塊，代碼抽象開發
4. 完成任務和領取需要保證冪等性
5. 高可用

名詞定義：

事件

• 任務中涉及依賴其他業務，這裏需要抽象出一個概念，用戶通過操作業務，完成任務的這個操作，我們把這個過程定義爲用戶完成任務事件觸發完成，如：評論事件，點贊事件，關注事件，等

解決方案：

在實現方案上，採用異步消耗隊列的方式，依賴業務接口埋入事件上報，將用戶成功操作業務的任務事件上報到隊裏中，然後開發消息消耗的腳本程序，對消息中用戶觸發的任務事件進行業務邏輯處理和DB操作，更新用戶任務進度和可領取狀態，響應給用戶(完成任務紅點提醒)，設計圖：

• 依賴業務解耦
  • 依賴業務將操作成功用戶的任務事件上報到消息隊列，然後程序進行異步消耗
  • 方案解決了依賴業務之間的強耦合，並且基本不影響現有依賴業務的接口性能
• 高可用：
  • 通過調度系統啓動多進程對隊列進行消耗
    • 進程守護系統，守護進程保活，奔潰重啓，可對執行日誌進行記錄與查看
    • 如： gocron
  • 消息隊列監控，無法及時消耗進行預警，保障即時性，避免長時間的延遲
    • rabbitmq
    • redis list
    • … …
  • 容錯與補償
    • 隊列消耗失敗需要進行記錄，並可根據業務場景，通過另外程序進行補充處理
    • 用戶操作業務上報任務事件不限制次數，以免用戶沒完成任務，允許用戶重新嘗試去做任務，程序消耗需要控制任務只能完成一次

表結構：

-- 任務表
CREATE TABLE `task` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增',
  `icon` varchar(300) NOT NULL DEFAULT '' COMMENT '圖標',
  `title` varchar(30) NOT NULL DEFAULT '' COMMENT '任務標題',
  `type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '任務類型，新手任務=1,每日任務=2',
  `event` int(11) NOT NULL DEFAULT '0' COMMENT '事件',
  `des` varchar(30) NOT NULL DEFAULT '' COMMENT '任務描述',
  `target_num` int(11) NOT NULL DEFAULT '0' COMMENT '目標數量',
  `points` int(11) NOT NULL DEFAULT '0' COMMENT '金幣',
  `sort` int(11) NOT NULL DEFAULT '0' COMMENT '排序',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '狀態 0=下線，1=上線，-1=刪除',
  `app_version` varchar(15) NOT NULL DEFAULT '' COMMENT 'app版本號',
  `app_version_compare` varchar(10) NOT NULL DEFAULT '' COMMENT 'app版本號比較運算符',
  `operator` varchar(10) NOT NULL DEFAULT '' COMMENT '操作人',
  `jump_uri` varchar(300) NOT NULL DEFAULT '' COMMENT '跳轉協議',
  `create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間',
  `update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新時間',
  `event_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '事件開始時間',
  `event_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '事件結束時間',
  `task_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '任務開始時間',
  `task_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '任務結束時間',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 用戶任務情況表
CREATE TABLE `user_task_case` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用戶任務情況',
  `user_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '用戶ID',
  `task_id` int(11) NOT NULL DEFAULT '0' COMMENT '任務id',
  `task_type` int(11) NOT NULL DEFAULT '0' COMMENT '任務類型',
  `event` int(11) NOT NULL DEFAULT '0' COMMENT '事件',
  `task_uni` varchar(30) NOT NULL DEFAULT '' COMMENT '任務唯一標識(唯一約束) ',
  `target_num` int(11) NOT NULL DEFAULT '0' COMMENT '目標數量',
  `finish_num` int(11) NOT NULL DEFAULT '0' COMMENT '完成數量',
  `points` int(11) NOT NULL DEFAULT '0' COMMENT '可領取金幣數量',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '狀態 0=待完成，1=待領取，2=已經領取',
  `finish_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '完成任務時間',
  `get_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '領取時間',
  `create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uni_user_id_task_uni` (`user_id`,`task_uni`) USING BTREE,
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 COMMENT='用戶任務情況表';

更新語句：

-- 更新領取狀態，注意：WHERE條件，強校驗
UPDATE user_task_case 
SET  `status`=2,finish_at=CURRENT_TIMESTAMP
WHERE id=:id AND user_id=:user_id AND `status`=1 AND finish_num>=target_num

表重點字段說明：

• task_uni
  • 任務唯一標識
• user_id和task_uni 組合唯一約束索引
  • 每日任務：
    • 任務id_任務類型_日期（task_id_type_date）
  • 默認都是隻做一次(新手任務/活動任務)：
    • 任務id（task_id）
• 冪等性
  • user_task_case 表中 user_id和task_uni 組合唯一約束索引，通過mysql的唯一約束，保證了多進程並行消耗事件隊列的情況下，每日任務和一次性任務不能重複INSERT
  • 通過UPDATE的WHERE條件校驗保障領取的冪等性

管理後臺：

產品在規劃需求的時候會設計出相關後臺，但是不一定設計的合理，所以這裏需要根據確認的解決方案協助產品對於管理後臺進行調整，保障後續的拓展性

代碼層面：

• 面向抽象開發，合理使用設計模式，便於後續的拓展

話外篇：

談近一年的感悟，近一年參與了新APP項目的開發，從0開始搭建項目，看着DAU一點點兒的漲起來，還是挺有成就感的。

角色上產生了變化，現在感覺自己更像是一個項目的參與者，而不是任務的執行人，完成業務開發的同時也會對產品上有根深瞭解。

空閒時間也會對競品調研以及用戶使用意見或者問題進行跟進，站在用戶角度提供產品上的一些建議。

後續會把新項目開發過程中遇到問題或者常見的業務場景下的解決方案進行梳理出來進行博文分享。

首發於Github： :rainbow:大話WEB開發 ，歡迎star :heart_eyes_cat:

有任何想說的請留言哦

轉載請申明原文地址，謝謝合作

Follow @sflaqiu

相關文章