CN110225021A - 网络直播方法及装置 - Google Patents

Abstract

本申请提供了一种网络直播方法及装置，其中，该方法包括：接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。采用上述方案，通过网络直播的方式进行少儿编程教学，大幅降低学习少儿编程的成本与门槛，解决了相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，推动了全民提升编程水平。

Description

网络直播方法及装置

技术领域

本申请涉及但不限于网络教学领域，具体而言，涉及一种网络直播方法及装置。

背景技术

在相关技术中，少儿编程犹如异军突起，而且这股热风已经愈刮愈烈。据资料显示，在科创教育细分赛道上，少儿编程的案例数和金额数均为最多，人工智能成为全球瞩望的焦点，而“编程学习”作为通向人工智能不可或缺的“基础能力”也一再成为热门关注。

现如今，时代技术爆点层出不穷：AR(Augmented Reality，增强现实技术)，VR(Virtual Reality，虚拟现实技术)，AI(Artificial intelligence，人工智能)等等都向我们宣告了新时代的到来。机器越来越强大，我们人类要赢过机器，就只能在创意能力和想象力方面突围，而编程的逻辑还有助于开拓思维，激发人类更多创造力。所以编程不仅能让我们去操控机器，还能帮助我们不被机器所操控。

尤其是对于成长在今天的孩子们来说，电脑就和书本、画笔一样，是日常学习和生活的普通工具，学习编程正是学习运用这些普及于生活的科技工具表达自己创意的过程。而且随着AI技术逐步渗透我们生活的方方面面，我们就更多地需要掌握“编程”这一项技术来与“人工智能时代”沟通。掌握这一通行语言，就好比在经济全球化的今天掌握了英语一样。正是因为如此，编程教育已和英语、汉语言文学等一样正式进入K12(基础教育)赛道，它很可能成为其中的一匹新的黑马。

各种计算机语言的广泛应用，包括Java、C++、Python、JavaScript等高级语言在社会生产中得到广泛的使用，同时也衍生了大量的计算机编程成人培训机构，少儿编程培训机构也大量涌现，少儿编程教育软件也应运而成。

但是，目前的少儿编程教育软件功能普遍比较单一，大多以游戏与动画风格为主，而这样的风格本身并没有什么不好，能很好的吸引青少年编程爱好者。如果，我们能在游戏和动画的基础上，增加在线视频讲解，并以问答形式每天发放小礼物会更加吸引更多的青少年加入“小小程序员”的行列。

理想往往都很丰满，现实却骨感。少儿编程行业依然存在诸多痛点，“大好趋势已来，但如今技术、人才及相关的配套服务却还难以跟上”使它陷入了一个“冰火两重天”的尴尬的境地。而这也会直接导致了市场培育的战线拉长，难度增加。

首先，很多家长本来就对于少儿编程的理解不足，他们并不了解学这个对于孩子的成长发展有什么必要性。甚至有部分家长认为这一项目更适合男孩子学习。持观望态度的家长在面临艺术等其它培训优秀“打挤”的情况还是会优先选择其它传统培优项目。

另一方面，教育行业是个讲究“春风化雨”的慢行业，没有人能够看到立竿见影的效果，除了少部分编程公司参考了计算机科学教师协会CSTA(Computer Science TeachersAssociation)评价体系还有一定科学性外，仍有一大部分教学缺乏权威评价体系的考量，家长看不到孩子的明显进步与收获自然会导致脱课率增加。

再一方面，由于相关技术中师资短缺是少儿编程市场发展的短板，教研方面更是有待进一步打磨。高校培养的编程高手不少，但是学这个学科的并不一定擅长教学，更何况对于这部分人来说，他们往往会有更高薪的选择。而传统教育行业的教师资源长期都是在比较成熟且固化的教育方法下培养起来的，这种编程类的新型学科本身就更新换代非常快，优秀且“与时俱进”的师资更是难以形成规模化的队伍。

另外，据了解，少儿编程课程设计多以游戏、机器人等为产品方向，而编程教育作为新秀，在课程研发方面，既不像传统课程有着清晰的教研逻辑，也缺乏可以借鉴的成熟经验，除了部分创办时间早的还有丰富的学员案例和数据来促进其更迭优化外，其他教育方法和体系是否完善还值得商榷。而且在资本红利的驱使下，也不排除有从业者素质不齐的现象存在，这既是家长的忧虑，也是整个行业需要共同努力完善的方向。

针对相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，目前还没有有效的解决方案。

发明内容

本申请实施例提供了一种网络直播方法及装置，以至少解决相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题。

