SiCM: Secrets in Cloud Music
在我暗恋别人的时候,非常渴望做的一件事,就是通过各种渠道,尽可能多地了解对方。无论是微信还是QQ还是更早时候的人人,我都会把对方的动态和更新翻好几遍。 上大学后,我开始听歌,接触到了网易云音乐,并很快成了其死忠。它之所以吸引我,除了丰富的曲库和准确的兴趣推荐之外,最为重要的一点,就是它同时提供了社交功能。在自己喜欢的歌下面阅读其他人的评论,是一种很奇特的体验。但是,它也有一个缺点,就是在我喜欢的女孩的主页上,只能看到她的歌单与“动态”,却不能看到她的评论。虽然现在我已经告别了单身生活,但是仍然清晰地记着自己当时多么渴望拥有这样一款能够提取用户评论的平台。借着这次参加“博彦之星”竞赛的机会,我决定由此入手,去实现自己这个过去的愿望,同时为未来的有着相似渴求的人提供微小的帮助。
通过分析,我发现本项目实现的难点,在于用户提供请求的频度是不可预知的。同时,由于单次爬取数据所需时间较长,必须要考虑不同进程的异步协调问题。AWS的SQS服务完美地对应本应用场景。
- 减少开销,轻量快速。如果自行搭建资源实现队列的托管,不但会极大地增加资源和时间开销,而且保障与维护将会是极其繁琐的工作;
- 原生集成,弹性扩展。作为一个学生项目,我并不知道其面向的数据规模,因此可扩展性与弹性非常重要。其次,为了简化流程,同时减少潜在的问题,选取SQS后,我在AWS上进行开发时,可以得到原生的集成计算服务,配置简单;
- 关注数据可靠性。SQS标准队列确保每个数据均能被保存并访问,且基本满足FIFO的要求,这正是本项目的核心需求。本项目不要求严格按照顺序进行爬取,甚至不要求每个请求仅被执行一次,但是必须确保每个请求都得到执行。
根据http://www.zhihu.com/question/36081767/answer/65820705 上的启发,调用获取网易云音乐评论所需的API。考虑到用户之间的个体差异巨大,同时爬取数据较为耗时,决定选取某一歌单进行爬取。用户通常会在自己喜欢的歌下进行评论,而衡量其实际喜爱程度的一项指标,是其听歌的次数。因此,决定设定其全部时间最爱听的100首歌为爬取目标。
在前后端交互方面,由于本应用的前端全部为静态HTML页面,因此希望尽可能简化配置。在这种情况下,选用了Apache 2自带的cgi模块实现Python与HTML的数据交互,即使用HTML接受用户输入作为参数,并运行对应.py脚本。
由于本项目在爬取数据阶段耗时较长,且后台有多个异步操作,为了提高用户体验,在交互时,选取了更换结果页内容的方式。在用户完成输入发出请求后,会被重定向到结果页。等待期间,会看到等待页面,此时后台正在生成对应的页面;生成完成后,会用最终的结果页替换等待页面,实现异步交互。同时,报错页面亦通过这种方式呈现。
本项目在过程中遇到的可能的错误有以下三种:
- 用户输入不合法。在完成输入后即处理这个问题,非法请求会导致打开对应报错页面;
- 目标云音乐用户开启隐私保护。在comments.py里,这会引发KeyError异常,捕获后会返回对应报错页面;
- 遭遇网易云音乐反爬虫策略。由于本平台当前运行环境为一台免费体验的AWS EC2服务器,性能较低,并没有采用分布式、伪装地址等爬虫策略。确认遭遇反爬虫策略后,后台守护进程会自动休眠20000秒,并告知用户。