Go, MySQL, Redis, Hive
功能：当活动触发时，会在屏幕上有大量带有装饰的弹幕展示，活跃直播间气氛。引导用户向主播发评论祝福，强化用户-主播关系。
在项目中的职责：评论狂欢链路服务端owner, 研发。
关键成果：从0到1建设了评论狂欢活动功能，支持狂欢道具触发，特定直播间定时触发，特定直播间人气触发，对直播评论渗透和直播看播时长起到正向作用（0.05%， 0.04%）。
解决的问题：
- 多种触发模式。
- 不同类型直播间触发限制。
- 触发频控多变。
- 狂欢样式多样化。
- 狂欢任务唯一性。
解决方案：
- 狂欢样式模板配置化。
- 定时任务配置化。
- 狂欢任务幂等。
- 主播白名单限制。
收益：
- 从0到1建设了评论狂欢活动功能。
- 配置化狂欢样式，快速支持活动任务。
- 狂欢任务配置化。
- 对直播评论渗透和直播看播时长起到正向作用（0.05%， 0.04%）。
挑战
- 如何保证消息下发稳定性
需要保证消息不能漏发，也不能多发。
对于送礼触发的任务，采用消费消息队列的形式触发，加上发送消息重试机制保证发送成功率。
消息平台有消息幂等机制，对于同一id的消息最多只发一次。
对于发送失败的消息，消息平台保证4个9，如果3次重试还无法成功发送。大概率是名师有问题，此时需要人工干预。活动是实时性的，所以对于失败的消息，后续发送也无意义。
对于定时任务消息，每5秒钟分轮询一次5秒钟后将要发送的消息。发送方式与上述相同。
- 定时任务设计难点
对于定时任务的要求是客户端上需要在特定的时间触发效果。如果是在活动开始时才发送消息，由于网络时延，不可能准确做到在某时刻触发特效果。
提前下发消息：我的做法是提前5秒钟下发消息，客户端根据消息中的开始时间准确开始活动。
- 模板配置设计考量
现在3种运营方式：特定房间在某时刻发送，特定房间在达到一定uv后发送，送礼发送。
模板需要支持可复用，可以快速配置。
配置数据结构
// 模板列表
{
"模板1":{
},
...
}
// 主播pv配置
{
主播id:{
model_id:"模板1",
pv:500000
}
...
}
// 定时任务
{
{
"start_time":2022-01-02 09:00:00,
"model_id":"模板1",
"user_id":[1,2,3], // 触发的主播房间
...
}
...
}
