君弘研究 · 直播控台 — 逻辑看板

把保利威(PolyV)直播能力整合进期货公司自有系统,覆盖「预告 → 直播间 → 回放」全生命周期,并叠加期货业合规闸门(适当性 C1–C5 + VIP 三档)。本看板只画大逻辑:做什么、流程怎么走、关键规则是什么。
业务设计成熟 工程:可演示,鉴权/回放未闭环 v3.0 基线 · Flask+SQLite+PolyV
00

全景时序:四角色怎么配合

一张图看懂全链路谁在什么时候做什么。竖线 = 时间推进(计划开播时间 T 为中心)。
sequenceDiagram
    autonumber
    participant O as 运营
    participant S as 系统定时任务
    participant P as 保利威 PolyV
    participant V as 观众
    O->>S: 建预告(绑直播间·配板块/品种/适当性/VIP)
    O->>P: 建/编直播间→创建频道(v4)
    Note over S: T-30min 扫描开播窗口
    S->>S: 备份直播间原信息
    S->>P: 注入预告信息到直播间
    S->>S: 命中检测(实际开播在 T±20min 内)
    P-->>V: 直播推流
    alt 命中
        S->>V: 推送开播提醒
    else 未命中
        S-->>S: 预告失效
    end
    Note over S: T+30min
    S->>P: 恢复直播间原信息
    P->>P: 自动生成回放(继承板块/品种)
    V->>P: 回放中心观看
01

预告创建流程

