本次抖声项目数据库采用MySQL数据库，一共5张表，分别是用户表:t_users、用户关注表:t_relation、视频表:t_video、视频点赞表:t_favorite和评论表:t_comment，如下图所示五个数据表
| 名称 | 意义 | 类型 |
|---|---|---|
| user_id | 用户id，主键 | bigint |
| username | 用户名 | varchar |
| password | 密码,md5加密 | varchar |
| 名称 | 意义 | 类型 |
|---|---|---|
| user_id | 用户id，外键：参照用户表id | bigint |
| to_user_id | 关注用户id（与用户id一起为复合主键） | bigint |
| 名称 | 意义 | 类型 |
|---|---|---|
| id | 视频id，主键 | bigint |
| user_id | 用户id,外键：参照用户表id | bigint |
| video_url | 视频地址 | varchar |
| video_cover | 视频封面地址 | varchar |
| title | 视频标题 | varchar |
| created_at | 创建时间 | datetime |
| 名称 | 意义 | 类型 |
|---|---|---|
| user_id | 用户id，外键：参照用户表id | bigint |
| video_id | 视频id，外键：参照视频表id，和用户id为复合主键 | bigint |
| 名称 | 意义 | 类型 |
|---|---|---|
| id | 评论id,主键 | bigint |
| user_id | 用户id，外键参照用户表id | bigint |
| video_id | 视频id，外键参照视频表id | bigint |
| content | 评论内容 | varchar |
| created_at | 评论时间 | datetime |
首先是项目结构，因为项目比较简单，并没有细分的很好，只分了逻辑业务层，数据层，没有特意去设置中间件层，比如鉴权，参数检验等都在逻辑业务层处理，config文件夹是一些数据结构的定义，pkg是一些工具包的定义，mysql是数据层操作，controller层是重要的业务处理，资源文件均存放在public目录中。
本次项目一共有如下几个功能：
| 功能项 | 说明 |
|---|---|
| 视频Feed流、视频投稿、个人信息 | 支持所有用户刷抖音，按投稿时间倒序推出，登录用户可以自己拍视频投稿，查看自己的基本信息和投稿列表，注册用户流程简化。 |
| 点赞列表、用户评论 | 登录用户可以对视频点赞，并在视频下进行评论，在个人主页能够查看点赞视频列表。 |
| 关注列表、粉丝列表 | 登录用户可以关注其他用户，能够在个人信息页查看本人的关注数和粉丝数，点击打开关注列表和粉丝列表。 |
用户注册这个功能主要的实现在token的生成，客户端post请求到服务端，服务端获取相应的用户名和密码后，首先需检查用户是否已在数据库中存在，不存在才进行注册操作。在插入数据库前，需要首先生成用户id作为唯一标识，这里我采用了雪花算法生成uuid来作为用户id。插入数据库成功后，通过jwt包来生成token，自定义字段加入了用户id和用户名，因此其它接口获取此token是可以直接解析出用户id和用户名来使用，而不需要从客户端额外获取用户id。
用户登录只需要校验一下数据库即可生成token返回给客户端，并不复杂。
用户id需要查询的内容较多，比如关注数和粉丝数等。这些都需要进行联表查询，稍微复杂一点。但是缺点就是并没有考虑到性能的问题，需要查询多次的数据库。优化可以使用redis做缓存来记录关注数和粉丝数这些记录，等一定时间后再存入mysql中。但项目中并没有使用redis。整个项目都仅仅采用了mysql。
首先还是参数校验，然后再token鉴权，其实这里可以使用中间件处理这些操作，但因为时间原因，并没有这样去实现，将记录写入点赞表即可。
首先这个功能是支持所有用户的，但是登录用户可以看到是否某个视频自己已经点赞了，因此是需要区分的。当用户未登录时，视频是否点赞和用户是否关注都默认为false，登录用户才会进行额外的数据库查询，因此算是一种逻辑优化。从数据库中输出最新的30条视频信息，优化的点就是可以在created_at上建立索引。这个接口也会进行大量的数据库查询。
这个功能应该是整个项目中比较复杂的，首先从客户端获取数据流，文件名使用的是用户id拼接文件名，这样可以最大程度保证文件名不重复。如果文件重复，也会覆盖这个文件，而不必再浪费额外的内存去存放视频。数据库存放的视频地址，可以根据视频地址直接访问服务器的静态资源，因此会有安全问题，静态资源可以被随意获取。比较难思考的是视频封面如何获取，这里使用了ffmpeg工具来获取视频的第一帧来作为视频封面，同样视频封面文件存放在public文件夹中，数据库中存放的依然是URL。但如果海量存储的情况下，得使用课上讲的对象存储，但我并没有使用。
剩下的功能逻辑都大同小异，因为整个项目并没有太考虑性能的问题，因此在高并发的情况下肯定是行不通的。但是因为对于golang的运用目前只能做到这种地步了，所以只能算是勉强完成所有功能。
视频流播放完全没有问题，同时可以点赞和取消点赞，点赞了会显示红色爱心
评论也可以删除
喜欢列表和发布列表：
视频发布成功！
首页刷新一下即可看到刚发布的视频，切换用户，其他用户也可以刷到。
但是由于客户端存在一些bug，所以体验并不会特别好，比如关注数和发布数不会实时同步。
