node mysql retry_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等机制可以处理调用嵌套问题。但在业务上，还是需要下一些功夫做好流程设计。