根据本申请的一个实施例，提供了一种网络直播方法，包括：接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

根据本申请的另一个实施例，还提供了一种网络直播方法，包括：服务器接收终端发送的第一登陆请求，依据所述第一登陆请求允许所述终端访问所述服务器提供的少儿编程教学内容；接收所述终端发送的第二访问请求，将所述终端接入与所述第二访问请求对应的少儿编程教学的网络直播间；传输所述网络直播间的音视频数据至所述终端，存储所述音视频数据至网盘，并发送所述网盘的账户信息至所述终端。

根据本申请的另一个实施例，还提供了一种网络直播装置，包括：第一接收装置，用于接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；第二接收装置，用于接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；第三接收装置，用于接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；缓存装置，用于缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

根据本申请的另一个实施例，还提供了一种网络直播装置，包括：第四接收装置，用于接收终端发送的第一登陆请求，依据所述第一登陆请求允许所述终端访问所述服务器提供的少儿编程教学内容；第五接收装置，用于接收所述终端发送的第二访问请求，将所述终端接入与所述第二访问请求对应的少儿编程教学的网络直播间；传输装置，用于传输所述网络直播间的音视频数据至所述终端，存储所述音视频数据至网盘，并发送所述网盘的账户信息至所述终端。

根据本申请的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本申请的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本申请，接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。采用上述方案，通过网络直播的方式进行少儿编程教学，大幅降低学习少儿编程的成本与门槛，解决了相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，推动了全民提升编程水平。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请实施例的一种网络直播方法的移动终端的硬件结构框图；

图2是根据本申请实施例的网络直播方法的流程图；

图3是根据本申请另一个实施例的整体架构图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例一

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本申请实施例的一种网络直播方法的移动终端的硬件结构框图，如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述移动终端还可以包括用于通信功能的传输装置106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中的网络直播方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在本实施例中提供了一种运行于上述终端的网络直播方法，图2是根据本申请实施例的网络直播方法的流程图，如图2所示，该流程包括如下步骤：

步骤S202，接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；

步骤S204，接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；

步骤S206，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；

步骤S208，缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

将音视频数据缓存至缓存服务器，便于后续复习，同时节省本地数据存储空间。

上述方法可以运行于相关技术中的移动终端或者笔记本电脑等。

通过上述步骤，接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。采用上述方案，通过网络直播的方式进行少儿编程教学，大幅降低学习少儿编程的成本与门槛，解决了相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，推动了全民提升编程水平。

可选地，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据之后，在检测到当前为问答题部分时，在所述本地数据库中缓存当前的问答记录；在检测到所述服务器宕机并重启后，同步所述问答记录至所述服务器。采用上述方案后，在服务器宕机后，以终端存储的答题记录为准，避免由于服务器宕机造成的答题记录的不准确。

可选地，在检测到当前为问答题部分时，在第一通道接收所述网络直播间的音视频数据，在第二通道接收所述问答题部分的文字；将所述文字置于所述音视频数据上显示。采用上述方案，将音视频数据和答题文字进行分别传输，保证答题文字的传输准确率，避免由于音视频数据的慢加载导致答题流程慢。

可选地，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据之后，接收所述服务器分配的网盘账户信息，其中，所述网盘账户信息用于登陆至存储有所述网络直播间的录像。采用该方案，除了终端本地将音视频数据上传至缓存服务器时，服务器还可以为终端配置一个云网盘，终端可以登陆至云网盘观看教学视频，增大了学习的维度。

根据本申请的另一个实施例，还提供了一种网络直播方法，包括以下步骤：

步骤一，服务器接收终端发送的第一登陆请求，依据所述第一登陆请求允许所述终端访问所述服务器提供的少儿编程教学内容；

步骤二，接收所述终端发送的第二访问请求，将所述终端接入与所述第二访问请求对应的少儿编程教学的网络直播间；

步骤三，传输所述网络直播间的音视频数据至所述终端，存储所述音视频数据至网盘，并发送所述网盘的账户信息至所述终端。

采用上述方案，通过网络直播的方式进行少儿编程教学，大幅降低学习少儿编程的成本与门槛，解决了相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，推动了全民提升编程水平。

可选地，传输所述网络直播间的音视频数据至所述终端，包括：在传输问答题部分的音视频数据至所述终端的场景下，在所述服务器宕机并重启后，删除所述终端对应的答题记录，同步所述终端上存储的答题记录至所述服务器。采用上述方案，将音视频数据和答题文字进行分别传输，保证答题文字的传输准确率，避免由于音视频数据的慢加载导致答题流程慢。

