实现的一个mini版抖音服务端

注意：新一期的青训营项目需要实现新的功能，实现好友聊天功能

• 方案1：完成socket消息服务中心，服务开发者自主指定服务端口号
• 方案2：客户端通过定时轮询服务端接口查询消息记录，当前登录用户和其他指定用户的聊天消息记录

1. • 视频Feeds流接口
2. • 用户注册
3. • 用户登录
4. • 用户信息
5. • 投稿接口
6. • 发布接口

1. • 赞操作
2. • 点赞列表
3. • 评论操作
4. • 评论列表

1. • 关注操作
2. • 关注列表
3. • 粉丝列表

douyin/
├── conf
├── controller
├── log
├── middleware
├── model
├── routes
├── serializer
├── log
├── service
├── docs
└── util

gin-swagger

• conf : 用于存储配置文件
• controller : 用于处理请求JSON格式返回
• log : 用于存储日志文件
• middleware : 自定义的中间件,支持跨域和限流
• model : gorm使用的数据库模型
• routes : 路由转发
• serializer : 定义序列化json的结构体
• log : 存放日志文件
• service : 具体的功能处理逻辑
• docs : swagger文档
• util : 工具类

1.下载第三方库

go mod tidy

2.配置数据库

1. 使用COS进行短视频存储，申请COS资源，在配置中填写对应bucket,id,key
2. 项目已经使用gorm2且开启了数据库自动迁移模式，仅需在conf/config.ini文件中配置相关参数，建立douyin数据库，启动服务器即可

3.运行

go run main.go

运行项目生成数据表后，请运行以下SQL语句使得Gorm大小写敏感

ALTER TABLE user MODIFY COLUMN name VARCHAR(50) BINARY CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL;

4.测试

1. 可以使用postman对接口进行测试
2. 也可使用客户端测试
3. Swagger为1.4.3版本，最新版1.5.3不兼容

额外的高级功能

1. • 使用bloomfilter判断重复用户名，减少数据库查询次数(服务器重启后原本维护在内存中的用户名会丢失，可以加一层redis中，然后重启服务器时，判断filter是否为空，然后利用自动化任务写入服务器内存)

1. • 使用ratelimit令牌桶算法开源实现进行限流 令牌桶初始化后里面就有 100 个令牌，每秒钟会产生 100 个令牌, 保证每秒最多有 100 个请求通过限流器, 也就是说 QPS 的上限是 100，流量过大时能够启动限流, 在限流过程中, 仍然能让部分流量通过

1. • 针对游客与登录用户Feeds流的推送。对于游客，我们可以推送给他们点赞多或者排行榜靠前的视频，一次构造出30条，呈给用户。对于已经登录的用户，又细分为下面第8的情况👇
2. • 登录用户关注不同粉丝量的用户时Feeds流方式。假设在我们的实践中存在一个值为FansCount，当用户粉丝数大于等于FansCount时，我们定义该用户为明星用户，小于FansCount时该用户为普通用户。因此有了如下推送规则：当该用户关注的普通用户发抖音时，系统从数据库中拉取普通用户对应的抖音视频即可(拉模式)。当该用户关注的明星用户发抖音时（明星用户可能有几百万，几千万，甚至上亿的粉丝量），为了防止在瞬间给明星用户的粉丝推送视频产生的大量查询拖垮数据库。因此有了针对明星用户的规则：当明星用户发抖音时，我们把明星用户的视频写入到他/她的粉丝Feeds流中，而不是让他/她的粉丝来请求他/她发的抖音(推模式)。
3. • 迁移jwt -> https://github.com/golang-jwt/jwt
4. • 引入pprof/直接看到当前web服务的状态，包括CPU占用情况和内存使用情况访问http:https://localhost:8080/debug/pprof/
5. • 引入Prometheus监控