拣阅一：缘由和系统设计

个人平时比较喜欢看些新闻资讯，比如科技类的huxiu, 36kr，体育新闻等，对相关的APP也有用到，今日头条做的很不错，周围很多人在用，但是在用了一段时间之后发现很多APP都有以下特点:

1. 信息多而且杂，即使我只订阅或者关注了某些类别，推送的消息首先是太多其次是不相关。太多的信息我消费不了，不相关的信息我比较反感。

2. 现在的APP号称可以进行精准和个性化的推荐，头条做的还行，但是感觉不能及时的捕捉用户的兴趣变化，推荐的结果变化也小， 惊喜度不够。

3. 聚合类的新闻资讯有很多重复性的内容，而且很多只是简单的抓取和展现，对阅读的方式和体验都没有太大改善。

以上大概是用过之后感觉有些不便的地方，之前做过一段时间的推荐和文本处理相关的事情，加上自己有些想法，就想实现一个简单的系统，拿自己做个试验试试，也好验证下自己的想法，针对以上问题，个人的想法是1. 每天给用户展现一定数量的有价值的新闻，即限制推送给用户新闻的数量，相关性方面需要针对用户的特征建模，预期效果不太明显，只能通过一些策略来控制，比如最热和相关结合，某个事件或者某个类别展现一条新闻等策略实现。2. 针对用户的行为及时更新用户的特征权重，及让变化更实时一点。3. 很多人看文章只是看文章的大意，很少通读全文的，如果能对文章进行摘要，对APP类的应该会比较好，但是现在对中文貌似没有好的摘要方法，只能不断的进行尝试改进，我会用之前文章介绍的摘要算法进行实验，结合中文的词法和语义做些尝试。

以上纯粹是个人的观点和看法，肯定有不妥的地方，这方面有想法的可以在一起交流下。

目前开发工作已经进行了一些，之前一直用java来做web相关的服务和设计，奈何一般的云服务器跑java的话费用较高，故采用了python来进行相关的开发工作。系统的简单设计如下:

系统主要分为OnLine Service, OffLine Service, 其中OnLine 部分主要进行以下操作:

    a).  Fetcher利用UA和PA来获取推荐展示的新闻数据，首先会向redis请求相关数据计算，然后到MySql获取数据，目前假定MySql可以满足一定量的并发请求，以后可以考虑按照数据类型在MySql前面再加一层缓存。 

    b). Updater主要是根据用户行为来更新缓存中的UA权重，这样下次就可以根据用户的最新行为进行推荐展示。

      OffLine部分主要负责的是线下逻辑的处理，主要包括对抓取数据的清洗、特征提取、摘要、入库等操作，为了解耦，利用MQ来存储抓取的数据。

    目前采用的方式是tornado 框架来提供web服务，redis作为缓存存储数据，mysql作为底层数据存储， rabbitmq 来作为消息队列，jieba分词器来进行中文分词，redis + mysql 目前已经实现，web主要剩下页面的设计和实现，特征提取和摘要正在进行，由于事情比较多，可能最后实现的跟文章中说的会有很大区别，接下来会讲部分想法的实现过程和效果， 具体取决于进度和工作了，如果有兴趣可以一起交流。