【项目跟进】KnowledgeManager--3--公众号接口的问题与解决

1.公众号接口的问题

1. 最大的问题就是频率限制了。新的一天早上，将每次翻页的频率设置成5秒，大概爬到1000条不到的时候，就会出现freq_control,错误码200013。
2. 参数问题。appmsg这个接口的参数count为5，表示一次翻页有五条消息，但是每次得到的文章列表有20几条，有的时候还是5条。
3. 更新问题。同一个公众号距上次爬取，文章有更新。

2.解决方案

1. 频率控制。我有一个个人订阅号号和服务号，订阅号频率控制等待的时间比较久，一般在30-60min，服务号的频率控制有的时候只要5min。我也不知道tx那边appmsg接口后台怎么处理的，可能服务号会好一些。实际自动化操作的时候可以在频率控制后设置等待回复时间，或者直接切换账号继续作业。
2. 频率控制后的恢复作业。中断设置flag标志，记录上次的msg总数和中断时的begin。新msg总数对新begin也会有影响，只需要知道在新总数下的begin‘，由于请求参数的规律性，直接给出计算公式：m=app_msg_cnt'-app_msg_cnt;begin'=m+begin-(m+begin)%5。新begin的前(m+begin)%5条是数据库已有的，在begin获取的数据中直接数据库去重就好。
3. 参数问题。研究了下appmsg返回的列表的数量与count不符因为返回列表有两个idcount是以appmsgid对应，我们看的数量以aid对应。
4. 更新问题。判度m（m=app_msg_cnt'-app_msg_cn）是否大于0，大于0则读begin：0 ~m-m%5的数据，并且在count为m-m%5的list做一个数据库去重。 

上图是针对中断、更新的逻辑流程图（这个不行，新思路见下）

---

20190812_23_23:想了下，上面的逻辑有问题。爬虫中断可能发生在更新或者下载全部的时侯。假设更新之前文章总数为app_msg_cnt，下载全部时，中断在了begin（begin<app_msg_cnt）。如果下次打开后上次剩余的部分没有爬完就更新，那么app-msg_cnt值会更新，影响下次打开后的begin值。而且加入更新时也发生了freq_control产生中断，那么上次中断的部分可能会遗漏，结果就是，虽然更新了，但是实际上中间或最后有可能漏几个文章。

想了下解决方案就是：为每个公众号设置一个flag_break标志位保存上次爬取时是否有终端，再设置break_begin和break_end索引，记录中断的地方，每次爬虫时，首先需要爬取上次遗漏的部分，使flag_break为假，然后再更新app_msg_cnt进一步更新文章。如果上述过程一旦产生爬取失败，则标志位为真，下次从遗留部分爬取（可以加个自动化，每天固定时间开启）。

新的流程图如下：

 

---

20190813_10_00:想了下，昨晚的流程逻辑还是有点小问题，问题出在恢复上次中断任务。使用的break_begin和break_end是根据中断时的app_msg_cnt得到的，而当恢复中断时，可能公众号发送了新的消息，有了新的app_msg_cnt,在这种条件下，本来存储的break_begin和break_end将不再适用，需要根据新的app_msg_cnt重新计算。计算公式为break_begin/end+m-m%5（m=app_msg_cnt'-app_msg_cn）

修改流程图如下：

---

有啥问题欢迎关注公众号直接后台问我，博客我不常上，但是公众号有消息推送，我会第一时间回复的。