直播互动任务怎么设置
做直播的都知道，观众刷个弹幕、点个赞、抢个红包，后台其实都在跑任务。这些看似简单的互动，背后离不开数据库的支持。很多人以为互动任务就是前端的事，其实真正要稳定运行，得靠数据库层面的设计和调度。
先想清楚要支持哪些互动
比如常见的抽奖、答题、倒计时打卡、连麦排队，每一种都是一个任务类型。在数据库里，可以用一张 interactive_tasks 表来统一管理：
CREATE TABLE interactive_tasks (
id INT AUTO_INCREMENT PRIMARY KEY,
task_type ENUM('lottery', 'quiz', 'countdown', 'queue') NOT NULL,
title VARCHAR(100),
start_time DATETIME,
end_time DATETIME,
status TINYINT DEFAULT 0, -- 0未开始 1进行中 2已结束
extra_data JSON,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);这样一条记录就能代表一个正在或即将发生的互动任务。比如抽奖任务，extra_data 可以存奖品列表；答题任务可以存题目ID数组。
任务触发靠定时器还是事件驱动？
很多人直接用程序轮询，每隔几秒查一次数据库有没有新任务要启动，效率低还容易漏。更合理的做法是结合数据库事件（MySQL Event Scheduler）加应用层消息队列。
比如在 MySQL 中开启事件调度器：
SET GLOBAL event_scheduler = ON;然后创建一个每分钟检查一次的任务触发器：
CREATE EVENT check_active_tasks
ON SCHEDULE EVERY 1 MINUTE
DO
UPDATE interactive_tasks
SET status = 1
WHERE start_time <= NOW()
AND status = 0;
状态一旦变成“进行中”，就可以通过监听 binlog 或调用 webhook 通知直播系统加载该任务。
用户参与数据怎么存
用户点了“参与抽奖”，这个动作必须快速写入。这时候不能只靠主库，否则高并发下会卡。建议拆出一张 user_task_logs 表，并按直播场次分表，比如 user_task_logs_20241015。
CREATE TABLE user_task_logs_20241015 (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
task_id INT NOT NULL,
action_type TINYINT, -- 1:参与 2:答题正确 3:获奖等
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user (user_id),
INDEX idx_task (task_id)
);这种结构既方便统计参与人数，也能快速查出某个用户是否已参加过任务。
实时反馈怎么实现
比如答题倒计时结束，系统要立刻公布结果。可以在任务结束时，由数据库触发一个存储过程，计算中奖名单并写入 task_results 表：
DELIMITER ;;
CREATE PROCEDURE finalize_quiz_task(IN task_id INT)
BEGIN
INSERT INTO task_results (task_id, user_id, result_value)
SELECT task_id, user_id, 'correct'
FROM user_task_logs_20241015
WHERE task_id = task_id AND action_type = 2;
UPDATE interactive_tasks SET status = 2 WHERE id = task_id;
END;;
DELIMITER ;前端再通过 WebSocket 拿到结果，就能实时展示“恭喜以下用户答对”了。
实际操作中，还可以把高频读写的任务数据缓存到 Redis，比如用 SET task:123:status "active" 来标记状态，数据库只做持久化落地。这样整个互动流程才扛得住万人同时点击。
直播不是秀技术，但没技术真撑不起来。把互动任务的数据库结构理顺了，直播间才能既热闹又稳当。