字节跳动青训营大项目总结

项目汇报文档

http://tiktok.zruler.fun/

使用Ctrl+鼠标左键点击进入即可查看！！！！

1、概念

Feed：Feed流中每一条状态或者是消息都是Feed，比如朋友圈中的一个状态就是一个Feed，微博中的一条微博就是Feed。

Feed流：持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页面也都是一个Feed流。

Timeline：Timeline其实是一种Feed流的类型，微博，朋友圈其实都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，因此也用Timeline来表示Feed流。

关注页Feed流：展示其他人的Feed消息的页面，比如朋友圈、微博首页等。

个人页Feed流：展示自己发送过来的Feed消息的页面，比如微信中的相册、微博个人页等。

2、特征

Feed流系统有一些典型的特点，比如：

• 多账号内容流：Feed流系统中肯定会存在成千上万的账号，账号之间可以关注，取关，加好友和拉黑等操作。只要满足这一条，那么就可以当做Feed流系统来设计。
• 非稳定的账号关系：由于存在关注，取关等操作，所以系统中的用户之间的关系就会一直在变化，是一种非稳定的状态。
• 读写比例100:1：读写严重不平衡，读多写少，一般读写比例在10：1，甚至100：1以上。
• 消息必达性要求高：比如发送了一条朋友圈后，结果部分朋友看到了，部分朋友没看到，如果偏偏女朋友没看到，那么可能会产生很严重的感情矛盾，后果很严重。

3、分类

Feed流的分类有很多种，但最常见的分类有两种:

• Timeline：按发布的时间顺序排序，先发布的先看到，后发布的排列在最顶端，类似于微信朋友圈，微博等。这也是一种最常见的形式。产品如果选择Timeline类型，那么就是认为Feed流中的Feed不多，但是每个Feed都很重要，都需要用户看到。
• Rank：按某个非时间的因子排序，一般是按照用户的喜好度排序，用户最喜欢的排在最前面，次喜欢的排在后面。这种一般假定用户可能看到的Feed非常多，而用户花费在这里的时间有限，那么就为用户选择出用户最想看的Top N结果，场景的应用场景有图片分享、新闻推荐类、商品推荐等。

4、实现

解决Feed流最核心的两个问题:一个是存储，另一个是推送

4.1、存储

因为该项目中Feed比较简单，就类比于空间说说，因此可以使用MysQL关系型数据库存储，如果对于数据结构比较复杂的Feed流就要使用NosQL数据库，这样存储更方便与高效，比如MongoDB或者HBase。

4.2、推送

在推送方案里面的，有三种方案，分别是:

• 拉方案：也称为读扩散，用户主动去拉取关注人的Feed内容
• 推方案：也成为写扩散，当用户添加Feed时，会自动将Feed通知给关注的人(优选)

使用Redis Sorted Sets(方便按时间排序Timeline）维护粉丝的Feed集合，当博主添加Feed时，主动将内容推送到粉丝集合中，这样用户可以很方便快速从集合中读取

• 推拉结合：比如微博，大部分用户的账号关系都是几百个，但是有个别用户是1000万以上才使用。

5、表结构设计

CREATE TABLE `t_feed`  (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `content` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '内容',
  `fk_diner_id` INT(11) NULL DEFAULT NULL,
  `praise_amount` INT(11) NULL DEFAULT NULL COMMENT '点赞数量',
  `comment_amount` INT(11) NULL DEFAULT NULL COMMENT '评论数量',
  `fk_restaurant_id` INT(11) NULL DEFAULT NULL,
  `create_date` DATETIME(0) NULL DEFAULT NULL,
  `update_date` DATETIME(0) NULL DEFAULT NULL,
  `is_valid` TINYINT(1) NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = INNODB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = DYNAMIC;