随着数据体量和代码量的增加,以前好端端的功能就成了定时炸弹,而且烧的还是无明火,不知道问题在哪,下面就列举一些bug
1,头条请求接口会出现阶段性没权限提示
- 第一阶段:偶发,排查授权接口,去授权页面重新授权,恢复使用
- 第二阶段:经常出现,但是排查授权接口,Redis存储,都没发现异常,只能手动授权,多打日志,继续观察
- 第三阶段:影响到投手的使用和技术人员
忍无可忍
- 也是照常排查官方的授权接口,没出现问题,就是一句话比较在意:
2. 查看了对应日志,正常刷新,正常存储,也没发现问题
3. 去Redis客户端查看了一下存值:
,奇怪的是几个存储的值是一样的
4. 查看刷新代码:
,逻辑没问题
5. 查看授权页面
,查看授权回调接口
,数据库记录
,都没发现啥
把能查的都查了,但还是不知道问题在哪,逻辑没问题,接口也没问题,想不通,想不通.处理到20:40发现还是搞不了,在肚子饿的情况下回家了,一边走一边在回忆这些信息.
初步判断是重新刷token导致旧token失效,但是代码全部查询了一遍,没发现第二处有地方刷新token,然后把流程在脑子里过了一遍,页面上手动授权->回调接口创建token->定时任务刷新token,只有刷新token才能刷新,再重新查看代码:
,发现这几个管家账户在Redis里面的token都是一样的,后面刷新的会把前面的token给覆盖掉,但是前面的已经存入Redis了,所以在10分钟有效期内还能使用,过了就不能用.
验证想法:
- 修改代码
分组刷新，避免覆盖刷新
- 再手动授权重新开始
观察一下午发现确实可以，手动触发定时任务也能正常使用
但是第二天又发现提示没权限，难受
- 梳理了一下流程，逻辑和方向是没错的
- 再过了一下进行修改的步骤，代码是没问题的，那应该就是手动授权姿势不对了
- 查看了一下授权页面，立马发现每个账号互相持有管家账号，如果全部勾选的话也是会出现token覆盖
- 重新手动授权，一个个授权，避免重复授权
- 观察了一周，未发现无权限问题
2,2023-08-11 字节拉取当天消耗接口没反应
第一反应是字节的token又出问题了?但是转念一想,不应该啊,查看了一下:
,定时任务配置:
,说明定时任务有在执行,但是为啥今天的没有数据呢?查看代码:
,为了提升效率用了线程池并发去处理.梳理了一下这个接口的相关业务:
- 同一个接口,但是今天会拉取昨天的消耗进行校准
- 拉取昨天会全量账号拉取,方便统计出哪些账号实际投投放,当天拉取只用有投放账号拉取提升效率
- 只有一个线程池
