背景描述

近几年redis应用的越来越多,正好现在手上的一个项目就用到了。简化一下需求,就是要实现一个worker程序,该程序所有的工作就是去redis中的一个任务链表tasklist里面去取任务,执行一些处理操作。

分工明确化

从始至终我们持有的一个观点就是,这个worker的功能要极度简化,就是去从tasklist中取任务,执行操作,并根据任务执行成功与否进行相关的结果记录。至于这个tasklist怎么来的,里面的任务是由谁来插入,worker一概不管。这样的话,有几个好处:

  • worker的角色明确,目标清晰。直接的好处就是代码容易编写。
  • 设计思想比较通用
  • tasklist的插入在不同的场景下有不同的方式,最常见的是根据某个不断增长的log中取任务,插入任务。而这个工作很灵活,通过脚本语言更方便实现。

关于重试

worker从tasklist中领取到一个任务来后,就开始执行相关的操作。如果一切顺利,就万事大吉。但在软件设计中,考虑异常情况几乎已经是广大码农们本能的反应了。不是我们天生心思缜密,而是这些都是通过一些惨痛的教训得来的。关于这个异常处理,在这里多说两句,讲一个亲身经历的例子:

我在上一家公司工作时,工作内容主要是版本发布。每天有几十个分布在全国各地的程序猿要把它们的工作成果–代码,合入到我这里来,我给编译一个版本,自己进行基本的验证,如果有问题,则解决问题或者回退,如果没有问题则版本迭代向前,并把这个版本发布出来给专职的测试人员进行进一步测试。这个工作是枯燥无味的,因此在那段时间就琢磨着怎么把编译、发布版本用脚本来完成。随手翻了几页shell脚本的书,于是我就堆砌了一堆命令行。其中有一个操作是这样的,执行编译后,cd到一个release目录,再用ftp上传到另一台发布版本的机器上。问题在于,以前每次都是手动操作,所以能确保release目录下有结果(如果没结果就是编译、打包错误了,早就去联系人解决了),而事实是当编译、打包失败时,这个release目录根本就不会生成。因此,在脚本执行cd时会出错,但是出错了由于我没有进行相关的处理,脚本并不会退出,而是在当前工作目录,继续欢快的执行ftp上传。于是终于有一次(事实是就是第二天),我把当前工作目录下的所有的源文件给当做版本发布出去了。结果很惨烈,一堆测试的兄弟们电话过来责问,领导也把我一顿批评。这就是想当然的认为cd不会发生错误的结果。

同样,在这个tasklist设计中,如果worker执行当前任务失败后,该怎么处理?很自然的想到了重试,给每个任务三次重试的机会。我一拍脑袋,把执行失败的任务放入到一个失败者队列,当worker遍历完tasklist队列后,则再把失败者队列的任务全部重新插入到tasklist里面。worker继续执行遍历操作,这样来三次为止。想到这一点,我还是挺沾沾自喜的,因为通过自豪的使用redis的RPOPLPUSH操作,是如此容易的将一个队列的任务全部插到另一个队列里面。而且这样,worker的核心处理过程,仍然是在处理tasklist链表,不用再去处理失败者链表。

这么想着,也这么干着,撸起袖子就把代码写了。拿到公网测试,是要写一个crontab脚本,该脚本每分钟执行一次,确保系统中有五个worker进程在劳动。在测试的一刹那,我想到出问题了。当把执行失败的任务放入到失败者队列,并在tasklist队列遍历完后,再把失败者队列插入到tasklist里面,每一次重试过程都这么重复,直到重试三次仍然失败后,worker进程退出。而此时这些失败的任务仍然是在失败者队列里面。当下一个worker进程继续来扫完tasklist后,又会再次对失败者队列执行相同的操作。

我们的目标是给失败的任务三次重新来过的机会,而不是无数次的复活再死去

之所以会出现这样的问题,在于,起初并没有想到我们的worker会被用一种什么样的方式来调用。对于一个worker进程而言,确实能保证只给予失败者三次重试的机会,因为让你执行三次后,我完成任务后就主动身亡了,你当然不会再继续复活了。可是,不管你进程什么时候死去,怎样死去,redis都在那里,每一个worker进程都会去处理同样的tasklist队列和失败者队列。同样的一个任务,如果它就是没救了该死了,第一个worker进程让它复活三次后又让它死去,第二个进程又让它复活三次,再让它死去。而我们每分钟都要确保系统中同时运行着五个worker进程。

想了想怎么解决这个问题。我又一拍脑袋,跟同事说,我们再搞一个永久死亡队列,一个任务死了三次后就放到这个永久死亡队列里面,以后再也不管它了。同事汗了一下,一拍脑袋说,在任务执行失败后,就把任务继续放到tasklist队列里面,而不是放到失败者队列,执行三次失败后,再放入到失败者队列,这个失败者队列就是永久死亡队列。里面的任务不会再被执行。

我愣了半天,这么简单啊,我怎么没想到。

联想

这个例子拿医生救人来类比最合适了。假设最开始一个医院只有一个医生,而病人很多,排着队等着抢救。他医术高超,可总有病入膏肓的病人他无能为力。这个时候,他把这些奄奄一息的人放到另外一个屋子里,因为只有他一个医生,他要去继续抢救其他更有希望生还的人。他抢救完了所有人后,他在来到那个屋子抢救那些基本没救的可怜的人。把那些人再弄到手术室里排着队,一个一个抢救,直到三遍以后,如果仍然有人治愈不了,他也无力回天了。

后来,医院规模扩大了,现在可以有五个医生同时看病了。如果还是按照以前的制度,每个医生碰到无法救治的病人,就把他们放到另一个队伍里, 直到第一个队伍的病人看完了之后,再把第二个队伍的没有治愈的病人放到第一个队伍里面,来把这个队伍处理三遍。如果医生们一辈子只上一天班,其实也没多大问题。可是,每天都有新的病人进来,无论是出于职业道德还是相关规定,医生们每天都要去处理正常的队列和无法治愈的队列。这样那些奄奄一息的人们每天都会被五个医生轮流看很多遍。

正确的做法是,用一个本子记录下来每个治愈失败的病人重复治愈了多少次,如果这个病人此次治愈无效,则让他回到队尾继续排队,给他的重试次数加一,每个医生在治疗每个病人之前,都会先查看这个本子,看这个病人的重试记录。到了三次,则宣布救治无效。关键在于,这个本子是所有的医生都可以看到的,有据可查,而不是都只在心里记下自己给病人重复治疗了多少次。
通过这个例子可以看到啊,好的设计之所以好,很可能是因为它简单明了。而如何要达到简单明了,则是功力所在了。