大話業務場景與解決方案-作任務

背景

多數的移動端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 : [