直播的同时，腾讯云的点播系统还会实时进行录制。录制的时候，会产生多个录制文件分片。结束之后，会把分片拉回到本地，重新对这些分片进行视频对齐，会重新进行布局、调整，包括分辨率调整，然后插帧补流，当有视频断流时，会插入带有课堂logo的静态画面，保证音视频的连贯性。最后重新生成定制的回放文件。这样学生看录制回放的时候，能有一个连贯性的观看体验。
最后是录制的方式。录制这边学生端也支持录播一路的方式或者录播多路的方式。PC端由于家庭带宽足够稳定，我们采用的是录播多路的方式。路过多路的方式在客户端可以做很多定制化的需求。比如回放过程中，PC客户端可以动态调整画中画和ppt的切换，分辨率或布局的调整。
以上就是在线教育课堂结合腾讯云音视频产品的实践。我们运用了腾讯云提供的的互动直播、直播、点播、CDN加速、视频加密的一整套解决方案。应用了腾讯云一整套解决方案，我们还需要做的事情就很少了。现在腾讯内部CTO和公司总办们也在大力推广技术整体上云的发展战略。我们也积极响应领导的号召，积极上云，这样可以大大减少音视频这块的运营和维护成本，可以把更多的精力聚焦于产品打磨，给老师和学生有一个更好的产品体验。
房间系统架构房间系统的架构请观看下面的流程，它分几个模块。首先是接入层，进出代理服务接入客户端请求，并把请求转发给心跳服务和成员列表进行状态存储。接着是逻辑层，它包括很多课堂交互的功能，比如学生举手、聊天区、红包互动等等，每个交互行为会产生一个消息，通过push代理服务把消息转播给其他老师和学生。
房间系统在开发过程中我们遇到三大挑战。心跳服务，成员列表，因为并发量非常大，那怎么做到平滑扩容？怎么保证服务的可靠性和可用性，还有容灾怎么做？另外消息push服务，怎么保证通用性和易用性，怎么保证消息的可靠性？在消息并发量高的时候，怎么解决消息风暴导致服务过载的问题？下面分别讲一下这三个模块我们的一些优化实践。
心跳服务优化心跳服务优化之前，它采用msgq接入（msgq是腾讯自研的内存消息队列），采用双机单进程模型。这个方案实践简单，在项目初期的时候能够满足业务快速上线，但随着用户量越来越大，现在已经无法支撑现在业务的实现。它现在有几个问题，高峰时期容易丢消息，当系统消息量突然间增大的时候，msgq缓冲队列到达上限或者msgq服务异常就有丢消息的风险。第二，逻辑复杂、不通用，比如超时检查、多终端登录需要定制开发。第三，因为心跳服务要保存目前的心跳状态，现在双机相互同步的方案无法扩容。基于这三个问题我们做了新的优化。
下面是新版的优化方案。 我们把心跳服务的架构分了两层，心跳代理heart_proxy和心跳存储服务heart_svr， 然后通过L5服务进行路由。L5是什么呢？L5是腾讯内部的路由决策服务。
新版的心跳服务要解决4个问题。1、服务扩展性。2、保证服务的可靠性。3、通用性设计。4、踢人检测，避免误踢。
扩展性方面，扩展性我们怎么做呢？我们解决方案是引入了一致性哈希算法。根据业务bid+房间roomid+用户qq进行hash，把请求路由到指定的heart_svr进行存储。
可靠性方面，当某一个心跳存储节点挂掉的话，L5服务会在1分钟之内发现，并把此台机ip剔除。Proxy就会把它路由到其他正常节点上面去。通过这个方式，来保持心跳状态的继续维持。
通用性设计方面，我们现在有课堂和辅导两款产品，后面可能还有其他新产品出现。每一款产品都涉及到心跳的功能，所以我们预先把心跳服务作成一个通用的服务，引入业务号Bid的方式，这样多个产品可以套用同一套心跳服务，以此解决多个产品的共用问题。
踢人检测方面，很重要的一个点怎么避免误踢？比如学生正在上课，突然间被踢出课堂，就会引起学生的反馈，对学生造成不友好的体验。所以一个心跳存储节点发现某一个用户超时的时候，会给heart_proxy发起反查，heart_proxy会把查询请求广播给所有heart_svr存储节点，通过这种方式来保障踢人安全。
成员列表服务优化