1、场景描述
比如说我们要做一款APP,需要通过api接口给app提供数据。假设我们是做商城,比如我们卖书的。我们可以想象下这个APP大概有哪些内容:
1)首页:banner区域(可以是一些热门书籍的图片做推广)、本周热卖书籍区域、本月好评书籍区域、活动打折的书籍区域。。。
2)排行榜:比如第一季度热销榜、新书版。。。
3)书单:管理后台运营添加的书单,比如《程序员从入门到放弃》系列书单。。。
4)用户相关的:比如用户个人信息设置、订单管理、消息管理、收藏的书籍。。。
数据是保存在数据库中,考虑到高并发数据库的瓶颈,采用DB+缓存的服务器架构。
2、重要接口汇总
看似简单的一个app,需要调用的api接口是非常多的,总结下大概有这几类接口:
1)列表接口:比如书单里面的书籍列表、排行榜的书籍列表;
2)详情接口:书籍的详细信息;
3)评论接口:书籍评论(这里可能要求购买了的才能评论)、星标;
4)点赞接口:给书籍点赞、给书单点赞;
5)收藏接口:收藏书籍、收藏书单;
6)“相关”接口:比如书籍《php从入门到放弃》相关的有哪些书籍;
7)关注接口:关注某本书或者书籍作者,一旦某本书有打折或者作者有新书,会推消息等等。或者是用户间互相关注;
8)发布接口:比如用户可以发布书单。A用户发布了书单,B用户可以关注A用户,A用户再发布新书单,会给B用户推消息等等;
9)搜索接口:查询书籍、查询书单、查询用户等等
3、后台管理系统
1)书籍信息的来源:爬虫抓取的数据、运营人员在管理后台添加;
2)书籍的价格、库存等信息,是可以在后台设置;
3)书籍的分类、书籍的标签,像爬虫如果抓取不到的,运营可以手动设置;
4)书籍的排序:在管理后台设置,用于在app上展示的先后顺序;
5)书单管理:运营可以添加、可以设置展示/隐藏;用户提交的书单,在后台进行审核;
6)用户的评论:在后台审核;
备注:管理系统还有很多功能,简单先写这几个。
4、数据库设计
1)书籍表 book
- id 自增id,主键,书籍id
- title 标题
- description 描述
- author_id 作者id
- source 爬虫来源
- stock 库存
- price 价格
- status 状态:上架/下架
- sort 排序顺序
- create_time 添加时间
- create_user 添加者(运营账号id、爬虫来的话是指定一个运营id)
- update_time 修改时间
- update_user 修改者
2)作者表 book_author
- id 自增id,主键,作者id
- name 作者笔名
- birthday 出生年月
- sex 性别
- description 描述
3)分类表 book_category
- id 自增id,主键,分类id
- parent_id 父类id,顶级分类的父类id为0
- title 分类名称
- status 状态 是否可用
- create_time 添加时间
- create_user 添加者(运营账号id)
- update_time 修改时间
- update_user 修改者(运营账号id)
4)书籍和分类关系表 book_category_relation
(书籍绑定到最细的分类,为简单起见,假设一本书只绑定一个分类,假设书籍和分类是多对一关系)
- book_id 主键
- cate_id
- create_time 添加时间
- create_user 添加者(运营账号id)
- update_time 修改时间
- update_user 修改者(运营账号id)
5)标签表 book_tags
参考分类表
6)书籍和标签关系表 book_tags_relation
参考书籍和分类关系表,为简单起见,假设书籍和分类多对一关系,一个标签有多个书籍,一个书籍只有一个标签。
7)书单表 book_list
- id 自增id,主键,书单id
- title 书单名称
- description 描述
- status 状态: 发布/隐藏
- audit_status 审核状态
- audit_reason 审核理由(审核失败时需要填写)
- audit_time 审核时间
- audit_user 审核者(运营id)
- create_time 创建时间
- create_user 创建者(运营或者用户id)
- update_time 修改时间
- update_user 修改者(运营或用户id)
8)书单内容表(书单包含的书籍) book_list_content
- id 自增id
- list_id 书单id
- book_id 书籍id
- reason 推荐理由
- star 推荐星级
- status 状态: 展示/隐藏
- sort 排序顺序
- create_time 添加时间
- create_user 添加者
- update_time 修改时间
- update_user 修改者
9)用户表 user
- id 自增id,主键,用户id
- user_name 用户名(登录用)
- nickname 用户昵称
- email 邮箱
- password 登录密码
- phone 电话
- sex 性别
- avatar 头像
- description 个性描述
- status 状态:待激活/已启用/黑名单
- create_time 账号创建时间
10)书籍点赞表 book_like
- id 自增id 主键
- book_id 书籍id
- user_id 用户id
- status 是否有效(因为不删除数据,所以增加这个状态字段)
- create_time 点赞时间
- update_time 更新时间
11)书籍收藏表 book_collect
参考 书籍点赞表
12)用户关注表(用户A关注用户B) user_focus
- id 自增id 主键
- user_id 用户id(用户A)
- target_user_id 被关注的用户id(用户B)
- status 是否有效
- create_time 关注时间
- update_time 更新时间
备注:用户A和用户B互相关注,则表中有2条数据
13)订单表 order
- id 自增id 订单id
- order_sn 订单号
- user_id 用户id
- coupon_id 优惠券id
- discut_money 打折减免的价格
- origin_money 原价
- money 订单总价格
- status 订单状态: 待支付/已支付/拣货完毕/已发货/退货/已收货...
- comment 用户备注
- reason 退货理由 等
- create_time 订单生成时间
- update_time 修改时间
14)订单内容表 order_content
- id 自增id 主键
- order_id 订单id
- book_id 书籍id
- num 数量
- price 价格,原价
- amount 总价
- discut_money 折扣减免的价格
- activity_id 活动id(活动有折扣)
15)评论表 book_comment (为简单起见假设评论只有对书籍的评论,没有对评论进行回复)
- id 自增id 主键
- book_id 书籍id
- user_id 用户id
- star 星级
- content 评论内容
- create_time 创建时间
- status 状态: 可用/删除
- update_time 修改时间
- audit_status 审核状态
- audit_reason 审核失败的原因
- audit_time 审核时间
- audit_user 审核者(运营id)
16)管理后台操作表 operation
- id 自增id 主键
- user_id 运营账号id
- content 内容
- operate_time 操作时间
备注:实际上不止这么少的表的,为简单起见,暂时就先列出这么多表
5、缓存设计
会在各个api接口中详细说明。
6、api接口设计思想
考虑到高并发时数据库的瓶颈,所以需要把请求的结果缓存起来。这里的策略是:
1)从缓存中获取数据,缓存中有数据则直接返回,或者做简单处理然后返回;
2)缓存没有数据,则从DB中查找数据,然后写回缓存;这种情况叫做“回源”。
3)缓存的key是需要设置过期时间的,避免数据一直占用内存;
4)过期时间的设计,最好是打乱,避免同一时间有大量的key过期导致请求集中去DB请求导致雪崩;
5)根据业务需求,“回源”的时候考虑申请到缓存锁的请求去数据库获取数据并更新缓存,其他请求则sleep一段时间(比如5毫秒10毫秒)然后再去缓存请求,如果请求还是没数据,可以继续等待或者直接返回空数据。
6)没有必要缓存起来的字段,不要缓存;
7)APP不需要用到的字段没有必要返回给APP,比如评论的审核时间、审核者,返回给APP是没用的,因为这些数据不需要展示出来,不会被用到;
8)减少api请求的次数,比如多次请求,要看下能否合并,比如首页,有好几个区域,每个区域都有几条数据。当然多次请求一样可以实现,但是请求次数少,则服务器可以接受更多客户端的请求。
原文地址:https://www.cnblogs.com/guangye/p/9369110.html