今日头条feed流（信息流 feed）
本文目录一览：
feed流是什么意思
1、feed流即持续更新并呈现给用户内容的信息流。feed是将用户主动订阅的若干消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容。
2、feed直接翻译是饲料的意思，其实是把用户都比喻成爱吃东西得某种动物，不断的给他喂食，满足他的需求，wiki百科上定义是一种数据格式，网站可通过它将最新信息传播给用户，用户能够订阅网站的先决条件是网站可提供持续更新的信息。流，就是他的呈现形式，就是这个信息怎么呈现的，大多数的都是根据时间排列的形式呈现的。使用了feed流的APP有很多，例如：微信朋友圈、百度信息流、今日头条推荐页等等。
探究的一般过程是从发现问题、提出问题开始的,发现问题后,根据自己已有的知识和生活经验对问题的答案作出假设．设计探究的方案,包括选择材料、设计方法步骤等．按照探究方案进行探究,得到结果,再分析所得的结果与假设是否相符,从而得出结论．并不是所有的问题都一次探究得到正确的结论．有时,由于探究的方法不够完善,也可能得出错误的结论．因此,在得出结论后,还需要对整个探究过程进行反思．探究实验的一般方法步骤：提出问题、做出假设、制定计划、实施计划、得出结论、表达和交流．
科学探究常用的方法有观察法、实验法、调查法和资料分析法等．
观察是科学探究的一种基本方法．科学观察可以直接用肉眼,也可以借助放大镜、显微镜等仪器,或利用照相机、录像机、摄像机等工具,有时还需要测量．科学的观察要有明确的目的；观察时要全面、细致、实事求是,并及时记录下来；要有计划、要耐心；要积极思考,及时记录；要交流看法、进行讨论．实验方案的设计要紧紧围绕提出的问题和假设来进行．在研究一种条件对研究对象的影响时,所进行的除了这种条件不同外,其它条件都相同的实验,叫做对照实验．一般步骤：发现并提出问题；收集与问题相关的信息；作出假设；设计实验方案；实施实验并记录；分析实验现象；得出结论．调查是科学探究的常用方法之一．调查时首先要明确调查目的和调查对象,制订合理的调查方案．调查过程中有时因为调查的范围很大,就要选取一部分调查对象作为样本．调查过程中要如实记录．对调查的结果要进行整理和分析,有时要用数学方法进行统计．收集和分析资料也是科学探究的常用方法之一．收集资料的途径有多种．去图书管查阅书刊报纸,拜访有关人士,上网收索．其中资料的形式包括文字、图片、数据以及音像资料等．对获得的资料要进行整理和分析,从中寻找答案。
基于时间线的Feed流后台系统设计
Feed流产品在我们手机APP中几乎无处不在，常见的Feed流比如微信朋友圈、新浪微博、今日头条等。对Feed流的定义，可以简单理解为只要大拇指不停地往下划手机屏幕，就有一条条的信息不断涌现出来。就像给牲畜喂饲料一样，只要它吃光了就要不断再往里加，故此得名Feed（饲养）。
大多数Feed流产品都包含两种Feed流，一种是基于算法推荐，另一种是基于关注（好友关系）。例如下图中的微博和知乎，顶栏的页卡都包含“关注”和“推荐”这两种。两种Feed流背后用到的技术差别会比较大。本文将重点探索一下“关注”页卡的后台实现方式。
图片来源:知乎
不同于“推荐”页卡那种千人前面算法推荐的方式，通常“关注”页卡所展示的内容先后顺序都有固定的规则，最常见的规则是基于时间线来排序，也就是展示“我关注的人所发的帖子，根据发帖时间从晚到早依次排列”。
Feed流实现方案介绍
读扩散也称为拉模式，这应该是最符合我们直觉的一种实现方式。如下图：
每一个内容发布者都有一个自己的发件箱（“我发布的内容”），每当我们发出一个新帖子，都存入自己的发件箱中。当我们的粉丝来阅读时，系统首先需要拿到粉丝关注的所有人，然后遍历所有发布者的发件箱，取出他们所发布的帖子，然后依据发布时间排序，展示给阅读者。
这种设计，阅读者读一次Feed流，后台会扩散为N次读操作（N等于关注的人数）以及一次聚合操作，因此称为读扩散。每次读Feed流相当于去关注者的收件箱主动拉取帖子，因此也得名拉模式。
这种模式的好处是底层存储简单，没有空间浪费。坏处是每次读操作会非常重，操作非常多。设想一下如果我关注的人数非常多，遍历一遍我所关注的所有人，并且再聚合一下，这个系统开销会非常大，时延上可能达到无法忍受的地步。因此读扩散主要适用系统中阅读者关注的人没那么多，并且刷Feed流并不频繁的场景。
拉模式还有一个比较大的缺点就是分页不方便，我们刷微博或朋友圈，肯定是随着大拇指在屏幕不断划动，内容一页一页的从后台拉取。如果不做其他优化，只采用实时聚合的方式，下滑到比较靠后的页码时会非常麻烦。
据统计，大多数Feed流产品的读写比大概在100:1，也就是说大部分情况都是刷Feed流看别人发的朋友圈和微博，只有很少情况是自己亲自发一条朋友圈或微博给别人看。因此，读扩散那种很重的读逻辑并不适合大多数场景。我们宁愿让发帖的过程复杂一些，也不愿影响用户读Feed流的体验，因此稍微改造一下前面方案就有了写扩散。写扩散也称为推模式，这种模式会对拉模式的一些缺点做改进。如下图：
系统中每个用户除了有发件箱，也会有自己的收件箱。当发布者发表一篇帖子的时候，除了往自己发件箱记录一下之外，还会遍历发布者的所有粉丝，往这些粉丝的收件箱也投放一份相同内容。这样阅读者来读Feed流时，直接从自己的收件箱读取即可。
这种设计，每次发表帖子，都会扩散为M次写操作（M等于自己的粉丝数），因此成为写扩散。每篇帖子都会主动推送到所有粉丝的收件箱，因此也得名推模式。
这种模式可想而知，发一篇帖子，背后会涉及到很多次的写操作。通常为了发帖人的用户体验，当发布的帖子写到自己发件箱时，就可以返回发布成功。后台另外起一个异步任务，不慌不忙地往粉丝收件箱投递帖子即可。写扩散的好处在于通过数据冗余（一篇帖子会被存储M份副本），提升了阅读者的用户体验。通常适当的数据冗余不是什么问题，但是到了微博明星这里，完全行不通。比如目前微博粉丝量Top2的谢娜与何炅，两个人微博粉丝过亿。
设想一下，如果单纯采用推模式，那每次谢娜何炅发一条微博，微博后台都要地震一次。一篇微博导致后台上亿次写操作，这显然是不可行的。另外由于写扩散是异步操作，写的太慢会导致帖子发出去半天，有些粉丝依然没能看见，这种体验也不太好。
通常写扩散适用于好友量不大的情况，据悉微信朋友圈正是写扩散模式。每一名微信用户的好友上限为5000人，也就是说你发一条朋友圈最多也就扩散到5000次写操作，如果异步任务性能好一些，完全没有问题。
读写混合也可以称作推拉结合。这种方式可以兼具读扩散和写扩散的优点。我们首先来总结一下读扩散和写扩散的优缺点：
仔细比较一下读扩散与写扩散的优缺点，不难发现两者的适用场景是互补的。因此在设计后台存储的时候，我们如果能够区分一下场景，在不同场景下选择最适合的方案，并且动态调整策略，就实现了读写混合模式。如下图：
对于那些活跃用户登录刷Feed流时，他直接从自己的收件箱读取帖子即可，保证了活跃用户的体验。当一个非活跃的用户突然登录刷Feed流时，我们一方面需要读他的收件箱，另一方面需要遍历他所关注的大V用户的发件箱提取帖子，并且做一下聚合展示。在展示完后，系统还需要有个任务来判断是否有必要将该用户升级为活跃用户。因为有读扩散的场景存在，因此即使是混合模式，每个阅读者所能关注的人数也要设置上限，例如新浪微博限制每个账号最多可以关注2000人。如果不设上限，设想一下有一位用户把微博所有账号全部关注了，那他打开关注列表会读取到微博全站所有帖子，一旦出现读扩散，系统必然崩溃；即使是写扩散，他的收件箱也无法容纳这么多的微博。
读写混合模式下，系统需要做两个判断。一个是哪些用户属于大V，我们可以将粉丝量作为一个判断指标。另一个是哪些用户属于活跃粉丝，这个判断标准可以是最近一次登录时间等。这两处判断标准就需要在系统发展过程中动态地识别和调整，没有固定公式了。
可以看出读写结合模式综合了两种模式的优点，属于最佳方案。然而他的缺点是系统机制非常复杂，给程序员带来无数烦恼。通常在项目初期，只有一两个开发人员，用户规模也很小的时候，一步到位地采用这种混合模式还是要慎重，容易出bug。当项目规模逐渐发展到新浪微博的水平，有一个大团队专门来做Feed流时，读写混合模式才是必须的。
前文已经叙述了基于时间线的Feed流常见设计方案，但实操起来会比理论要麻烦许多。接下来专门讨论一个困难点——Feed流的分页。不管是读扩散还是写扩散，Feed流本质上是一个动态列表，列表内容会随着时间不断变化。传统的前端分页参数使用page_size和page_num，分表表示每页几条，以及当前是第几页。对于一个动态列表会有如下问题：
在T1时刻读取了第一页，T2时刻有人新发表了“内容11”，在T3时刻如果来拉取第二页，会导致错位出现，“内容6”在第一页和第二页都被返回了。事实上，但凡两页之间出现内容的添加或删除，都会导致错位问题。
为了解决这一问题，通常Feed流的分页入参不会使用page_size和page_num，而是使用last_id来记录上一页最后一条内容的id。前端读取下一页的时候，必须将last_id作为入参，后台直接找到last_id对应数据，再往后偏移page_size条数据，返回给前端，这样就避免了错位问题。如下图：
采用last_id的方案有一个重要条件，就是last_id本身这条数据不可以被硬删除。设想一下上图中T1时刻返回5条数据，last_id为内容6；T2时刻内容6被发布者删除；那么T3时刻再来请求第二页，我们根本找不到last_id对应的数据了，也就无法确认分页偏移量。通常碰到删除的场景，我们采用软删除方式，只是在内容上置一个标志位，表示内容已删除。由于已经删除的内容不应该再返回给前端，因此软删除模式下，找到last_id并往后偏移page_size条，如果其中有被删除的数据会导致获得足够的数据条数给前端。这里一个解决方案是找不够继续再往下找，另一种方案是与前端协商，允许返回条数少于page_size条，page_size只是个建议值。甚至大家约定好了以后，可以不要page_size参数。
实际业务应用
文章最后结合我们自身业务，介绍一下实际业务场景中碰到的一个非常特殊的Feed流设计方案。直享直播是一款直播带货工具，主播可以创建一场未来时刻的直播，到时间后开播卖货，直播结束后，主播的粉丝可以查看直播回放。这样，每个直播场次就有三种状态——预告中（创建一场直播但还未开播）、直播中、回放。作为观众，我可以关注多位主播，这样从粉丝视角来看，也会有个直播场次的Feed流页面。这个Feed流最特殊的地方在于它的Feed流排序规则。
Feed流排序规则：
1.我关注的所有主播，正在直播中的场次排在最前；预告中的场次排中间；回放场次排最后
2.多场次都在直播中的，按开播时间从晚到早排序
3.多场次都在预告中的，按预计开播时间从早到晚排序
4.多场次都在回放的，按直播结束时间从晚到早排序
问题分析
本需求最复杂的点在于Feed流内容融入的“状态”因素，状态的转变会直接导致Feed流顺序不同。为了更清晰解释一下对排序的影响，我们可以用下图详细说明：
图中展示了4个主播的5个直播场次，作为观众，当我在T1时刻打开页面，看到的顺序是场次3在最上方，其余场次均在预告状态，按照预计开播时间从早到晚展示。当我在T2时刻打开页面，场次5在最上方，其余有三场在预告状态排在中间，场次3已经结束了所以排在最后。以此类推，直到所有直播都结束，所有场次最终的状态都会变为回放。
这里需要注意一点，如果我在T1时刻打开第一页，然后盯着页面不动，一直盯到T4时刻再下划到第二页，这时上一页的last_id，即分页偏移量很有可能因为直播状态变化而不知道飞到了什么位置，这会导致严重的错位问题，以及直播状态展示不统一的问题（第一页展示的是T1时刻的直播状态，第二页展示的是T4时刻的直播状态）。
直播系统是个单向关系链，和微博有些类似，每个观众会关注少量主播，每个主播会可能有非常多的关注者。由于有状态变化的存在，写扩散几乎无法实现。因为如果采用写扩散的方式，每次主播创建直播、直播开播、直播结束这三个事件发生时导致的场次状态变化，会扩散为非常多次的写操作，不仅操作复杂，时延上也无法接受。微博之所以可以写扩散，就是因为一篇帖子发出后，这篇帖子就不会再有任何影响排序的状态转变。在我们场景中，“预告中”与“直播中”是两个中间态，而“回放”状态才是所有直播的最终归宿，一旦进入回放，这场直播也就不会再有状态转变。因此“直播中”与“预告中”状态可以采用读扩散方式，“回放”状态采取写扩散方式。
最终的方案如下图所示：
会影响直播状态的三种事件（创建直播、开播、结束直播）全部采用监听队列异步处理。我们为每一位主播维护一个直播中+预告中状态的优先级队列。每当监听到有主播创建直播时，将直播场次加入队列中，得分为开播的时间戳的相反数（负数）。每当监听到有主播开播时，把这场直播在队列中的得分修改为开播时间（正数）。每当监听到有主播结束直播，则异步地将播放信息投递到每个观众的回放队列中。
这里有一个小技巧，前文提到，直播中状态按照开播时间从大到小排序，而预告中状态则按照开播时间从小到大排序，因此如果将预告中状态的得分全部取开播时间相反数，那排序同样就成为了从大到小。这样的转化可以保证直播中与预告中同处于一个队列排序。预告中得分全都为负数，直播中得分全都为正数，最后聚合时可以保证所有直播中全都自然排在预告中前面。
另外前文还提到的另一个问题是T1时刻拉取第一页，T4时刻拉取第二页，导致第一页和第二页直播间状态不统一。解决这个问题的办法是通过快照方式。当观众来拉取第一页Feed流时，我们依据当前时间，将全部直播中和预告中状态的场次建立一份快照，使用一个session_id标识，每次前端分页拉取时，我们直接从快照中读取即可。如果快照中读取完毕，证明该观众的直播中和预告中场次全部读完，剩下的则使用回放队列进行补充。照此一来，我们的Feed流系统，前端分页拉取的参数一共有4个：
每当碰到session_id和last_id为空，则证明用户想要读取第一页，需要重新构建快照。这里还有一个衍生问题，session_id的如何取值？如果不考虑同一个观众在多端登录的情况，其实每一位观众维护一个快照id即可，也就是直接将系统用户id设为session_id；如果考虑多端登录的情况，则session_id中必须包含每个端的信息，以避免多端快照相互影响；如果不心疼内存，也可以每次随机一个字符串作为session_id，并设置一个足够长的过期时间，让快照自然过期。
以上设计，其实系统计算量最大的时刻就是拉取第一页，构建快照的开销。目前的线上数据，对于只关注不到10个主播的观众（这也是大多数场景），拉取第一页的QPS可以达到1.5万。如果将第二页以后的请求也算进来，Feed流的综合QPS可以达到更高水平，支撑目前的用户规模已经绰绰有余。如果我们拉取第一页时只获取到前10条即可直接返回，将构建快照操作改为异步，也许QPS可以更高一些，这可能是后续的优化点。
读扩散、写扩散、读写混合，几乎所有基于时间线和关注关系的Feed流都逃不开这三种基本设计模式。具体到实际业务中，可能会有更复杂的场景，比如本文所说的状态流转影响排序，微博朋友圈场景中也会有广告接入、特别关注、热点话题等可能影响到Feed流排序的因素。这些场景就只能根据业务需求，做相对应的变通了。
转自：
信息流广告Feeds AD
深入浅出解析信息流广告|人人都是产品经理
1. 与产品功能混排在一起的原生广告。
例如：①微信在使用微信朋友圈功能，查看好友动态时，与好友动态加载一起的广告，就像朋友发的动态信息。②今日头条在使用APP功能浏览资讯时，混排在咨询信息中的广告，很像新闻信息。
同理，刚才电脑管家的信息流广告也是与产品功能混排，在你查看电脑测评状态时，推送了特斯拉广告。
2. 主动推送。
信息流又叫feed流，feed的英文含义是供给、喂送，顾名思义，信息流广告亦是如此，是主动推送广告。所以，一些垂直信息平台的被动广告，并不能算目前的信息流广告。例如58同城，产品功能是提供本地信息服务，当网民在58上搜寻信息时，平台应用会展示商家广告，这些广告信息本身就是平台功能，但不是主动推送，而是被动触发，所以不是信息流广告。
综上两点，目前营销市场上被称为信息流的广告是：用户在使用互联网产品（服务）功能时，主动推送，并与产品（服务）功能混排在一起的原生广告。一般常见于社交媒体和资讯类产品。
信息流是原生的一种.
微信订阅号Feed流APP实践
可能很多人不知道Feed流是什么，你现在用的Facebook，Twitter，微信朋友圈，微博，今日头条...内容展现形态都是Feed流，下面是一个定义：
本人是一个Feed流的拥趸者，Google砍掉了Google reader之后，我就开始用Feedly，在MacOS系统上 Feedly + Reeder 我认为是完美的结合。
微信订阅号的出现，催生了很多自媒体人，正如微信所言「再小的个体也有品牌」，对于大多数自媒体来说，他们都没有网站，微信订阅号文章的展现形态是按照订阅号为入口，查看文章要： 打开微信——订阅号——进入订阅号列表——进入文章列表——查看文章 ，流程过长，然而Feed流的产品就可以： 打开APP——进入文章列表——查看文章 ，从5步缩短成3步，而且不需要详情和返回按钮多次点击。
目标用户 ：微信订阅号用户
解决痛点 ：通过Feed流的形式结局阅读路径长，阅读不方便的问题
调研过身边的朋友，诟病目前订阅号阅读方式的不在少数，有用户，有痛点，就是产品机会。
在很长时间内没有找到抓取微信文章的办法，而且微信有反爬机制，校验IP和用户，如果要自己做服务，开发成本过高。直到看到有专门提供抓取微信文章的API接口，轮子有了，就差组装了。
为什么要做iOS而不是Andriod？
一方面，很简单的理由：iOS目前是统一的应用市场，推广方便，准入门槛低。而国内安卓市场众多，上架需要有著作权证书，时间成本过高，难推广。
另一方面，iOS找到了比较合适的（按开发工时结算）做开发的Freelancer。
然而苹果的审查机制比较严格，不认为WeRss是传统的网页的Rss工具，需要我提供授权，几经邮件的来回沟通，最终还是没能上架。
然而更痛苦的是微信就在此时，推出了Feed流功能。默认就是Feed流方式阅读。
APP夭折后，转而我想，微信的桌面版还没有开发Feed流的方式，既然微信也做了Feed流，那么证明，用户痛点一定是存在的，而且也是相当一批用户的痛点，不然微信不会增加这种功能，存在即合理。
于是我们做了桌面版本 WeRss
桌面软件的推广
国内毫无疑问百度和360稳坐两把交椅，也占据了90%+的市场份额，然而他们的政策对独立开发者很不友好，开户首次要￥8000+，CPC基本要在￥0.5的成本。
相比之下 Google Ads （原Adwords）就太人性化了，注册账号就可以投放（只要广告合法），没有开户金额限制。
先后做了两次推广：
第一阶段
第二阶段
第一阶段点击率过低，做了关键词的优化，到第二阶段整体CTR提升91%，CPC降低了65%。
整体带来了187个安装，CPA平均￥1.68，相比国内动辄十几，甚至几十软妹币的CPA，Google对独立开发者和小团队无疑是最好的选择。
那么为什么是迷失了呢？
虽然有了安装，但是用户的使用情况，并没有达到我的预期，最高每天接口的调用次数也就几十次，寥寥无几的活跃用户。但是很开心的是，我们也迎来了用户反馈的需求。
