背景
在项目整体上线运营之后，直播的基础框架底层基本已经搭建完毕，在运营期间需要不断的创造营收和刺激打赏，这就需要通过迭代大量的活动和玩法来完成。
目标导向
在创造营收这期间如果活动、玩法等一开始没有进行抽象处理和设计，势必会让技术债务越来越重，当然在产品/运营看来，前期MVP版本的迭代是他们的期望，在最短的时间撸出MVP版本去验证才是他们的目标导向，而对于技术而言，制造工具让他们用最短的时间完成MVP版本验证且保证高质量交付才是目标导向
设计思路
1.可视化的界面配置
思路
- 在运营后台植入活动模块
- 可以自由CRUD活动的配置、类型、日、周、月榜单等
- 可以自由上传更新活动的设计图、活动位配图等
- 可以自由生成静态页面的配置，比如配置玩法说明页、规则页等，配置后生成链接，链接即刻生效
2.人性化的校验机制
思路
- 用户输入的校验提示
- 配置正确与否的校验
- 目标奖励正确与否的校验
3.多地区并行的适配
思路
- 支持不同地区运营同一活动
- 多时区下同一活动的处理
- 多语言的配置
4.长期可扩展的接口设计
思路
- 引入版本号机制的兼容接口设计
- SDK模块化设计
5.高性能抽象化的榜单统计
思路
- 工厂、策略模式抽象化榜单
- 巧妙运用redis实现高性能榜单统计
6.高可用严谨的发奖模式
思路
- 发奖任务集群
- 发奖一致性保证
- 发奖并发处理
7.可观测的数据大盘
思路
- 活动数据埋点服务
- 投放平台上报
- 冷热数据存储与查询方案
- BI数据聚合统计
总结
- 活动平台适用于需要多次重复举办的活动，比如每周一次/每月一次/长期的活动
- 可视化的配置能提高运营人员的生产力，提升配置体验
- 人性化校验机制能及时洞悉配置正确与否，这显得极为重要，尤其突出在奖励方面，特别是一些大活动，设计的奖励类型，数量非常之多，如果单纯靠填写ID方式不做校验，可能会造成严重后果
- 多地区的设配能有效拉动营收，在活动预热期间可以一个活动多个地区一起预热上线，直接提高了运营效果。
- 扩展接口设计能兼容不同版本的活动、客户端正常运行。
- 高性能榜单统计利用了Redis zSet数据结构的优势，优雅轻松实现榜单数据的实时统计，对于大Key也可以进行冷热Key处理和分Key统计
- 高可用严谨发奖模型利用了XXL-JOB集群高可用的优势触发发奖任务，利用状态位设计结合分布式锁、乐观锁等实现发奖的一致、准确性。
- 可观察的数据大盘提供了实时数据聚合查询、冷数据统计收集统计，整个数据分析对运营/产品显得极为重要，是用来衡量活动效果、期望值的绝佳杀器。