备注：找不到原作者了。
现在大部分SNS网站都有一个功能，就是显示好友的活动状态，比如你的好友上传了一张照片、分享了一篇文章等等动作，都可以显示在你的页面里，这样大大增强了社区的互动性，也成为现在SNS网站的主要特征，对于这样一个功能，从设计角度，还是值得思考的，并不简单，特别是用户越来越多，信息海量增长的时候，我未必能提出十全十美的方案，但我们可以由简如繁梳理一下思路。
首先我们要定义用户的活动消息，也可以理解为一个事件，就是我们举的例子：用户上传照片、与别人结为好友、修改了个人资料等等，动作各有不同，但需要在结构上通用，我们先设计一个
ID //消息ID
UserID //用户ID
MsgType //消息类型，比如加好友、上传照片等不同的类型
EventMsg //消息的内容，这里我们可以用Json的数据格式来描述出不同的活动内容
CreateTime //消息创建时间
这个结构也是个数据库的结构，当用户做个一个动作之后，就会创建这样一个消息，并保存在数据库中，当显示好友的活动信息时，就从这张表里查询自己好友id的数据，并按时间显示，这个做法是一个最简单的实现，但会出现一些问题，当你与一个用户成为好友之后，该好友之前发生的动作会显示出来，而不是在成为好友时点之后的动作，同样，切断好友关系之后也有类似的问题，如果从业务角度和用户体验上可以接受的话，也没什么，但由于信息是按时间排序，有时候会给用户错乱的感觉，还有，这个信息不能删除，如果删除了所有好友就看不到这条信息了，但在Facebook里是则是可以删除好友的动作信息的，这个方法还有一个问题是，所有信息都放在一张大表里，在信息爆炸增长，个人好友也很多的情况下，查询效率会非常低，产生严重的性能障碍，如果对这张表做水平切分，则在实现上复杂了许多，性能也未必好很多，接下来我们再思考是否有更好的解决办法。
在SNS的理论里，个人好友的合理数量在150个左右（），SNS网站应该是有好友数量的限制的，我们就按人均150个好友来设想，是否可以在用户发生某些动作之后，针对他的所有好友都写入一条信息，所能解决的是，信息是在用户成为好友时点之后写入，用户可以删除好友的活动信息，不影响其他用户的显示，在显示时查询效率要高很多，但是负面效应也十分明显，一个用户的动作有平均150个写入，对于数据库来说开销也非常大，我们想想在这样的设计下，是否可以提高性能。
首先看数据库设计，我们要把信息表和信息与用户的对应表分开，我们上面定义的数据结构保留，我们定义它的表名为Event，我们再新建一张表EventUser，结构如下
ID& //主键
EventID //Event表的ID
FriendUserID //好友的ID
CreateTime //消息创建时间
对FriendUserID做索引，当用户发生动作时，首先将动作信息写入Event表，之后查找用户的所有好友，将EventID、好友ID逐条写入EventUser表，当要显示自己的好友活动信息是，查询EventUser中FriendUserID等于自己ID的信息，并和Event表做一个Join查询就可以了。
进一步提升性能的方法，将Event里的信息缓存，比如用Memcached，EventID做为Key，内容做为Value，这样，查询EventUser是就不用Join Event表，而是从缓存里读取，由于要记录给每个好友的信息，所以EventUser会变得非常大，平均要比我们最初设计的数据容量大150倍，我们对EventUser表做水平切分，根据用户ID做Hash算法，基本上能均匀的分配到所有的表中，至于EventUser水平切分的算法还有多种，根据实际情况来定，总的来说就是把数据分摊掉，同时EventUser里的数据可以不永久保存，做定期删除，可以保持数据容量在一个合理的范围内。
对于用户动作之后的数据写入，可以采用异步的方法，在发生动作时，抛出一个消息，由另外一个线程在做写入操作，如果对每个动作平均150次的写入仍存顾虑，我们可以针对每个用户开出一块内存空间，或是缓存，里面保存最后50条最新的好友动作，并在每条记录里做一个持久化标志，当有50条信息都标志是“未持久化”时，做一次数据库的写入，然后把信息置为“已持久化”，这种非实时写入的方式，可以提高一定的数据库效率，显示时，先从内存中取出，再查数据库。
还有一些问题，对不不同消息类型的处理方式不同，比如用户修改个人资料，并不是每次发生这样的动作都要做一次给朋友做一次“群发”的操作，如果遇到这个人在短时间内做了多次修改个人资料的操作，就给朋友发出多个消息，会产生垃圾信息，让人觉得很怪异，所以对于这样的操作会有一定的时效性，比如在一天之内的修改个人资料，就是一个消息，这时候的处理是更新，而不是插入。
以上是我对SNS中好友动态功能的设计思路，可能还有一些未想到的问题，还需要认真思考。
Views(...) Comments()SNS网站feed的设计思考 -
- ITeye博客
博客分类：
SNS网站一般都有这么一个功能：feed或者叫做新鲜事之类的
之前在我们自己的网站也做了类似的一个功能，当时让人最郁闷的就是数据量的问题，上网搜了下，大部分结构都是类似。
我当时设计了这么一种简单的机制，数据量相对较小，但是运算复杂，并且限制较多：
1）feed字典表：
event_type: int, //事件类别：写日记，上传照片，成为好友等等
share_type: int, //公开类别：私密信息（收到新消息之类的），公开信息等
msg:string //feed消息模板
2）user_feed表，用于保存用户操作的每个：
user_feeds
feed_id: int, //feed字典表所属ID
user_id: int, //用户名
share_type: int, //公开类别
params: string,//参数，可以是jason格式
attach_text: string,//附加说明
created_at: datetime
updated_at: datetime
3）user_watch表，用于保存用户对哪些好友进行关注，关注哪种类别消息：
user_watches
user_id, //用户ID
friend_id, //好友ID
watch_type
在这种结构下，我们采用的方法就是连接查询并生成该用户(current_account)可见好友的feeds:
select uf.*
from user_feeds uf,user_watches uw
where uf.user_id = uw.friend_id and uf.user_id = (current_account_id) and uf.share_type = (public)
个人产生私有feeds
select * from user_feeds where user_id = (current_account_id) and uf.share_type = (private)
在页面层再调用feed render方法:
render_feed(user_feed) 来根据feed类别来渲染不同的显示。
然后做页面层的cache，每10分钟或者20分钟刷新一次，并且每一段时间清空一次过期的user_feeds表。
目前这种机制我们使用的还没有遇到太多问题，在我们网站还是百万量级的存储。
这种方式最大的缺点就是无法删除feed，并且feed需要重复运算。优点就是存储空间小。
当时想到一种支持删除feed的方法就是做一个feed_watches表，用于存储某个查看某个user_feed的状态，
目前没有实现。
目前其他网站的做法貌似都是使用了一张表专门存储某个用户收到的feed。
这个表会非常大，每天产生100万个事件，如果平均每个人有20个好友，那么将会有两千万条消息。
假设要保存10天的数据，将会有两亿多条数据，只能通过分表来解决。
不知道Facebook这些公司咋搞的~
浏览: 26374 次
来自: 上海
大哥，可不可以搞个DEMO出来。这个更管用。道理咱懂，搞出来有 ...
可以考虑下nosql来实现，一些知名的SNS都是用NOSQL实 ...
请问，去IBM以后做的还是ruby 和 rails 吗？
你在哪个部门哪个team？做dev？
有必要给每一个好友创建一条feed记录吗？考虑到用户可以删除好 ...休闲娱乐生活服务其他类别
Feed流设计：怎样用策略掌控用户视线？ 早期的Feed流主要是把用户关注的内容以Timeline的形式展开。但是随着用户场景的丰富，Feed流也有了更多的变种。本篇文章主要讨论如何设计一个Feed流，以及Feed流背后的设计逻辑。▌0.前言首先，什么是Feed流？Feed是一个互联网早期的概念，本意是RSS中用来接收信息来源更新的接口。现在的定义比较宽泛，一般而言，持续更新并呈现给用户的内容都叫做Feed流。朋友圈是feed流，微博首页是feed流，知乎首页是feed流，各种门户的内容也是feed流。换句话说，我们大量的在线时间和视线，实际上都被Feed流掌控。早期的Feed流主要是把用户关注的内容以Timeline的形式展开。但是随着用户场景的丰富，Feed流也有了更多的变种。本篇文章主要讨论如何设计一个Feed流，以及Feed流背后的设计逻辑。▌1. Feed流设计的要核心问题之前提到，对于搜索而言，基本上是召回用户感兴趣的内容，然后进行筛选排序。其实Feed的设计也是如此。一个Feed流永远是在解决两个核心问题：应该展示给用户什么内容这些内容该怎么排序不同的Feed流其实是在给出这两个问题不同的答案。不同的答案也没有绝对的对与错，更多的是场景是否合适。▌2. 永恒的经典——TimelineTimeline，一般而言，不对用户主动要求获取的内容进行筛选，同时所有的内容按照时间排序。最经典的案例就是朋友圈。关于Feed流设计的两个核心问题，微信朋友圈的回答是这样的：应该展示给用户什么内容：用户好友发的内容这些内容该怎么排序：按照时间先后顺序Timeline简单的内容选取和排序非常易于用户理解，充满了极简主义的哲学：随时更新，吸引用户随时打开使用，而每次更新的部分都有限也保证了大部分用户不会错过任何消息。微信也用这个设计，获取了用户大量的时间。既然Timeline有这么多优点，那么Feed流为什么还会迭代衍生出来其他的设计？其实这里也牵扯到一个问题，Timeline有一个致命的缺点——内容呈现效率最为低下。需要内容提供方非常克制，同时也需要用户对这些内容足够关注。微信朋友圈的内容是用户自己的个人展示，注定不会大量更新；同时选择都是基于熟人关系，能引起用户足够的关注。正是这两个原因，保证了朋友圈内容虽然效率低下，但是还是极具吸引力。如果动辄每天上千条陌生人更新的内容，使用Timeline的形式呈现出来，想见一下，这是一个多么缺乏思考的设计。▌3. 重力排序算法——兼顾热度和更新时间如果每天有更新量很大的Feed流，同时大部分内容没有太大用户价值，这种情况下我们该怎么排序？这个场景其实也很常见，也是一些PM在实际工作中遇到的棘手问题。答案就是重力排序算法。重力排序算法中，对于一个在Feed流中的内容而言，有两种力量：重力和拉力。重力是持续让内容往下掉的力，这个重力就是时间，因为新的内容会把老的内容刷下去；同时拉力则是让内容排序往前的力，比如知乎的赞，贴吧的回复。这样的排序算法实现方式有很多，这里可以简单介绍一种，也是来自Reddit的核心排序算法：其中：H表示能代表内容热度的值：比如说收到的赞，比如说浏览量，也可以是综合类似的指标，加权求和得到的值。T代表内容发布的时间，代表一个时间的起始值，只要比最早发布的内容早就行了（比如用公司创立时间）。T-T0用来衡量一个内容的新旧程度，单位为秒，T-T0越大，则代表内容越新。A也是设立的参数，A越大，T-T0的影响力越小，则内容更新的越慢。一般而言初始值可以用36000，10个小时的秒数，后续不断迭代。关于Feed流设计的两个核心问题，重力排序算法的回答是这样的：应该展示给用户什么内容：用户表现出喜好的内容都推给用户，虽然用户不一定看得见后面的。这些内容该怎么排序：按照时间衰减因素和内容受欢迎程度综合排序。
上一页&1共2页热门新闻更多
热门游戏相关新闻热门视频发现好货
阅读下一篇视频推荐全部答案（共1个回答）
词汇题　　15. The word“fed相关信息专家你好我身体很健康就是阴茎短小正常情况...我的儿子今年18岁阴茎短小医生建议做阴茎...做爱时间不长就泄了!怎样能让阴茎变大,更...我的阴茎短小并且包皮过长怎么办?性生活总...阴茎短小
阴茎短小 看看 ...阴茎短小容易怀孕吗。精液随着就流出来了。...好像把手指插入阴道了,不知道有没有弄破处...医生你好!我和男友同房,我是4号来例假,...我早上尿完尿后会滴几滴和精液东西粘稠的还...自慰后龟头上有两个红点,还有点痒是怎么回...勃起功能下降龟头流出白色包茎会影响射割除包皮手术轻按睾丸疼痛" in line 20 is closest in meaning to　　(A) put　　(B) eaten　　(C) bitten　　(D) nourished　　又来了一道词汇题。无论你认识与否，先将它归源。浏览四个选项，我们知道fed是feed的过去式或者过去分词。如果你平时背过这个单词，它可能早已经“明花有主”，即选择了D(nourished)。倘若你不认识这个单词或者对自己的初步判断不确定的话，我们现在就将它定位回原文。在第20行，我们找到了包含这个词的句子，“The wire to make the barbs is fedsintosthe machine from the sides and cut to length by knives that cut diagonally through the wire to produce a sharp point.”。这个句子乍一看来似乎有点费解，不过仔细解读后我们还是能理解它的意思，它的大致意思是“要制成带刺的那条金属线被从边上在(进)机器，然后用刀子顺着金属线对角地割成刺状”。了解一下为什么制成刺状有助于我们解题。回头浏览一下原文，我们知道这花样甚多的金属线都是为了有效地防止牛畜对庄稼的侵犯，所以刺状的金属线起了围墙的作用。但怎么让金属线带刺呢？这正是本题要你理解的。如果你在上大学时，曾经试图在宿舍里的窗户旁边安装铁丝用来凉衣服的话，你就会理解为什么要将金属线的两端固定在机器上——将金属线的两端固定可以使金属线崩直，以便刻刺。这么看来，选项D是错误的，而A却很可能正确。但是，如果A正确的话，为什么要用feed这个词来代替put呢？这个反问似乎很愚蠢。但事实上feed的意思是“饲养，喂”的意思，与put“放”千差万别。所以，我们排除选项A和D。现在，我们只剩下B和C，eat是“吃”的意思，而bit的动词是“咬”的意思。应该是哪一个呢？如果只按中文来判断的话，似乎“吃”更常用。但是，仔细理解eat这个词的意思，你就会发现eat只能是吃某种食物，机器不会吃，金属线也不是食物。因此只能用bit这个词。这是，原来的句子就成了“要制成刺的那条金属线被从边上咬进机器，然后用刀子顺着金属线对角地割成刺状”。所以正确答案是C.这道题实在有些费劲。大部分的考生都做错了，包括作者本人最初做这一道题时，也误选了put。
feed通常用人作主语，Sb feed(s)sth.(animals or sb.),Sth(animal) feed on sth.如：We feed the...
是内嵌病毒，删除它吧，对浏览器不会有影响 的。
agree onbe based onbe fixed oncall oncheck onfeed ... oncongratulate ...ondepend...
选择Dscenery是指自然景色spectacle强调观览物，展览物且landscape scenery＝scenery of a landscape 自然景色...
答: 吉隆坡容器胶囊酒店我是9.28号凌晨到机场，订的28号00:00--23:50这种房，我28号凌晨能入住吗？
答: 你朋友是宫颈息肉.推荐一文,供你参考:什么是子宫颈息肉子宫颈息肉是慢性宫颈炎表现的一种，在已婚妇女中比较多见。　　子宫颈是子宫下端的部分，其内腔呈圆筒形或梭形，...
答: li660912同学：您好！您有这样的想法非常好，说明您知道父母为了您成长的辛苦和劳累。呵呵，有这样的心理，我想您一定会在学习上下苦功夫，以优异的成绩来回报父母...
大家还关注
确定举报此问题
举报原因(必选)：
广告或垃圾信息
激进时政或意识形态话题
不雅词句或人身攻击
侵犯他人隐私
其它违法和不良信息
报告，这不是个问题
报告原因(必选)：
这不是个问题
这个问题分类似乎错了
这个不是我熟悉的地区后使用快捷导航没有帐号？
Feed流设计：怎样用策略掌控用户视线？
产品经理不再是一个单纯的职位,而是一种思维方式,这种思维是所有互联网人必备的,做互联网的人不能不懂产品,关注产品,改变生活.
作者：潘一鸣全文共 2144 字，阅读需要 4 分钟 BEGIN 早期的Feed流主要是把用户关注的内容以Timeline的形式展开。但是随着用户场景的丰富，Feed流也有了更多的变种。本篇文章主要讨论如何设计一个Feed流，以及Feed流背后的设计逻辑。0.前言首先，什么是Feed流？Feed是一个互联网早期的概念，本意是RSS中用来接收信息来源更新的接口。现在的定义比较宽泛，一般而言，持续更新并呈现给用户的内容都叫做Feed流。朋友圈是feed流，微博首页是feed流，知乎首页是feed流，各种门户的内容也是feed流。换句话说，我们大量的在线时间和视线，实际上都被Feed流掌控。早期的Feed流主要是把用户关注的内容以Timeline的形式展开。但是随着用户场景的丰富，Feed流也有了更多的变种。本篇文章主要讨论如何设计一个Feed流，以及Feed流背后的设计逻辑。1. Feed流设计的要核心问题之前提到，对于搜索而言，基本上是召回用户感兴趣的内容，然后进行筛选排序。其实Feed的设计也是如此。一个Feed流永远是在解决两个核心问题：应该展示给用户什么内容这些内容该怎么排序不同的Feed流其实是在给出这两个问题不同的答案。不同的答案也没有绝对的对与错，更多的是场景是否合适。2. 永恒的经典TimelineTimeline，一般而言，不对用户主动要求获取的内容进行筛选，同时所有的内容按照时间排序。最经典的案例就是朋友圈。关于Feed流设计的两个核心问题，微信朋友圈的回答是这样的：应该展示给用户什么内容：用户好友发的内容这些内容该怎么排序：按照时间先后顺序Timeline简单的内容选取和排序非常易于用户理解，充满了极简主义的哲学：随时更新，吸引用户随时打开使用，而每次更新的部分都有限也保证了大部分用户不会错过任何消息。微信也用这个设计，获取了用户大量的时间。既然Timeline有这么多优点，那么Feed流为什么还会迭代衍生出来其他的设计？其实这里也牵扯到一个问题，Timeline有一个致命的缺点内容呈现效率最为低下。需要内容提供方非常克制，同时也需要用户对这些内容足够关注。微信朋友圈的内容是用户自己的个人展示，注定不会大量更新；同时选择都是基于熟人关系，能引起用户足够的关注。正是这两个原因，保证了朋友圈内容虽然效率低下，但是还是极具吸引力。如果动辄每天上千条陌生人更新的内容，使用Timeline的形式呈现出来，想见一下，这是一个多么缺乏思考的设计。2. 重力排序算法兼顾热度和更新时间如果每天有更新量很大的Feed流，同时大部分内容没有太大用户价值，这种情况下我们该怎么排序？这个场景其实也很常见，也是一些PM在实际工作中遇到的棘手问题。答案就是重力排序算法。重力排序算法中，对于一个在Feed流中的内容而言，有两种力量：重力和拉力。重力是持续让内容往下掉的力，这个重力就是时间，因为新的内容会把老的内容刷下去；同时拉力则是让内容排序往前的力，比如知乎的赞，贴吧的回复。这样的排序算法实现方式有很多，这里可以简单介绍一种，也是来自Reddit的核心排序算法：其中：H表示能代表内容热度的值：比如说收到的赞，比如说浏览量，也可以是综合类似的指标，加权求和得到的值。T代表内容发布的时间，代表一个时间的起始值，只要比最早发布的内容早就行了（比如用公司创立时间）。T-T0用来衡量一个内容的新旧程度，单位为秒，T-T0越大，则代表内容越新。A也是设立的参数，A越大，T-T0的影响力越小，则内容更新的越慢。一般而言初始值可以用36000，10个小时的秒数，后续不断迭代。关于Feed流设计的两个核心问题，重力排序算法的回答是这样的：应该展示给用户什么内容：用户表现出喜好的内容都推给用户，虽然用户不一定看得见后面的。这些内容该怎么排序：按照时间衰减因素和内容受欢迎程度综合排序。3. 智能排序双刃剑Facebook使用智能排序之后据称效果拔群，于是我们看到越来越多的社交网络放弃使用Timeline排序，转入智能排序的阵营，国外的Twitter，国内的微博和知乎。智能排序牵扯到复杂的模型构建和机器学习，这里只阐述下简单的原理。首先，系统需要知道什么是一个内容被展示的目标值。比如微博，一个内容被展示的目标值是转发，评论，点赞的次数。那么通过大量的样本的机器学习，系统对于什么是好的内容会有一个预测。这个对于一个内容的预测，则是的智能排序的基础。接下来，系统会屏蔽掉一些违规的内容，比如Facebook处罚标题党，知乎处罚抱团点赞。其次，为了用户内容的质量，系统会在用户的Feed中增加一些热门的内容。最后，考虑内容和用户的亲密度、系统认为内容受欢迎的程度、内容时间衰减性等因素后，系统进行综合排序。听起来智能排序是一个很好的主意。但是，智能排序也是一把双刃剑。算法质量的高要求，导致一些技术比较差的公司，使用智能排序效果不佳。另一方面，因为智能排序的不透明性和扩展性，过度的商业化更是成为了用户体验的头号凶手。有的内容因为用户买了粉丝头条而可以排在Feed流前面，有的内容只要有足够的推广费，可以绕过关注关系，呈现在用户面前。智能排序如果被过度商业化，那么Feed流的用户体验也会越来越差。4. 总结Feed流的设计原理其实讲起来比较简单，如果需要成型的排序算法，也可以找到很多，但是更重要的是，什么是真正适合的选择。如果选择Timeline的排序，那么就需要考虑用户关注的内容是否足够有吸引力。如果选择重力排序算法，那么就需要考虑该如何选择参数保证最后的展示效果。如果加入不断壮大的智能排序大军，那么就需要考虑是否有足够的技术实力和产品自制力。重要的是思考清楚两个问题：应该展示给用户什么内容这些内容该怎么排序Don’t waste life in doubts and fears，just make a choice. END 本文由 @潘一鸣 原创发布于人人都是产品经理。未经许可，禁止转载点击“阅读原文”下载APP
关于威腾网什么是威腾网？
网站地图快速找到你想要的
微信扫一扫关注我们