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], // 触发的主播房间
		...

	}
	...
}