nodejs基于async waterfall/retry的出错重试流程设计

问题来源

最近搞了一个线上服务，涉及到网络请求、图片处理、文件读写等流程，为了解决函数嵌套，我用了async的waterfall方法。结果上线后发现非常不稳定，估计有至少1/4的访问都没有成功。至此，方才明白稳定可靠服务的重要性。
仔细排查了一下日志，发现有下面几个问题
- 程序中的error一定要处理
- 每个过程要考虑失败的情形

第一条程序中的error特别重要，多数情况下是因为忽略了对异常的处理，导致服务不可用。
第二条是对程序可靠性的保证，一个简单粗暴的方法是，只要流程出错，就重试。

Solution

我们知道，使用waterfall可以保证一序列函数执行的顺序，如果函数执行失败了，会直接中断处理流程。比较可靠的办法是，重试流程。
这就用到了async中的retry方法。

var async = require('async');

async.waterfall[
    function(callback) {
        async.retry({times:5, interval:1000}, function(cb) {
            do_task();
            var some_err = '';
            var some_result = '';
            cb(some_err, some_result);
        }, function(err, result) {
            callback(err, result);
        });
    },
    function(param, callback) {
        //类似流程......
    },
], function(err, result) {
});

上面的代码中，最外层的是waterfall，顺序执行流程。在每个函数中，可以再加上retry函数，其用法如下：

retry(opts, task, callback)

其中
opts是一个对象，表示重试相关参数，times字段表示重试次数，interval参数表示重试间隔，如果opts只放一个整数，则表示times，interval默认为0。
task表示要执行的任务，该任务带有一个回调函数，在执行完成后必须调用，例如上面示例中的cb函数。
callback是retry的回调函数，即retry完成后，对结果进行后续处理。

async中的回调函数参数更像是一种通知机制，就是说在函数执行完成后，传参到下一流程。例如，在retry过程中的cb，还有waterfall中的callback。
在上面的例子中，callback是外层流程waterfall的回调函数，每个函数执行完成后，通过它将参数传递给后续流程。而cb就是retry的回调函数，每次任务执行完成后，由它传参，并决定是否重试。

这样，就能实现一个完整的流程控制，并且在每个过程当中，进行出错重试设计。当然，把retry拿到外层，对waterfall整个进行重试设计，也是可行的。只是需要处理好业务流程。

nodejs的异步特性在面对复杂业务时，有一些劣势。尽管有async、Promise等机制可以处理调用嵌套问题。但在业务上，还是需要下一些功夫做好流程设计。

参考

https://github.com/caolan/async

文档

async_demo

Async.retry executes immediately before waiting for interval