java异步框架feed,Feed流及回复、转发的关系

信息流的现有方案

信息的流动，已经从传统的文章-回复发展成信息流的形式，但是信息流的组织形式，由于其复杂性，想把信息流非常合理的展示出来，还是挺麻烦的。

考虑到一种比较复杂的关系，如下：

topic-root-1 // 主题帖子

- reply-01 // 对主题的回复，楼层帖子

- reply-floor-01-01 // 回复reply-01

- reply-reply-01-01-01 // 回复reply-floor-01-01

- reply+forward-01-01 // 回复且转发 reply-floor-01-01

- reply-floor-01-02

- reply-02

- forward-01

- reply-03

- reply+forward-01

topic-root-2

reddit，网易回帖是基于回复缩进的展示格式，就是，视觉上的最直观的就是回复的回复会空两格，类似于：

一个典型的层级关系的回复列表：

topic

- reply-1

- reply-1-1

- reply-1-1-1

- reply-1-1-1

- reply-1-1-2

- reply-1-1-2-1

- reply-1-1-2-2

- reply-1-1-3

- reply-1-2

- reply-1-2-1

- reply-1-3

- reply-1-4

- reply-2

曾经这种格式很流行，但目前大部分都改成了最多两级的形式， 然后如果是对回复的回复，会@回复的作者，然后再内部记录这个post所回复的id，知乎，贴吧，雪球，头条，微博都是这种形式。

然而，大家对待回复的等级并不相同。

大部分对于回复的处理，都是主贴的附加属性，没有被真正的重视，例如，在贴吧，头条里，回复只能是二等公民，无法展示在feed流中；而雪球，微博，回复也是可以被转发的，然后，通过基于用户的关注关系和推荐算法，回复也可以被独立的展示在Feed流中。

信息流设计

post的子子孙孙，有点像git树一样，每次对回复的回复，都是相当于创建了一个分支。

因此，可以把post和reply合并为一起，保存着同一个表中，在存储层面不区分区分post和reply；在逻辑层面，把reply提升到与post的同等地位，reply也可以点赞，收藏，转发，分享等等。

转发

转发可以被设计为一个独立的动作，转发就是纯粹转发，不能在转发的基础上回复；如果要回复，则需要在回复的时候选择是否转发。

这样的好处是，易于追踪讨论的主题，而不会被一些转发中断信息流。此外，对于转发的回复，可以挂在被转发的文章下，更加集中信息流。

回复

对话

设计

综合上面的分析，将post设计如下：

title: string

content: string

rootId: 如果是独立的内容，rootId为0；如果是对主题的回复，rootId为这个回复的主题id；如果是对回复帖子的回复，rootId为回复帖子的rootId

replyId: 如果是对主题的回复，replyId和rootId一样，都是主题id；如果是对回复帖子的回复，replyId是被回复的帖子id；

branchId: 如果是对主题的回复，branchId和rootId一样，都是主题id；如果是对回复帖子的回复，branchId是该层的楼层帖子id；(被回复的brandId)

forwardId: 如果不是转发，forwardId为0；如果是转发，forwardId为被转发的主题id

midId: 如果是对转发帖子的回复，则设置midId是转发帖子的Id，上面的rootId,replyId, branchId设置为转发帖子

关联关系

用户的follow关系，以及如何查询用户follow的posts，在数据量较小的情况下，可以简单的通过sql查询来完成。