抖音青训营后端项目——简易抖音

项目名称

基于 GORM 和 Gin 框架构建的简易版抖音——抖声

项目亮点

• 使用Redis进行缓存 ，使用布隆过滤器解决缓存雪崩的问题，并对缓存穿透以及缓存击穿进行了处理；
• 使用Redis的事务机制来保证数据的一致性，确保多个用户同时点赞时不会造成数据错误；并且将点赞数据定时写入数据库持久化存储；
• 使用七牛云OSS对象存储对短视频进行存储和管理，提升视频访问速度和用户体验；
• 使用Kafka对评论功能以及私信功能进行异步削峰，减轻系统的负载压力，同时也对评论进行了预加载，提高响应速度；
• 使用Redis集群，来保证数据的高可用性和可靠性，并且使用Redis主从复制，来提高数据的可用性；
• 数据库使用Mycat实现分库分表，以及两主两从读写分离；
• 使用预先设定好的敏感词初始化前缀树，实现对用户发布的敏感词进行过滤，以避免用户发布可能的敏感词；
• 使用Redis的Set集合存储点赞，实现点赞功能，减轻服务器压力；
• 密码进行MD5加密，并且预防XSS攻击；
• 使用令牌桶算法进行接口限流，保证接口的稳定性和安全性。

功能列表

• 注册模块：用户可以通过注册页面进行注册，注册时需要提供用户名、邮箱、密码等信息。
• 登录模块：用户可以通过登录页面进行登录，登录时需要提供邮箱和密码进行身份验证。
• 视频接口流：用户可以通过视频接口流查看抖音青训营中的视频资源。
• 用户信息：用户可以通过个人中心页面查看自己的个人信息，包括用户名、邮箱、头像等。
• 投稿视频：用户可以通过视频上传页面上传自己的视频资源。
• 关注操作：用户可以通过个人中心页面或其他用户的个人主页进行关注操作，关注后可以收到被关注用户的动态。
• 点赞操作：用户可以通过视频播放页面进行点赞操作。
• 评论操作：用户可以通过视频播放页面进行评论操作，发表对视频的评论。
• 评论模块：用户可以通过个人中心页面查看自己发表的评论，或者在视频播放页面查看其他用户对视频的评论。

开发环境

• 语言：Go
• 数据库：MySQL
• 数据库中间件：Mycat
• 缓存：Redis
• 消息队列：Kafka
• 框架：Gin，Gorm
• 云存储：七牛云OSS对象

部署方法

（1）导入项目到goland中，等待一会等右下角的加载完成 （2）执行命令

go build main.go

（3）将项目生成的main二进制文件移到服务器中， 直接用XFTP将生成的文件移到服务器

chmod +x main     # 赋权

./main    # 前台运行
# 或者
nohup ./main &    # 后台运行

API文档

https://www.apifox.cn/apidoc/shared-09d88f32-0b6c-4157-9d07-a36d32d7a75c/api-50707523

数据库ER图

场景分析

• 场景1：

现象：预计0.5%的用户属于大V，粉丝很多，也会经常上传视频，而其他人可能上传较少；

解决方法：利用Mycat进行读写分离，来减轻数据库的压力，同时利用分库分表和雪花算法，来减轻单一数据库压力提高性能。

• 场景2：

现象：用户评论消息（发送聊天）后等待时间过长。

解决方案是：利用RabbitMQ消息队列来实现异步削峰，提高评论响应速度；用户评论（或者聊天）将被放入消息队列中，异步存储进数据库中。

• 场景3：

现象：用户点赞会非常频繁，可能会出现卡慢的现象。

解决方案：将点赞消息存储在Redis中，以便于快速查询和更新；同时，使用Redis 提供的事务机制和乐观锁来保证数据的一致性；并且，定时将Redis数据存储到数据库中；

• 场景4：

现象：刷视频时视频或者图片加载时间过长，用户体验不佳；

解决方案：视频流使用消息队列进行预加载，每次提前加载下一部分的数据，减少等待时间；同时，使用七牛云OSS对象存储，也可以提高加载的速度；

• 场景5：

现象：在加载关注列表或者喜欢列表时，获取不到数据（可能一次性加载量过大，导致缓存穿透或者缓存雪崩）；

解决方案：

使用布隆过滤器以及缓存空对象来避免缓存穿透和缓存击穿；并且使用分布式锁来避免缓存雪崩，保证在高并发情况下只有一个请求能够访问数据库并将数据更新到缓存中；

• 场景6：

现象：出现密码泄露或者token泄露被修改的情况，

解决方案：在输入密码时，通过MD5加密方法把密码加密后在插入到数据库当中，token也应用对应的加密方法对token进行加密;

• 场景7：

现象：用户发表的标题或者评论里面含有敏感词；

解决方案：通过使用敏感词过滤，将敏感词过滤掉。敏感词通过前缀树的方法，将敏感词构造成前缀树，然后再判断发表的文本有没有存在敏感词。

• 场景8：

现象：用户获取到的数据和实际的不一致（数据库和缓存不一致）；

解决方案：在有数据变更的地方，同时更新缓存和数据库；对于读多写少的情况，比如个人信息的功能，采用事务以及先更新数据库再更新缓存；对于并发要求高的且一致性要求高，比如点赞的功能，选择“先更新数据库再删除缓存，并结合删除重试、补偿逻辑和缓存过期TTL的手段。

• 场景9：

现象：用户点赞出现失败的现象（点赞频繁导致数据库压力过大）；

解决方案：使用Redis作为数据库对点赞信息进行存储，并定时将数据持久化到Mysql数据库中；

• 场景10：

现象：用户刷到重复的视频；

解决方案：使用Redis对用户看过的视频进行记录，每次预加载前进行判断是否已经刷过，刷过则跳过。

• 场景11：

现象：用户通过上传恶意文件来绕过应用程序的安全措施，导致应用程序遭受攻击；

解决方案：进行文件类型检查：在上传文件之前，检查文件类型是否为允许的类型。

• 场景12：

现象：用户通过输入恶意字符进行XSS或者SQL攻击；

解决方案：对用户输入的数据进行非法字符的过滤；