2016-3-25突然推送大量消息的问题及查找 -- Sangit

　　起因：2016年3月25日 18:30 左右，突然接到客户投诉，说APP收到大量的任务推送消息，而且点击进去都是一些过期任务，我们将对此展开追踪，查找问题原因。

　　过程：

　　　　1、当时的第一反应是先查看redis的消息队列，发现redis队列里还仅存着一条数据

　　　　2、然后马上中断错误文件，当再查看消息队列时，仅剩下的一条消息也没了

　　　　3、之前反馈消息说只有iOS的收到，当时在想，会不会发送至iOS的function有误

　　　　4、为了确定是否iOS的发送function有问题，登录腾讯信鸽进入消息统计那里查看发送记录，然而发现Android端的也有发送，只是没有Android的用户反馈这问题

　　　　5、而且还发现信鸽列表每条消息所发送的用户数量是不一致的，这判断出发送时对用户的条件判断是生效的

　　　　6、然后代码对比，对比自己的代码与自己修改前的那一个版本看是否代码存在问题

　　　　7、对比发现新增加的代码基本不存在对发送主流程有影响的地方

　　　　8、在这时候认真的总结了一下消息发送流程，如下：

　　　　　　管理后台审核通过任务列表——点击推送按钮——填写要发送的标题与文字——把发送的文字添加到message表，把message的id写入到task表——把task的id存进redis消息队列

　　　　　　crontab定时器——每隔五分钟运行一遍message文件

　　　　　　message文件——检测redis消息队列是否有数据——循环发送——删除消息

　　　　9、这时候把自己觉得有出现可能都想了出来

　　　　　　1）代码是否存在问题

　　　　　　2）是否redis的key是否在其他地方有用到

　　　　　　3）redis是否会自动回滚，或者某些操作导致redis回滚

　　　　10、首先把查看代码问题，代码根据流程一步一步往上走：发送后删除消息，没有问题（因为根据过程的第1步redis队列的内容从有到无，证明已经删除，为了安全起见，重新走了一遍发送流程，发现没有问题）；获取消息队列，循环没问题；管理后台消息写入，也没有问题

　　　　11、搜索redis队列的key是否在别的地方用到，管理后台搜索后发现只在当前页面用到，没有问题，在前台的接口文件搜索后发现不存在，没有问题，说明没有其他地方调用这个key；然后车看写入消息的function是否在其他页面用到，搜索前后台还是只有当前页面用到，也没有问题

　　　　12、那么最后好像只剩redis的问题了，对于redis这块由于不是很熟悉，只能通过百度来查找，发现还没有什么操作或者自动会让redis的某个可以回滚，然后在这步一直卡住，因为之前的都没有问题，好像就到了这里才有问题

　　　　13、对于这块的不熟悉，百度也没有结构，于是就向熟悉的同事问了一遍，他们根据流程跑了一遍发现也没什么问题，因为他们熟悉redis，觉得redis自动回滚的概率性太小了，觉得会不会是其他的问题导致消息队列存在数据

　　　　14、先是询问了一遍审核任务的同事，看是否有人一直在发送推送消息，然后得到的答复是一般都是审核通过就点击推送的，我们查了其中的任务，三月初的任务都有推送，这又卡住了

　　　　15、然后我们的大神说了一句，会不会因为上一个版本存在问题导致消息一直存在队列中，没有发送出去，之后新版本上线刚好修复了，从而把所有存在队列中的消息一起发送出去了

　　　　16、说到这个然我突然想起我在修改完测试时，程序在以前的代码块出现了错误，导致程序运行错误，当时我还在想为什么代码到我这就不行了

　　　　17、把代码恢复到我修改前的那一个版本，进行测试，发现真的是那个代码有错误

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

　　总结：通过这次的问题查找发现了自己存在很多问题：

　　　　　　1、当时的第一反应应该是马上中断程序，停止发送，而不应该是先去查看消息队列，自己在处理突发事件时缺乏经理，乱了阵脚

　　　　　　2、在发现出现的问题不属于自己版本时并没有留心或者向修改上一版本的同事求证，只是通过自己的修改完成，导致问题发生

　　　　　　3、发现自己在寻找问题的时候会陷入牛角尖，并没有及时的跳出来，想想其他的方面，只是在思考自己的开始所觉得的几个问题

　　　　　　4、自己找问题时不会怀疑他人把东西交到手的是否有问题，没有去质疑别人

　　　　这都是需要我努力改进。