# 总结与展望

# 数据库

我在一开始写数据库的 SQL 的时候, 很蠢地添加了 update 数据时自动更新时间. 导致系统总是会出现一些很奇妙的 bug.

系统实现到后期的时候, 我发现这张表并不完整, 有一些字段没有被加入, 比如用户的粉丝数量, 关注者的数量, 评论回复数量等, 而不是单纯的用户在不同类别下用户行为的数量.

这张表虽然被升级过, 能过记录各种不同类型的用户行为, 但是在查询这张表的时候, 我发现没办法分页查询用户被动动态 (被关注, 被评论, 被回复等), 这让用户中心的体验变差了很多, 弱化了用户关联.

如果时间能够重来, 我绝对不会使用基于用户的协同过滤算法作为主推荐手段. 相比从新闻角度进行推荐, 相似用户推荐带来了更大的计算需求, 此外系统需要保证数据库里有足够的活跃用户. 这些问题在今天看来就很操蛋, 隔壁的新闻排分推荐看着就挺好.

当前系统的推荐粒度只到了 "类别" 的范畴. 而我的一个理想的操作, 对每篇新闻内容进行分词操作, 用某种手段提取这些分词中关键的部分, 并将用一棵词树来记录. 如此, 判断两篇新闻的相似度就可以从关键词出发, 利用词树 (计算结点之间的距离) 来得出相似值.

考虑一种情况, 用户登录到系统, 系统给出推荐, 但是用户没有浏览过推荐内容, 随后用户登出并再次登录, 系统给出推荐. 理论上, 一个成熟的推荐系统不会给出两份几乎一样的推荐, 因为它在提供推荐时对历史推荐内容进行了过滤, 这是我当前系统中实现了一半的功能.

一种简单的操作是, 也是我实现了一半的操作, 再起一个数据表, 每次系统给出推荐内容的时候, 数据表将记录为每一个用户推荐过的所有推荐内容. 那日久天长数据量太大怎么办? 可以在记录推荐内容的同时, 删除 72 小时前的数据, 因为是推荐的是新闻, 本身是对时间敏感的内容, 不需要记录地非常准确.

前面提到过, 系统一共有 5 种不同的推荐情况, 当前系统面对这 5 种情况时, 虽然有着不同的推荐方式, 但是底层的数据库或是分页信息并没有对这些推荐方式作出相应的适配, 存在某些推荐场景使用了不合适的底层功能, 需要改进.

在当前系统中, 用户请求的大部分功能都需要先对用户做身份验证, 然后在用户完成操作后, 及时更新相关的统计数据表以及行为记录表. 如果有机会, 我希望能够使用拦截器来完成这些工作.

原来计划使用一个数据库全局查询工具, 先对数据库内容进行分词, 然后工具会为每个词创建一个链表, 标明哪些内容带有这个词. 使用这个工具后, 可以让搜索功能更加完整丰富. 同时还可以添加筛选条件, 完成更细的搜索功能.

其他的事情, 就是希望能对接口进行重新设计. 部分功能, 比如用户对文章的点赞与点踩, 新闻编辑模块, 用户中心显示用户的被动动态 (被关注, 被评论, 被回复等) 等功能并没有被实现. 另外, 我还想添加向用户推荐用户的功能.

一开始设计前端的时候使用比较激进的设计, 页面的组件设计不是很合理. 如果能够重来, 我希望这部分设计能够按页面区分, 减少组件层次, 保证组件独立, 尽量不考虑组件复用. 事实证明, 能力有限的情况下使用组件复用基本是个笑话, 还是比较适合写一次性代码, 保证方便维护即可.

爬虫运行过程中总是会有一些非常奇妙的 BUG, 导致数据库中的数据总是不一致, 例如用户记录数量与用户统计数据的记录数量总是对不上. 这些 BUG 我尝试寻找过, 但是都没有结果.

一个是日志, 当前的日志量太大, 最大的可以到一百多兆, 应该想办法处理一下.

另一个问题是应该将系统爬取数据与填入数据库两部分分离开来. 开发过程中, 总是要反复清空数据库内的数据, 然后重新爬取, 这样的时间成本过高. 如果能够将要存入 MySQL 的数据保存在一个单独的文件中, 并编写自动程序导入数据, 用户体验就会好很多, 同时也方便多设备数据同步.

再就是当前爬虫不允许中途停下, 因为这可能会导致数据记录不一致, 应该优化请求提交的过程.

最后的最后, 我没能找到一个浏览器能够在后台稳定爬取数据的方法, 现在的爬虫工作的时候总是要占着整台机子.

爬虫中只抽取了数据库相关的配置信息. 其实还有很多配置内容可以抽取出来, 为了系统的稳定性, 我没有这么操作, 有机会再改吧.

在过去实现系统的几个月时间里, 我面对过很多问题, 很多内容我都没有找到自己想要的答案, 所以写下这些东西, 即是对过去内容的总结, 也是想帮组其他同样陷于毕设中的同学. 最后, 很高兴你能看到这, 如果上面的内容能够解答你的一些疑惑, 那就再好不过了.

如果觉得喜欢这个项目, 可以帮忙到仓库中点个 Star 哦 😃 .