项目结构
- 安卓客户端-API端(http协议)-service端(RPC协议)-缓存-数据库
douyin
|-- apps
|-- api
|-- user 调用rpc服务
|-- rpc
|-- user 用户登录注册和信息获取（已完成）
|-- video 视频部分
|-- readme.md
|-- go.mod
|-- pkg 公共部分
|-- authcrypto.go auth获取token和鉴权
|-- userdb.go user结构体和数据库缓存的连接函数
数据库设计
type User struct {
ID int64 // 主键（用户id）
Username string // 用户名
Password string // 密码
FansCount int64 // 粉丝数
FollowerCount int64 // 关注数
Avatar string // 用户头像
Name string // 用户昵称
BackgroundImage string // 顶部头图
Signature string // 个人简介
TotalFavorited string // 获赞数量
WorkCount int64 // 作品数
FavoriteCount int64 // 喜欢数量
}
// 是否关注这个人 一对多 一个用户关注多个人
type fans_followers {
ID int64 // 主键
FansId int64 // 粉丝id
FollowerId int64 // 关注者id
}
// 是否喜欢这个视频 一对多 一个用户对应多个视频
type users_favor_videos {
ID int64 // 主键
UserId int64 // 用户id
VideoId int64 // 喜欢的视频id
}
type Video struct {
ID int64 // 主键（视频id）
UserId int64 // 用户id
PlayUrl string // 视频播放地址
CoverUrl string // 视频封面地址
FavoriteCount int64 // 视频点赞总数
CommentCount int64 // 评论总数
Title string // 视频标题
CreatedAt int // 创建时间
}
// 视频的评论 一对多 一个视频对应多个评论
type Comment struct {
ID int64 // 主键
VideoId int64 // 视频id
UserId int64 // 用户id
Content string // 发布内容
CreatedAt int // 发布时间
}
// 是否进行聊天 多对多 发布者和接收者的id都需要操作
type Chat struct {
ID int64 // 主键
Content string // 消息内容
CreatedAt int // 发送时间
ToUserId int64 // 发布者id
FromUserId int64 // 接收者id
}
设计思路，将视频信息，用户信息分表，然后让再创建进行关联的表 最大程度保证微服务的解耦 而且以后有新的扩展可以直接增加关联的表或者修改原有的关联表，确保了较好的可扩展性 简单来说就是首先创建相应的视频 用户资源 他们之间的交互通过关联表实现
设置Redis-MQ-MySQL 查询：首先redis查询队列，然后mysql查询 写入：先积压在redis中，然后再进行写入
聊天（一般都是短时间内聊天，会频繁的查看聊天记录和增加聊天记录） 使用redis缓存 添加几天的过期时间，先写入缓存，再写入数据库，查询先查询缓存，再查询数据库
评论和点赞（流量大的博主可能会出现短时间内大量的点赞和评论） 使用redis的缓存的消息队列的积压去完成吞吐
用户信息和视频信息（不断刷视频会读取大量的用户信息和视频信息） 按照时间排序，将设置过期时间，先写入缓存，再返回给用户，在一定时间内用户访问的都是缓存的视频以此解决高并发的访问
这么设计其实只是根据自己的经验一个模拟的预期结果，真实可能需要统计数据去优化（比如过期时间的设计，还有就是保证数据库和缓存的一致性）
用户注册
需求
- 用户名不能重复
- 用户名和密码小于32位
- 注册完设置默认的值（头图，头像，昵称，粉丝数等）
RPC服务
请求
username
password
返回
用户id
{
"status_code": 0,
"status_msg": "登录成功",
"user_id": 1,
"token": "eyJhbGciOiAiSFMyNTYiLCJ0eXAiOiAiSldUIn0=.eyJFeHAiOjE2OTIzMjY0OTMsIklhdCI6MTY5MjI0MDA5MywiSWQiOjF9.39bECbrjIlgAwqV-qzmTsmsDZAWYXbzCj3NH0eLRkhE="
}
用户登录
需求
- 验证用户名和密码是否正确
- 密码在数据库中存储也是加密的状态（通过用户名＋密码md5加密），保证数据库泄露仍然安全
用户信息
需求
- 通过user_id在user表查询相应的用户信息
投稿接口
- 将取得的视频进行压缩 可能需要相应的编码和解码格式
- 储存在静态资源服务器上，返回数据的时候将域名和路径进行拼接
- 使用nginx 配置静态资源