下面结合本申请另一个实施例进行说明。

本申请另一个实施例以完整的体系对少儿进行编程基础教育，训练少儿的逻辑思维，针对性开发，寓教于乐，每日小礼物，让孩子们得到充分的肯定，拥有满满的成就感，享受编程乐趣。

一，本方案包括安卓Android手机端、iOS手机端、web端等三个端的软件实现。按照两个维度来选择课程，第一，按照少儿年龄段进行分组，第二，按照计算机语言划分教育课程。提供以下5个功能：

1.在线课程直播

在线实时直播讲解，可以更广泛的面对更多的少儿和家长。直播时，可随时插入即兴问答环节，抽取小礼物，鼓励少儿，证明孩子学的很好。

2.视频教程

录制一系列“专业且优质”的基础课程的视频，展现我们的教育实力和专业水平，达到硬实力的宣传目的。

3.算法练习游戏

课后练习环节，开发一系列易于少儿理解的算法小游戏，寓教于乐。比如：价格查询、计算天数、分配任务、猜数字等等。

4.家长手册

为家长提供指导性建议，配合孩子进行与老师的互动，从而调动少儿参与在线互动的积极性。

5.个人信息

采集数据，维护数据等。

二，场景分析

技术上面分为后台，客户端和互联网web。

android和ios的实现统一，android的特点就是比较随意，android基于了开发者无限的权利，但是ios往往受限于各种苹果的政策，所以两端在方案设计初期一定要确定好实现方式，如果不能统一用native那就统一用web。

web的优点就是通用，但是缺点也很明显，速度和安全。

有了web和客户端，那么对于后台来说我们就要实现两种协议支撑了，http和tcp。

图3是根据本申请另一个实施例的整体架构图，如图3所示，前端页面由安卓/IOS和H5组成，后台的整体架构分为三层，分别为接入层、逻辑层和存储层。

前端页面由源生安卓/iOS页面和H5混合构成，一些内容不会经常变动的页面用源生页面来实现，内容经常发生变动的页面由H5页面来实现。

接入层：在流量真正接入到我们业务后台之前，提供就近接入，安全策略、互联网协议地址ip收敛和负载均衡等功能，http协议解析之后统一负载均衡的打到后台的nginx(高性能的HTTP和反向代理web服务器)中，后续就是逻辑处理了。对于传输控制协议tcp请求，在移动端的复杂网络条件下很多问题都很难处理，业内已经有很多成熟的软件开发工具包SDK。我们借助这些SDK完成网络通信，这样做解放了客户端同学的人力，毕竟在复杂网络中做好连接的维护不是一件简单的事情。同时后台对于tcp请求统一接入到一个代理服务中，再有其进行转发，后台隐藏起来方便其内部进行流量控制调整，请求调用链分析，服务质量监控等。

接入层往往逻辑很简单，就是反向代理，再有一些登录态、安全和消息不全的基础功能，无论tcp还是http都要将请求打到逻辑层的业务中。如何标识一个请求对应的服务就需要命令字了，这也是很多java的远程过程调用rpc框架实现的基准。但是上述的实现是需要服务注册、消费等一整套基础框架支撑的，一个命令字往往是一个16进制的数字或者一个字符串，字符串要比数字更清晰明了。

协议的设计选择pb(Protocol buffer，协议缓存器)，因为更高效的编解码效率和简单易懂的pb文件，能够瞬间了解整个流程，但http层通常是json格式。json到pb可以无损失的转换，但pb到json则会丢失精度，原因是byte和long。

逻辑层部分的直播间：

基本上所有的直播场景都是围绕着直播间运转的。直播间有两块相互独立的系统，一个是音视频一个是直播间具体的业务，进入直播间是一个相对重的逻辑(白名单，黑名单，特效，排行榜等众多业务)，进入直播间业务失败也不应该让用户看不到音视频流，因此音视频流和直播间应该是解耦的，直播间的开播和音视频的推流相互不影响，这样方便音视频流的测试而不影响直播间的具体业务。

直播间是整个直播业务的核心链路，平时明星活动时一个直播间上10w真实用户都有可能，挑战点有两个：

