基于Redis实现分布式消息队列（2）

最新推荐文章于 2024-08-07 09:00:00 发布

A心无旁骛

最新推荐文章于 2024-08-07 09:00:00 发布

阅读量383

点赞数

分类专栏： php 文章标签： redis

php 专栏收录该内容

40 篇文章 0 订阅

订阅专栏

1、消息队列需提供哪些功能？

在功能设计上，我崇尚奥卡姆剃刀法则。
对于消息队列，只需要两个方法：生产和消费。
具体的业务场景是任务队列，代码设计如下：

public abstract class TaskQueue{
    private final String name ;
    public String getName(){return this.name;}

    public abstract void addTask(Serializable taskId);
    public abstract Serializable popTask();
}
 
 1
2
3
4
5
6
7
 
 1
2
3
4
5
6
7

同时支持多个队列，每个队列都应该有个名字。final确保TaskQueue是线程安全的。TaskQueue的实现类也应该确保线程安全。

addTask向队列中添加一个任务。队列中仅保存任务的id，不存储任务的业务数据。

popTask从队列中取出一个任务来执行。
这种设计不是特别友好，因为她需要调用者自行保证任务执行成功，如果执行失败，自行确保重新把任务放回队列。无论如何，这种机制是可以工作的。想想奥卡姆剃刀法则，我们先按照这个设计实现出来看看。
如果调用者把业务数据存在数据库中，业务数据中包含“状态“列，标识任务是否被执行，调用者需要自行管理这个状态，并控制事务。

popTask采用阻塞方式，还是非阻塞方式呢？
如果采用阻塞方式，队列中没任务的时候，客户端不会断开连接，只是等。
一般情况下，客户端会有多个worker抢着干活儿，几条狼一起等一个肉包子，画面太美。连接是重要资源，如果一直没活儿干，先放回池里，也不错。
先采用非阻塞的方式吧，如果队列是空的，popTask返回null，立即返回。

2、后续可能提供的功能

2.1、引入Task生命周期概念

应用场景不同，需求也不同。
在严格的应用场景中，需要确保每个Task执行“成功“了。
对于上面提到的popTask后不管的“模式“，这是另外一种“运行模式“，两种模式可以并行存在。

在这种新模式下，Task状态有3种：新创建（new，刚调用addTask加到队列中）、正在执行（in－process，调用popTask后，调用finish前）、完成（done，执行OK了，调用finishTask后）。
调整后的代码如下：

public abstract class TaskQueue{

    private final String name ;
    public String getName(){return this.name;}

    public abstract int getMode();

    public abstract void addTask(Serializable taskId);
    public abstract Serializable popTask();
    public abstract void finishTask(Serializable taskId);
}
 
 1
2
3
4
5
6
7
8
9
10
11
 
 1
2
3
4
5
6
7
8
9
10
11

2.2、增加批量取出任务的功能

popTask()一次取出一个任务，太磨叽了。
好比我们要买5瓶水，开车去超市买，每去一次买1瓶，有点儿啥。
我们需要一个一次取多个任务的方法。

public abstract class TaskQueue{
    ... ...
    public abstract Serializable[] popTasks(long cnt);
}
 
 1
2
3
4
 
 1
2
3
4

2.3、增加阻塞等待机制

想象一种场景：
小明同学，取出一个任务，发现干不了，放回队列，再去取，取出来发现还是干不了，又放回去。反反复复。
小明童鞋肿么了？可能是他干活需要网络，网络断了。可能是他做任务需要写磁盘，磁盘满了。

如果小明像邻居家的孩子一样优秀，当他发现哪里不对的时候，他应该冷静下来，歇会儿。

但他万一不是呢？只有我们能帮他了。

假如队列中有10000个待办任务。
这时候小明来了。他失败100次后，我们应该拦他吗？不应该，除非他主动要求（在系统参数中配置）。5000次后呢？也不应该，除非他主动要求。我们的原则是：我们做的所有事情，对于调用者，都是可以预期的。

我们可以在系统参数中要求调用者设置一个阀值N，如果不设置，默认为100。连续失败N次后，让调用者睡一会儿，睡多长时间，让调用者配置。

假如我们的底层实现中包含待办子队列、重做子队列和完成子队列（这种设计好复杂！pop的时候先pop重做，还是先pop待办，复杂死了！但愿不需要这样）。
待办子队列中有10000个任务。

在小明失败10000次后，所有的任务都在重做子队列了。这时候我们应该拦他吗？
重做子队列要不要设置大小，超过之后，让下一个访问者等。
等的话就会涉及超时，超时后，任务也不能丢弃。
太复杂了！设置一个连续失败次数的限制就够了！

2.4、考虑增加Task类

不保存任务的相关数据是基本原则，绝对不动摇。
增加Task类可以管理下生命周期，更有用的是，可以把Task本身设计成Listener，代码大概时这样的：

public abstract class Task{

    public Serializable getId();
    public int getState();

    pubic void doTask();

    public void whenAdded(final TaskQueue tq);
    public void whenPoped(final TaskQueue tq);
    // public void whenFaild(final TaskQueue tq);
    public void whenFinished(final TaskQueue tq);
}
 
 1
2
3
4
5
6
7
8
9
10
11
12
 
 1
2
3
4
5
6
7
8
9
10
11
12