教学直播概括

不同于常规的主播互动直播；教学直播，面向k12人群，

前期会有课前的准备工作比如课程创建，学生购买数据，老师课件，试卷题目的准备；

双师模式：学生会分配给不同的辅导老师，辅导老师会对学生进行分班处理，课中也会有学生选组上课互动的场景，辅导老师也可以给学生上课，也会在后台进行跟课，监督学生上课；

相对于常规的主播互动，会模拟线下上课的场景到线上课中直播，形成一套线上教学直播间场景模式

业务发展：

课中直播是按章节维度进行直播交互的，一个章节一个直播间；

随着业务发展，出现了一个章节多个不同直播间的场景（出镜），多个章节共享一个章节直播间的场景(共享直播间）； 一个章节有2个相同课中主讲直播间的场景（旁听）; 后面根据业务需求衍生出其他组合玩法；

上课业务流程介绍：

售卖侧建课：售卖老师在售卖后台新建课程章节，定义课程章节的属性，形成售卖商品上架；

学生侧购买报名：学生在售卖页面可以购买课程章节上课，或者0元课扫二维码直接购买报名上课；

辅导侧： 根据上课用户的年龄段进行分类：低幼，班主任，督学，0转化督学；对报名的用户课前排灌班，以大班/小班/小组的组织形式上课；

教学直播课前预热：

1. 将当天课前准备的课件，试卷题目，课程章节老师辅导相关的等非状态非易变接口数据在上课之前预热至缓存中；因为课中上课是突发流量场景，减少对后台接口db的并发压力； 对课中不会变的接口数据可以加上本地缓存，提高相应吞吐效率；(读多写少场景接口，cache-aside模式）
2. 课前对课中异动易变数据需要直播间缓存，业务组织缓存等初始化缓存数据；提供给课中互动场景使用；后面通过业务策略绑定，把业务组织数据抽象一个课中理解的数据模型，直播间缓存， 组织树节点缓存，学生所在直播间节点缓存等初始数据；（基于这个课中缓存数据模型，进行编码，隔离业务属性）
3. 对于异动状态易变更新频繁的接口直接课中缓存交互，异步落盘，降低相应延迟减少对后台接口的读写压力；（写多频繁场景接口，write-behind模式）

教学直播课中互动：

1. 不同用户角色直播链路
   1. 老师端：初始化直播间(配置加载，不同的互动ui, 互动功能是否可用，流媒体appid/token)→ 加载课件(cocos资源) →进入直播间 → 通过流媒体推流拉流/连麦/通过长链接发送聊天消息和信令→互动（发题目/答案/红包/奖励）→ 切换直播间(辅导出镜)/结束直播
   2. 学生端：初始化直播间(配置加载，流媒体appid/token, 流程配置)→加载资源(cocos互动资源包/ai模型资源包)→签到/分组→进入直播间→通过流媒体拉流推流/连麦/通过长链接发送聊天消息→互动（发题目/答案/红包/奖励/pk）→ 退出直播间
   3. 辅导跟课后台：进入跟课后台→ 进入直播间→通过流媒体拉流/通过长链接发送聊天消息→处理报警/遮盖/鉴黄/标记→直播结束获取计算好的学生到课时长，作答率，出勤率，完课率等
2. 互动依赖长链接，答题，pk等场景，都有开始到结束的过程，对每个互动场景用互动id来管理生命周期，涉及金额的互动，需要考虑黑产的影响，需要对答案加密，以及金额的提前计算预热和防止多发少发，互动读写接口尽量细化，防止读写io多在同一个接口中；尽量把计算放在用户端来处理， 比如 答题是否成功，pk是否赢了等，分散服务端流量压力；(原则：统一管理互动类型，可配置化，细化io, 计算前置,分流)

教学直播课后回放：

1. 建课后直接根据绑定的策略直接生成直播间，提供回放数据，比如素养课，伪直播
2. 课中的回放数据，会有直播间和用户互动最终状态数据落库
3. 回放数据是不会更改，读多写非常少的场景，缓存直接通过cache-aside的模式缓存db后台接口数据

教学整体概括架构

​ 底层的基础建设比较重要(高效能)；上层业务的发展离不开基础组件的稳定性(高可用)；以及服务多了之后，如何高效快速迭代，上线之后保证整体服务性能的稳定性(高并发/低延迟/可监控/可配置)； 以及服务模块之间的划分合理，细化出功能组件，异动业务代码的可维护性（低耦合高内聚）；这些都需要理论知识加以指导(比如服务划分抽象原则DDD, 业务抽象设计原则SOLID)，以及实践场景中去平衡折中改进；没有永恒的银弹(内卷)，尚需不断迭代提高。一个字 “稳”。

references