https://apifox.com/apidoc/shared-d1ef64d0-3d7e-44cc-b976-ed2c4717268e
Feed：Feed流中每一条状态或者是消息都是Feed，比如朋友圈中的一个状态就是一个Feed，微博中的一条微博就是Feed。
Feed流：持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页面也都是一个Feed流。
Timeline：Timeline其实是一种Feed流的类型，微博，朋友圈其实都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，因此也用Timeline来表示Feed流。
关注页Feed流：展示其他人的Feed消息的页面，比如朋友圈、微博首页等。
个人页Feed流：展示自己所发布的Feed消息的页面，比如微信中的相册、微博个人页等。
主页Feed流：展示平台所有用户的Feed流，随机推荐，比如抖音主页。
-
Feed分类 Feed流的分类有很多种，但最常见的分类有两种:
-
Timeline：按发布的时间顺序排序，先发布的先看到，后发布的排列在最顶端，类似于微信朋友圈，微博等。这也是一种最常见的形式。产品如果选择Timeline类型，那么就是认为
Feed流中的Feed不多，但是每个Feed都很重要，都需要用户看到。 -
Rank：按某个非时间的因子排序，一般是按照用户的喜好度排序，用户最喜欢的排在最前面，次喜欢的排在后面。这种一般假定用户可能看到的Feed非常多，而用户花费在这里的时间有限，那么就为用户选择出用户最想看的Top N结果，场景的应用场景有图片分享、新闻推荐类、商品推荐等。
-
Feed存储方案 因为该项目中Feed比较简单，就类比于空间说说，因此可以使用MySQL关系型数据库存储，如果对于数据结构比较复杂的Feed流就要使用NoSQL数据库，这样存储更方便与高效，比如MongoDB或者HBase。
本项目的feed流均为文本，相对比较简单，采用MySQL+Redis进行搭配存储。
-
Feed流推送方案 在推送方案里面的，有三种方案，分别是:
-
拉方案：也称为
读扩散，用户主动去拉取关注人的Feed内容。 -
推方案：也成为
写扩散，当用户添加Feed时，会自动将Feed通知给关注的人(优选)，使用Redis Sorted Sets(方便按时间排序Timeline）维护粉丝的Feed集合，当博主添加Feed时，主动将内容推送到粉丝集合中，这样用户可以很方便快速从集合中读取。 -
推拉结合：比如微博，大部分用户的账号关系都是几百个，但是有个别用户是1000万以上才使用。（项目用户量比较大时适合）。
项目的数据库设计
-- User表
CREATE TABLE `users`
(
`id` bigint(0) NOT NULL AUTO_INCREMENT COMMENT 'PK',
`username` varchar(32) NOT NULL,
`password` varchar(200) NULL DEFAULT NULL,
`follow_count` bigint(0) NULL DEFAULT 0,
`follower_count` bigint(0) NULL DEFAULT 0,
`avatar` varchar(255) DEFAULT NULL COMMENT '头像链接',
PRIMARY KEY (`id`)
);
ALTER TABLE `feed`.`users`
ADD UNIQUE INDEX `username&password`(`username`, `password`) USING BTREE COMMENT 'username+password的唯一组合索引';
-- 关注表
CREATE TABLE `relations`
(
`id` bigint(0) NOT NULL AUTO_INCREMENT,
`user_id` bigint(0) NULL DEFAULT 0,
`following_id` bigint(0) NULL DEFAULT 0,
PRIMARY KEY (`id`)
);
ALTER TABLE `feed`.`relations`
ADD UNIQUE INDEX `user_follow`(`user_id`, `following_id`) USING BTREE COMMENT '关注着和被关注者的id构成唯一索引';
-- 博文表
CREATE TABLE `blogs`
(
`id` bigint(0) NOT NULL AUTO_INCREMENT COMMENT 'blog_id',
`title` varchar(128) NOT NULL DEFAULT '' COMMENT '标题',
`content` VARCHAR(512) NULL DEFAULT NULL COMMENT '博文内容',
`favorite_count` bigint(0) NULL DEFAULT 0 COMMENT '点赞量',
`comment_count` bigint(0) NULL DEFAULT 0 COMMENT '评论量',
`user_id` bigint(0) NOT NULL COMMENT 'FK reference user id',
`top` varchar(24) NOT NULL DEFAULT 0 COMMENT '置顶标志字段',
`create_time` datetime(0) NOT NULL DEFAULT CURRENT_TIMESTAMP (0),
`update_time` datetime(0) NOT NULL DEFAULT CURRENT_TIMESTAMP (0),
PRIMARY KEY (`id`)
);
-- 点赞表
CREATE TABLE `favorites`
(
`id` bigint(0) NOT NULL AUTO_INCREMENT,
`user_id` bigint(0) NOT NULL,
`blog_id` bigint(0) NOT NULL,
`is_favorite` tinyint(0) NULL DEFAULT 0,
PRIMARY KEY (`id`)
);
ALTER TABLE `feed`.`favorites`
ADD UNIQUE INDEX `user_blog`(`user_id`, `blog_id`) USING BTREE COMMENT 'user_id+blog_id的唯一索引';
-- 评论表
CREATE TABLE `comments`
(
`id` bigint(0) NOT NULL AUTO_INCREMENT,
`user_id` bigint(0) NOT NULL,
`blog_id` bigint(0) NOT NULL,
`content` varchar(500) DEFAULT '',
`create_time` datetime(0) NOT NULL DEFAULT CURRENT_TIMESTAMP (0),
PRIMARY KEY (`id`)
);
ALTER TABLE `feed`.`comments`
ADD INDEX `blog_id`(`blog_id`) USING BTREE COMMENT 'blogId的普通索引';项目的总体结构
- Redis的****Sorted Sets集合使用
- 存储用户个人feed集合，方便用户更快的获取个人发布的feed流信息，用户发布和删除feed时候会对于Redis存储集合进行操作。
- 存储用户关注的所有用户发布的feed集合，自动根据发布时间作为score来进行排序，用户发布feed时会主动推送到所有粉丝的该集合内，用户关注新用户也会将所关注用户的所有feed信息存储进入集合排序。用户取关时也会将对应的取关者的feed流从该集合中去除。
- feed流传统分页问题解决
由于Feed流下数据是不断更新的，因此数据的角标也会随之变化，传统的分页模式会导致出现数据重复读的情况。
使用滚动分页
滚动分页的核心就是：我们需要记录每次操作的最后一条，然后从这个位置开始读取数据。
使用缓存读优化~~~~
- 代码层优化
- 使用go并发编程对于一些代码进行优化（如查询feed流时需要的查询关注状态以及点赞状态可以并发进行）。
- 使用消息中间件比如（RabbitMQ、Kafka、Pulsar）来对于用户发布feed时异步的将feed推送到粉丝的feed集合中去。
- 存储层面优化 能满足需求的系统主要有两类，一类是阿里云的Tablestore单系统，一类是开源组件组成的组合系统。
- 开源组件组成的组合系统：包括MySQL、Redis，这些系统单个都不能解决Feed流系统中遇到的问题，需要组合在一起，各司其职才能完成一个Feed流系统，适用于热衷开源系统，人多且喜欢运维操作的团队。
- Tablestore单系统：只使用Tablestore单个系统就能解决上述的所有问题。
阿里Tablestore是基于阿里盘古分布式文件系统的一个处理大数据的一个产品。可以将TableStore的架构简单理解为Lucene + BigTable。
- BigTable解决大数据存储的问题；
- Lucene解决搜索和排序的问题。
Tablestore在多年前就已经开始重视Feed流类型业务，官方之前也发表过多篇文章介绍，功能上也在专门为Feed流系统特别定制设计，所以到今天，只使用Tablestore一款产品，是可以满足上述需求的。选择Tablestore做Feed流系统的用户具有以下一些特征：
- 产品设计目标规模大，千万级或亿级。
- 不喜欢运维，喜欢专注于开发。
- 高效率团队，希望尽快将产品实现落地。
- 希望一劳永逸，未来系统随着用户规模增长可以自动扩容。
- 希望能按量付费，用户少的时候费用低，等用户增长起来后费用在跟随用户数增长。
如果具有上述四个特征的任何一个，那么都是适合于用Tablestore。
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent