功能需求
- 发布动态：类似朋友圈的功能，支持图片、文字、视频。
- 读取动态：支持推荐、最新、最热等栏目。
- 删除动态：支持发布者删除，运营删除（包括硬删除和软删除）。
- 审核动态：需要有正常、审核中、封禁中等。
- 动态送礼、点赞：支持给某条动态送礼、点赞。并且需要给发布者发消息。并且需要有消息列表，可以删除和一键清空。
- 动态运营：运营可以置顶、推荐某个动态，还可以以运营身份发布官方动态。
需求分析和初步设计
考虑到发布动态的人群是主播，所以量不会很大，表的设计不用分表。
动态页面的访问是很频繁的，所以在主页面如果有多张图则使用缩略图，否则使用原图，视频显示第一帧，剩下的交给CDN。
接口读取的时候根据需求拉取动态ID，然后将每条动态的元数据缓存，加快接口速度。
送礼和点赞，要考虑并发和效率，将发消息异步到队列慢慢处理。
发消息方面，提供一个接口，在客户端第一次进入动态页时请求，获取是否有最新消息，后面则由客户端监听消息，来绘制新消息UI。
数据库设计
具体细节就不赘述了，大致有以下几张表：
值得注意的几点：
- 点赞数和礼物数记录在主表，不要sum流水表。（减慢写，加快读）
- 所有表添加
is_delete，表示软删除，涉及违规的才采用真删除，方便运营还原。
代码设计
总体来说这个功能是比较简单的，只是一个上传加查询的过程。
需要注意的：
- 将动态采用元数据缓存起来，一条动态一个，如果动态有修改直接更新该缓存，按照业务，一般设置3-7天过期就好了。
- 首页排序提前用command命令计算好，不同的页面直接获取排好序的动态Id，然后点查缓存。主页可以不用缓存，只是全部拿缓存的过程。（整个返回值套缓存，第一是占redis内存，第二是拿全部出来再解析和直接点查效率差不多，第三是直接点查实时性更好。）
- 一旦后台有删除、封禁操作，将某个动态的缓存删掉就好了，当读不到缓存生成的时候判断
is_delete即可。（不用直接执行command计算命令，第一是时间可能很长，第二是有些算法是根据时间来的，就是需要定期执行。） - 如果点赞的量过大，可以考虑加消息队列，但是可能会存在ABA的问题。（点赞数忽上忽下）