前言
LeanCloud可以统计Hexo文章的阅读次数, 但是有它的缺陷。
当你的文章数目逐渐变多的时候, 使用hexo d
时, 经常会出现 Too many requests的错误。
原因是, 使用免费开发版Leancloud无法短时间内接受太多的请求, 所以会导致429错误。
官方解释
信息 - Too many requests.
含义 - 超过应用的流控限制, 即超过每个应用同一时刻最多可使用的工作线程数, 或者说同一时刻最多可以同时处理的数据请求。通过 控制台 > 存储 > API 统计 > API 性能 > 总览 可以查看应用产生的请求统计数据, 如平均工作线程、平均响应时间等。使用 LeanCloud 商用版或企业版 的用户, 如有需要, 可以联系我们来调整工作线程数。
原因
查看源代码, node_modules\hexo-leancloud-counter-security\index.js
, 发现每次进行hexo d
的时候, 他对每个博文的title和url, 向leancloud发送一次查询请求, 如果发现leancloud那边儿没有该条记录的话, 那么再发送一条插入请求。
原逻辑如下:
1 | _.forEach(urls, function (x) { |
就是说, 每一次hexo d
的时候最少的查询次数等于你的博文个数。如果你的leancloud的应用的处理能力不够强大的时候, 对于这种高强度的请求, 当然会出现Too Many Requests的错误代码。
我们要做的就是较少不必要的请求咯。
本地记录一个title和url的json数组, 每次查询这个数组, 看看哪些是真正的需要查询的, 然后再去查询leancloud。其实可以这样理解, 这个本地的数组存储就是leancloud的远程数据库表。
因为筛除了一些记录, 所以每次hexo d时的请求数量仅仅是相比上一次hexo d时候的增量。
修改代码
修改node_modules\hexo-leancloud-counter-security\index.js
这个文件, 修改处代码均有注释, 往下翻就可以看到了
展开代码
1 | ; |
修改完后, 还需要打开博客配置文件_config.yml
找到skip_render:
这一项,然后加上leancloud_memo.json
。
1 | skip_render: |