运营在自有控台建一条预告,绑定已有直播间,配置分类与合规门槛。系统据此自动计算状态与命中状态。
flowchart TD
    A["填写预告表单
标题/封面/简介/富文本
关联直播间/板块/品种/适当性/VIP/计划时间"] --> B["写入 Preview 表
落库保存"] B --> C{"状态按时间自动计算"} C -->|未到开播| D[pending] C -->|开播后2h内| E[live] C -->|超2h| F[ended] B --> G{"命中判定
实际开播在 T±20min 内?"} G -->|是| H[hit] G -->|否| I[missed] D --> J["列表/分享
筛选·编辑·复制链接"] E --> J F --> J H --> J I --> J
关键规则
状态机idle/live/ended/pending —— 由计划开播时间与当前时间自动推导
命中窗口预告 ±20min:实际开播落在窗口内 = hit,否则 missed
必填关联直播间为必填项,预告本身不持有流,流在直播间
属性继承板块/品种 预告 → 直播间 → 回放 全链路继承
02

预告 → 直播间(自动注入)

这是系统自动化核心:开播前自动把预告信息"注入"到直播间展示,开播后自动恢复。运营无需手工搬运。
flowchart TD
    A["定时任务扫描 T-30min"] --> B{"进入注入窗口?
T-30 ~ T+30"} B -->|否| A B -->|是| C["备份直播间原信息"] C --> D["注入预告信息到直播间
进入注入状态展示"] D --> E{"命中检测
实际开播在 T±20min 内?"} E -->|命中 hit| F["推送开播提醒给预约用户"] E -->|未命中 missed| G["预告失效 不推送"]
关键规则
注入窗口开播前 30min ~ 开播后 30min;入窗前先备份,出窗后恢复
命中窗口预告 ±20min;命中才通知预约用户
恢复窗口结束(T+30min)自动把直播间恢复为原信息
优先级属性流转不可丢:板块/品种必须随注入→恢复完整回滚
03

直播结束 · 恢复 · 回放生成

直播一结束,系统先恢复直播间原貌,再自动沉淀回放内容,让"一次直播"变成"可检索的长期资产"。
flowchart TD
    A["直播结束 T+30min 窗口末"] --> B["恢复直播间原信息
用备份覆盖"] B --> C["自动生成回放
PolyV 录制完成→拉取"] C --> D["继承板块/品种"] D --> E["回放中心可检索观看
点击走权限验证弹窗"]
⚠ 当前工程缺口:回放(VOD)的 PolyV 授权闸门未实现——只做了直播的 custom auth,回放能否看目前不受适当性/VIP 约束。需在 VOD 播放前补一道同源鉴权(见 ⑤)。
关键规则
恢复时机注入窗口结束(T+30min)自动恢复,不依赖人工
回放继承板块/品种 从直播间继承到回放,分类保持一致
存储回放独立存储,可检索,与直播间解耦
04

控制台 · 创建直播间(保利威集成)

运营在控台建/编直播间,系统把配置同步到保利威真实频道,并把频道地址回填到本地库。这是"自有控台替代保利威后台"的关键。
flowchart TD
    A["运营建/编直播间
三层字段:原生/默认/生效"] --> B["调 PolyV v4 /channel/create
返回频道号"] B --> C["回填频道ID/密码
basic/get 拉推流/观看地址"] C --> D{"观看条件设为?"} D -->|custom| E["指向本系统授权回调
走合规闸门 ⑤"] D -->|无/白名单/密码/等级| F["PolyV 原生限制
不走自定义回调"]
⚠ 当前工程缺口:① 创建频道后漏调 basic/get,导致推流/观看地址字段为空;② 创建时未把频道观看条件设为 custom,PolyV 根本不会触发授权回调——合规闸门从源头没接上(修复见迁移方案 P0)。
关键规则
三层字段保利威原生 / 管理台默认 / 当前生效(优先级递增覆盖)
创建接口v4 /channel/create;签名 MD5(appSecret+升序拼接+appSecret).upper()
地址回填创建不返地址,必须再调 basic/get 拉推流/观看地址
观看限制无 / 白名单 / 密码 / 等级 / custom(自定义授权)
05

观众侧 · 自定义鉴权(合规闸门)

期货投教硬合规:观众能否看,必须在服务端按真实身份校验适当性/VIP。这是整个系统最不能出错的一环。
flowchart TD
    A["观众进入 /watch/id
前端骨架屏→房间卡"] --> B["PolyV 触发 custom auth 回调
携带 id + ts"] B --> C["校验回调签名
MD5(secret+id+secret+ts)"] C --> D{"适当性不低于最低
且 VIP 不低于最低?
适当性优先"} D -->|通过| E["回签 MD5(secret+id+secret+ts+secret+userid)
放行播放"] D -->|拒绝| F["403 适当性不足 / VIP不足
用户不存在 / 网络异常"]
⚠ 当前工程缺口(最高危):代码取"第一个活跃用户"直接放行,不识别真实观众身份——等于任何人都能看。同时频道侧没设 custom(见④),回调都未必会触发。修复:按观众真实 userid 查其适当性/VIP 再判定(迁移方案 P0)。
关键规则(合规口径,不可改)
适当性排序C1 < C2 < C3 < C4 < C5(风险承受递增)
VIP 排序空 < 君研(junyan) < 君行(junxing) < 君尊享(junzunxiang)
优先级适当性 > VIP;未设时回退 suit_level / vip_tier
强制点校验必须在服务端,不能只靠前端隐藏(监管口径)
06

数据模型速查(6 张表)

一眼看清系统落了哪些数据。核心是 Preview(预告)与 Room(直播间)的全链路属性流转。

Team 团队

  • id 主键
  • name 团队名
  • 研究员归属分组

Researcher 研究员

  • id
  • name
  • team_id 外键
  • 作为直播间主播

Preview 预告

  • id
  • room_id 关联直播间
  • 板块/品种/适当性/VIP
  • 计划开播·状态·命中

Room 直播间

  • id
  • channelId/密码/推流/观看
  • 三层字段结构
  • 观看限制·启用·WEB

User 用户

  • id
  • suit_level 适当性
  • vip_tier VIP
  • 当前为模拟登录

room_researchers 关联

  • room_id
  • researcher_id
  • 多对多主播映射