课程发布模块

课程发布之前运营方会进行课程审核，审核通过后课程方可发布。

作为课程制作方即教学机构，在课程发布前通过课程预览功能可以看到课程发布后的效果，哪里的课程信息存在问题方便查看，及时修改。

1.课程预览接口开发：

课程预览的流程

点击预览

 

课程预览需求开发：机构人员可以点击课程预览来查看课程的信息（这些信息来自于四个表 基本信息 营销信息 课程计划 师资管理） 这个预览页面是机构人员来看，我使用了freemarker技术，进行服务端的渲染，因为这个访问量不是那么大，freemarker是一个模板引擎技术，渲染的过程就是向j页面(模板)内填充数据(模型)。编写一个业务接口，查询这四张表的数据，通过freemark的官方文档指定api进行开发：

指定视图（页面）和模型(数据)

2.课程审核接口开发

如何控制课程审核通过才可以发布课程呢？

在课程基本表course_base表设置课程审核状态字段，包括：未提交、已提交(未审核)、审核通过、审核不通过。

整体流程：

1、一门课程新增后它的审核状为”未提交“，发布状态为”未发布“。

2、课程信息编辑完成，教学机构人员执行”提交审核“操作。此时课程的审核状态为”已提交“。

3、当课程状态为已提交时运营平台人员对课程进行审核。

4、运营平台人员审核课程，结果有两个：审核通过、审核不通过。

5、课程审核过后不管状态是通过还是不通过，教学机构可以再次修改课程并提交审核，此时课程状态为”已提交“。此时运营平台人员再次审核课程。

6、课程审核通过，教学机构人员可以发布课程，发布成功后课程的发布状态为”已发布“。

7、课程发布后通过”下架“操作可以更改课程发布状态为”下架“

8、课程下架后通过”上架“操作可以再次发布课程，上架后课程发布状态为“发布”。

1、课程提交审核后还允许修改课程吗？

如果不允许修改是不合理的，因为提交审核后可以继续做下一个阶段的课程内容，比如添加课程计划，上传课程视频等。所以允许机构人员再提交审核之后继续修改课程信息。

但是如果机构人员提交审核后，继续修改课程信息，如果运营人员去从基本信息表去读数据，就会发生冲突

 为了解决这个问题，引入了预发布表

提交审核之后 把四张表的信息汇总到预发布表中，运营人员审核的是预发布表，在机构人员提交审核之后，还可以操作四张关于课程信息的表，关键在于两批人操作的是不是同一张表

 2、提交审核课程后，也修改了课程信息，可以再次提交审核吗？

提交审核课程后，必须等到课程审核完成才可以再次提交课程

涉及的数据模型：1.课程预发布表

注意这个主键id就是courseId

 提交审核：

1.向预发布表插入信息 注意状态为已提交

2.更新课程基本信息表的课程审核状态为：已提交

以下的3,4在项目中未实现

3.课程审核后，更新预发布表的审核状态，更新课程基本信息表的审核状态，

4.审核结果写入课程审核记录表。

2.课程审核记录表如下：

 3.课程发布开发前传

需求分析流程：

1、向内容管理数据库的课程发布表存储课程发布信息，更新课程基本信息表中发布状态为已发布。

2、向Redis存储课程缓存信息。

3、向Elasticsearch存储课程索引信息。

4、请求分布文件系统存储课程静态化页面(即html页面)，实现快速浏览课程详情页面。

涉及的数据模型：

课程发布表的数据来源于课程预发布表，它们的结构基本一样，只是课程发布表中的状态是课程发布状态，而课程预发布表的状态是审核状态：已提交 审核通过 审核不通过

 为了完成这个接口的开发，我们引入了分布式事务控制：

一次课程发布操作需要向数据库、redis、elasticsearch、MinIO写四份数据，这里存在分布式事务问题

本地事务和分布式的事务：

本地事务：spring去控制事务是利用数据库本身的事务特性来实现的，因此叫数据库事务，本地事务具有ACID四大特性，数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作 要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚。

分布式事务:

课程发布操作后将数据写入数据库、redis、elasticsearch、MinIO四个地方，这四个地方已经不限制在一个数据库内，是由四个分散的服务去提供，与这四个服务去通信需要网络通信，而网络存在不可到达性，这种分布式系统环境下，通过与不同的服务进行网络通信去完成事务称之为分布式事务

举个例子:

本地事务：

begin transaction；
//1.本地数据库操作：张三减少金额
//2.本地数据库操作：李四增加金额
commit transation;

分布式事务：

begin transaction；
//1.本地数据库操作：张三减少金额
//2.远程调用：让李四增加金额
commit transation;
假设远程调用李四增加金额了，但结果由于网络问题迟迟没有返回，这时候此时本地事务提交失败就回滚了张三减少金额的操作，莫名奇妙的李四多了100元?有这好事？

因此在分布式架构的基础上，传统数据库事务就无法使用了，张三和李四的账户不在一个数据库中甚至不在一个应 用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。

产生分布式事务的场景：

个人总结：服务连接数据库是需要网络连接的，服务之间的调用也是需要