Redis助力集群自动任务跑得更快更稳，效率提升真明显

（根据“某电商平台技术团队分享”整理）

我们团队之前一直用一个挺老的任务调度系统来处理各种后台任务，比如每天凌晨给用户发促销短信、统计前一天的销售报表、清理一些过期的临时数据什么的，这些任务看起来不起眼，但数量一多，特别是赶上大促期间，就成了大问题，最让人头疼的就是两个事儿：一个是慢，像双十一之后那个销售报表，有时候能跑到天亮还没完，老板等着看数据，我们心里急得冒火；另一个是不稳，经常有任务莫名其妙卡住了，或者同一时间好几个服务器节点都在跑同一个任务，导致数据算重了,甚至把数据库都搞挂了。

后来我们琢磨着怎么改进，听同行介绍了Redis，说这东西不只是个缓存，还能当轻量级的消息队列和数据库用，特别适合我们这种场景，我们就抱着试试看的心态，用Redis给我们的集群任务系统动了个“小手术”,没想到效果出奇的好。

第一招，用Redis当“任务公告栏”，解决抢活干和丢活的问题。

以前的任务调度是“推”的模式，中心调度器硬把任务指派给某个工作节点，这个节点要是当时CPU正忙或者网络抽风，任务就可能卡死在那儿，现在我们换成了“拉”的模式，我们把所有需要执行的任务，像一个个小纸条一样，用LPUSH命令放进Redis的一个List列表里，这个List就相当于一个“任务公告栏”。

各个工作节点没事干的时候，就主动去用RPOP命令从这个列表末尾“拉”一个任务下来执行，这样做的好处太明显了：谁手头空闲谁就去领活，自动实现了负载均衡，再也不会出现忙的忙死、闲的闲死的情况，就算某个工作节点突然宕机了，它还没来得及处理的那个任务纸条还好端端地留在Redis的List里，过一会儿其他健康的节点就会把它取走执行，任务根本不会丢，这就解决了“不稳”的大问题。

第二招，用Redis当“任务状态牌”，防止重复劳动。

我们最怕的就是同一个任务被多个节点同时执行，比如给用户发优惠券，要是发重了，公司损失就大了，为了解决这个，我们用Redis的Set集合给每个任务打上了“正在执行”的标签。

具体是这样：当一个工作节点从“任务公告栏”成功拿到一个任务时，它不急着开始干活，而是先检查这个任务的唯一ID在不在一个叫“正在执行任务集”的Set里，如果不在，它就用SADD命令把自己的ID加进去，相当于挂上个“此任务已有人处理，闲人免进”的牌子，然后再开始干活，等任务顺利完成，它再用SREM命令把自己的ID从这个Set里移除,牌子摘掉。

如果另一个节点手快，也拿到了同一个任务（虽然概率低，但以前真发生过），它一检查Set，发现牌子已经挂上了，就知道有兄弟已经在干了，它就会乖乖地把任务纸条重新放回List里，然后自己去干别的，这一招彻底杜绝了重复执行,让我们心里踏实多了。

第三招，用Redis当“任务进度本”，执行到哪儿了一目了然。

有些任务特别耗时，比如全量更新商品索引，可能得跑上好几分钟甚至更久，以前，任务一提交就跟石沉大海一样，我们只能干等着，或者不停地查日志,根本不知道进度如何。

现在我们在每个任务里设置几个关键节点，每完成一个节点，工作节点就用HSET命令，以任务ID为Key，在Redis的一个Hash结构里更新一下进度状态，progress:任务ID”这个Hash里，写进一个字段“step”: “正在处理第5000个商品”，这样，我们开发或运维的同学，随时都可以通过Redis的桌面工具或者简单敲条命令，直观地看到所有长任务的实时进度，就跟看下载进度条一样，一旦哪个任务卡在某个节点长时间不动，我们就能马上发现并介入处理,再也不用盲目等待了。

效果怎么样？

用了Redis这套新机制之后，变化是实实在在的，最直观的就是快，任务队列再也没有堵塞了，资源利用率高了，像那个曾经要跑通宵的报表任务，现在一两个小时就能搞定，稳就更不用说了，快一年了，再没出现过任务丢失或者重复执行的尴尬事，运维的同学也轻松了,查问题不再是两眼一抹黑。

所以说，Redis对我们来说，真不只是个提升性能的缓存工具，它用非常简单的数据结构，像积木一样，帮我们搭起了一个又灵活又可靠的后台任务系统，让我们的集群自动任务跑得又快又稳，效率提升非常明显。 结束）