大話Synchronized及鎖升級

背景

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

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

業務分析

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

1. 用戶想要完成任務，需要去操作其他業務功能，如：評論成功後需要完成每日評論任務，關注主題後完成關注新手任務，這裡就涉及核心問題，任務需要依賴於其他業務
2. 為了保障後續拓展性，任務需要支持後臺管理，配置任務名，描述，任務類型（每日，新手，活動），完成次數，獎勵積分數量，去完成跳轉uri 等
3. 用戶完成任務後不用自動領取獎勵，需要進入到任務列表點擊領取操作，可領取時導航Tab需要小紅點提醒，和產品確認任務的完成和提醒的用戶體驗 可以接受短時間延遲
4. 用戶多次操作業務，或者出現重複操作（惡意併發請求刷積分），保證任務只能完成一次並且只能領取一次獎勵，需要保證冪等性

方案設計

核心目標：

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

名詞定義：

事件

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

解決方案：

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

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

表結構：

<code>-- 任務表
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='用戶任務情況表';/<code> 

更新語句：

<code>-- 更新領取狀態，注意：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/<code>

表重點字段說明：

• 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條件校驗保障領取的冪等性

管理後臺：

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

代碼層面：

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

作者：SFLYQ
鏈接：https://juejin.im/post/5e8aa3306fb9a03c3912e99e

閱讀更多 妖精的雜七雜八 的文章

關鍵字: Redis 升級 設計