2021直播营销技术方案-CSDN博客

本文链接：https://blog.csdn.net/Mengbabe_2018/article/details/139421502

文章目录

背景
抽奖
- 系统调用图
- 时序图
分享有礼
- 时序图
分表

背景

B端注册客户160万、7.8亿C端用户，1000万人最高同时在线。商家可以购买服务建立自己的线上店铺，进行商品的销售、推广，录制课程，直播。
在这里插入图片描述

慕课付费资源网站 https://www.92ydl.com/1152.html

抽奖

系统调用图

参与抽奖主要流程：

⽤户参与抽奖活动
业务测在达到抽奖条件之后进⾏抽奖
业务测把需要抽奖的序号和需要抽取的⼈发送给抽奖服务测
抽奖服务抽出奖品，通知业务测
业务测发放奖品

时序图

1、⼿动开奖
从redis集合中获取活动的参与者数据
从数据库去查询活动的奖品数据
随机匹配参与者和奖品，并将结果存⼊数据库中
将开奖结果返回给业务侧
2、⾃动开奖：（定时脚本：每秒执⾏⼀次）
获取这个时间点需要开奖的抽奖活动数据
从redis集合中获取活动的参与者数据
从数据库去查询活动的奖品数据
随机匹配参与者和奖品，并将结果存⼊数据库中
在这里插入图片描述

分享有礼

时序图

讲师端发起分享有礼活动
在这里插入图片描述

生成带有活动ID的分享链接逻辑
在这里插入图片描述

分享有礼写入关系核心逻辑
在这里插入图片描述

分表

一、背景

数据分析c端实例数据库 db_ex_crowd 的数据表 t_crowd_user（人群用户表）月底数据达六十多亿，数据太多，单表内存占用近3T。拆表主要推动力为：腾讯云推荐实例存储为不超过3T, 运维现在是放宽了，历史最高到了6T, 如果数据量继续增长下去，容易出现不可控风险。其它：影响了正常业务查询的速度等。

此表其他情况：这个表是由大数据写入的，用来统计人群。人群每次更新，全量写入，更新多次写入多次信息，里面就会出现很多过时的无效的记录。现在大数据的做法是每个月底跑脚本从此表中统计出最近的每一个人群的信息进新表，然后重命名此表为其它名称，新表命名为 t_crowd_user, 待旧表没用后删除，这样此表每月初数据量是不多的。

2011-11-30 20:59 此表情况如下：

在这里插入图片描述

二、项目目标

将数据分析c端实例db_ex_crowd.t_crowd_user（人群分组成员表）表拆分并迁往新的实例，提供接口对该表的操作供外界其他项目使用（收归），解决掉该表过大引起的问题。

三、拆表方案

将t_crowd_user 按人群自动更新和手动更新拆为两类，人群分组成员表-手动，人群分组成员表-例行。人群例行更新的再按天分表（例行更新每天都会产生数据）。然后按app_id将其按crc32算法分成0-99共100个表（eg: fmod(sprintf(“%u”, crc32($app_id)), 100);）。这样手动更新就是100张表，自动更新每天100张表。自动更新的按业务需要可以保留最近7天的，其他的定时删除(删除前备份)。这样就解决了数据量大的问题，而且直接删表不会引起单表大量删数据带来的问题，比如主动同步。拆表后需要查找指定人群的用户信息，故需要在现有的 t_crowd 表加两个字段,trigger_compute_type，compute_day，一个是记录此人群更新时的触发方式(手动or例行)，另一个是记录更新时的时间。这样，如果需要查找对应人群的成员信息，先去t_crowd表查到 trigger_compute_type, 和 compute_day, 然后就可以锁定对应的人群成员表了。

trigger_compute_type(字段名待定)：此人群更新时的触发方式(手动or例行)。

compute_day(字段名待定)：更新时的时间。

现有手动更新人群和例行更新人群人员数量的统计如下：

每天需要例行更新的人员有 2亿多。