直播房间是一个消息内容的承载，消息的获取无非就是推push或者拉pull，push的好处是实时性强，缺点就是需要维护成员列表，还有需要关注linux单进程的连接数限制。pull的好处是没有成员列表，缺点是实施性差，请求可能是锯齿状的，错峰能力需要提前考虑，否则有可能瞬间所有客户端一起请求，压垮后台。一个复杂的系统往往是推拉结合的，push可以消息合并，pull可以兜底。那么一个问题就是成员列表，如何把10w+的用户成员列表维护好，性能方面基本上已经到缓存的瓶颈了，况且有同时开播的直播间会有1k+，再者网络抖动带来的影响很大。那就只有内存了，内存的问题是怎么把同一个直播间的用户分配到一台机器上，一致性hash，使用内存的缺点就是数据易丢失，直播间的场景我们不需要考虑持久化，只需要在直播开始到直播结束保持稳定即可。但一台机器还是会有单点问题，那就多写，多机完全冗余，并且能够分担读请求压力。多机的问题就是一致性和扩容，客户端在进入直播间之后需要定时发送业务心跳来维护在线状态，同时可以返回一些业务信息，1/min的业务心跳能够保证多机中成员列表多数情况一致。如果多机仍然扛不住读请求，那么就需要水平扩容，使用内存的另一个弊端就出现了，如何数据搬迁，搬迁时的变化又怎么处理？还是依赖于心跳，水平扩容先写，过2分钟后基本上就可以提供读了。在日常的直播场景中，小直播间(1w以下)占绝大多数，基本的业务都或多或少依赖成员列表。但是去年百万英雄之类的火爆答题(100w同时在线)条件下，成员列表就没必要存在了，另外那个场景另外再分析。

进/退直播间、直播间内的心跳、送礼、发言等等都是直播间内的消息，这多多消息怎么处理。肯定要合并写、合并读，合并是根据直播间id进行合并的，合并的载体依旧是内存，那就又需要一致性hash了。另外一个问题就是成员列表怎么传输，分页拉取，增量调整。

在处于答题场景时，本申请另一个实施例只做一件事就是答题，但还是有以下问题：

1.人数众多。人数多需要采用一致性hash的方案，但是每台机器是单点，没有备机，因为业务心跳也没了。如果答题时宕机就会影响一部分用户漂移到其他机器上，这个用户的资料就丢失了，通过把用户资料传给客户端，客户端请求时主动带上来，这样保证有一份兜底数据。只有漂移时才使用兜底数据，并且对数据加密(非对称)。基本上不可能用户一直在多台机器漂移。那么用户会不会有ABA问题，即宕机的服务恢复了，然后又飘回来了，因为原有机器上数据存在，但是之前的老数据，会不会有影响。解决方案：时间戳。

2.峰值。准点开始的答题，不可能在一瞬间完成，业务需要主动的通过提前通知用户，引导错峰进入直播间，给业务多点时间。

3.pull，没有了成员列表，push变得不可能，拉的问题就凸显了，pull不能集中(后台可以控制请求频率，将请求打散)，2000-3000ms。

4.时间。答题一般10s，音视频延时时间+网络延时时间，计算一个最大的答题时间。

5.题目。题目混在音视频流中容易跟着一起卡，因此需要题目单独拿出来。

6.异地部署，在不同城市可以就近接入当地的服务器，以减轻总部服务器的压力。

7.结算，在结束后需要将得奖用户写入redis，最终在将各地的redis中用户汇总(mb级别)，再通过mq异步发奖，异步消息使用kafka，分布式实现，提高数据吞吐量。

存储层：存储层在2c业务方面起到一个很重要的角色，mysql这种传统的关系型数据库有可能在性能方面扛不住，redis在性能方面没有什么问题，但是需要考虑缓存击穿问题，而且这个问题还不太好处理，需要考虑的问题还很多。redis会受到单机容量限制，同时redis在容量满时会有丢弃策略。CKV分布式存储系统在这方面做得很好，一主一备，自动扩容，lru冷备，完全就当做能落地的持久层用。故推荐使用ckv，Redis主从版(CKV)采用主从节点部署架构，提供数据持久化和备份，适用于对数据可靠性、可用性均有要求的场景。

主节点提供日常服务访问，从节点提供双机集群系统HA，当主节点发生故障，系统会自动切换至从节点，保证业务平稳运行。CKV主从版兼容Redis 3.2版本的命令和协议，支持4GB-384GB的规格，满足大容量存储的需求。

三，本申请另一个实施例的网络直播系统的详细架构设计可以如下：

1.SpringCloud整体微服务框架。

2.Nginx做负载均衡，反向代理，承受高并发访问。

3.Zuul动态路由，url鉴权，参数验证，提供系统安全性。

4.Eureka Server+Eureka Client服务注册，提供微服务。

