药店相符宝2016年3月25日突然推的问题,并找到了很多的新闻 - Sangit

  原因:在18:30 2016年3月25左右,突然接到客户的投诉,他说,APP收到了大量的任务推消息,点击进去是一些过期的任务,我们将陆续推出跟踪,找到问题的原因。

  处理:

  如图1所示,当第一反应是看redis的消息队列,该队列还发现redis的唯一剩下的一条数据

  2,然后立即中断了错误的文件,当再查看消息队列,只留下一个消息也不见了

  3,只有iOS的收到的反馈,就在想,不会发出错误的功能到iOS之前新闻

  如图4所示,为了确定是否存在这样的问题的iOS传输功能,登录腾讯鸽传入消息发送统计上看到的记录,但是,发现的Android也已经发送端,但是没有的Android用户反馈问题

  5,而且还发现信鸽列出所发送的每个消息不一致,则确定用户的数量,用户的发送条件的判断是有效

  6,那么代码比较,比较的是用自己的代码的代码更改以前的版本,看看是否有问题

  7,用于发现新添加的对比度基本上不存在本地发送主流有影响的代码

  如图8所示,在这个时候认真总结了消息发送处理,具体如下:

  管理后台审批任务列表 - 点击按钮 - 填写标题和文字发送 - 添加文本由台发送的消息,该消息被写入任务表ID - 任务存款的ID为Redis的消息队列

  crontab的计时器 - 每五分钟再次运行消息文件

  消息文件 - 检测是否消息队列redis的数据 - 传输周期 - 删除消息

  9,这个时候似乎有感觉,他们可能会想出来的

  1)是否有问题的代码

  2)是否Redis的关键无论是在其他地方有用

  3个)的Redis会自动回滚或回滚一些操作导致的Redis

   如图10所示,第一至看代码问题,按照代码的进程通过步骤往上步骤:发送之后删除消息,也没有问题(因为过程redis的的第一步骤中的内容从那里排队,以证明已被删除,出于安全原因,走了一遍又发送过程中,没有发现问题); 获取消息队列中,周期是没有问题; 管理后台写邮件,没有问题

   11,键搜索Redis的队列是在其他地方使用,只有在本使用的管理后台搜索网页发现,没有任何问题,搜索后发现前台界面文件不存在,是没有问题的,有没有其他说明调用这个地方的关键; 然后写邮件功能的车,看看是否前后站只搜索当前页面或使用,没有问题之后使用其他页面

  12,那么最后一个问题似乎只的Redis,Redis的这一点,因为它是不是很熟悉,只能通过百度找到发现有很少或自动操作将回滚的Redis的,那么这一步已经被卡住了,因为有没有问题之前,似乎这里有一个问题

  13,因为这是不熟悉的百度没有结构的,所以他要重新熟悉的同事,他们跑了一遍根据过程中发现没有问题,因为他们熟悉的Redis,即Redis的概率太小了自动回滚,而将不会导致数据消息队列的存在其它问题

  14,首先要求重新审核任务的同事,看看是否有人已经发送推送消息,那么答案通常是通过点击推,这是我们检查任务审查,该任务已被推月上旬,这反过来又卡住

  15,然后我们伟大的上帝说了些什么,也不会因为一个版本会导致消息已在队列中的问题,它不发出的线刚修好,因此,所有发送在一起那么新版本的存在在队列中出现有消息

  16,说到这个,然后我突然想起我当你修改发生在代码的前一个块的测试程序错误,导致运行错误,我仍然不知道为什么我不会做的代码

  17,一个版本的代码恢复到之前,我修改,测试,我们发现该代码是一个真正的错误

  18,终于找到了原因╮(╯▽╰)╭

  总结:通过这个问题,发现自己找到了很多问题:

  1,当第一个反应,应立即中断程序,停止发送,而不应该是去看一个消息队列,他们缺乏管理人员在处理突发事件,趁乱

  2,当发现问题没注意是不是他自己的版本或确认给同事的修改后的版本,但通过自己的修改完成后,产生的问题

  3,发现自己在看的时候会陷入一个死胡同的问题,并没有跳出来,想想其他方面,只是想着正在开始自己的几个问题

  4,其他人怀疑他会不会把事情交给手,如果有发现问题,而不是质疑别人的问题

  这是所有我需要努力提高。

未经允许不得转载: 演示站 » 药店相符宝2016年3月25日突然推的问题,并找到了很多的新闻 - Sangit

赞 ()

相关推荐

评论