5.Config提取公共配置，使用git远程管理配置文件，便于集中管理。

6.Redis缓存，分布式锁，RDB或AOF持久化存储数据，提供高性能存储。

7.Zookeeper+Kafka，分布式高吞吐异步消息。

采用本申请另一个实施例的方案，带来以下两点有益效果：

1、更好的调动少儿学习编程的积极性。

2、比线下教学更加节省成本，不再受到空间限制，一位老师可以面对更多的学生与家长。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

实施例二

在本实施例中还提供了一种网络直播装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

根据本申请的另一个实施例，还提供了一种网络直播装置，包括：

第一接收装置，用于接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；

第二接收装置，用于接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；

第三接收装置，用于接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；

缓存装置，用于缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。采用上述方案，通过网络直播的方式进行少儿编程教学，大幅降低学习少儿编程的成本与门槛，解决了相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，推动了全民提升编程水平。

根据本申请的另一个实施例，还提供了一种网络直播装置，包括：

第四接收装置，用于接收终端发送的第一登陆请求，依据所述第一登陆请求允许所述终端访问所述服务器提供的少儿编程教学内容；

第五接收装置，用于接收所述终端发送的第二访问请求，将所述终端接入与所述第二访问请求对应的少儿编程教学的网络直播间；

传输装置，用于传输所述网络直播间的音视频数据至所述终端，存储所述音视频数据至网盘，并发送所述网盘的账户信息至所述终端。

采用上述方案，通过网络直播的方式进行少儿编程教学，大幅降低学习少儿编程的成本与门槛，解决了相关技术中由于少儿编程教学资源缺乏导致的教学效率低的问题，推动了全民提升编程水平。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例三

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

S1，接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；

S2，接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；

S3，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；

S4，缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本申请的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输装置以及输入输出设备，其中，该传输装置和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；

S2，接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；

S3，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；

S4，缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种网络直播方法，其特征在于，包括：

接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；

接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；

接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；

缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

2.根据权利要求1所述的方法，其特征在于，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据之后，所述方法还包括：

在检测到当前为问答题部分时，在所述本地数据库中缓存当前的问答记录；

在检测到所述服务器宕机并重启后，同步所述问答记录至所述服务器。

3.根据权利要求2所述的方法，其特征在于，在检测到当前为问答题部分时，所述方法还包括：

在第一通道接收所述网络直播间的音视频数据，在第二通道接收所述问答题部分的文字；

将所述文字置于所述音视频数据上显示。

4.根据权利要求1所述的方法，其特征在于，接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据之后，所述方法还包括：

接收所述服务器分配的网盘账户信息，其中，所述网盘账户信息用于登陆至存储有所述网络直播间的录像。

5.一种网络直播方法，其特征在于，包括：

服务器接收终端发送的第一登陆请求，依据所述第一登陆请求允许所述终端访问所述服务器提供的少儿编程教学内容；

接收所述终端发送的第二访问请求，将所述终端接入与所述第二访问请求对应的少儿编程教学的网络直播间；

传输所述网络直播间的音视频数据至所述终端，存储所述音视频数据至网盘，并发送所述网盘的账户信息至所述终端。

6.根据权利要求5所述的方法，其特征在于，传输所述网络直播间的音视频数据至所述终端，包括：

在传输问答题部分的音视频数据至所述终端的场景下，在所述服务器宕机并重启后，删除所述终端对应的答题记录，同步所述终端上存储的答题记录至所述服务器。

7.一种网络直播装置，其特征在于，包括：

第一接收装置，用于接收第一输入信号，依据所述第一输入信号运行少儿编程教学的应用程序；

第二接收装置，用于接收第二输入信号，其中，所述第二输入信号用于选择待进入的少儿编程教学的网络直播间；

第三接收装置，用于接收服务器传输的所述网络直播间的音视频数据，显示所述音视频数据；

缓存装置，用于缓存所述音视频数据至本地数据库，并同步所述音视频数据至Redis缓存服务器。

8.一种网络直播装置，其特征在于，包括：

第四接收装置，用于接收终端发送的第一登陆请求，依据所述第一登陆请求允许所述终端访问服务器提供的少儿编程教学内容；

第五接收装置，用于接收所述终端发送的第二访问请求，将所述终端接入与所述第二访问请求对应的少儿编程教学的网络直播间；

传输装置，用于传输所述网络直播间的音视频数据至所述终端，存储所述音视频数据至网盘，并发送所述网盘的账户信息至所述终端。

9.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至6任一项中所述的方法。

10.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至6任一项中所述的方法。