List基础数据
在Redis中，可通过list来简单的实现异步消息队列，他提供了lpush(left),rpush(right)，以及对应的lpop和rpop方法来实现对队列的自由操作，同样因为Redis的单线程执行模型，可以确保多实例和多线程对消息的消费不会出现并发问题。
通过指令来操作list结构
下面是一个消息队列的spring boot 后台任务，简单的定时轮询实现
首先开启spring boot后台任务调度
创建一个任务类MessageQueueSchedule并设置5s轮询一次，运行程序等待list中push数据进去：
通过控制台（也可以通过任意客户端，比如RedisDesktopManagerment，Spring Boot其他指令）来给list插入数据，在任务中会自动轮询并接收到消息：
在控制台中能够看到以下输出：
以上是对list的简单应用，相对于其他专业的消息队列中间件功能和模式都比较简单，管理工具几乎等于没有，无法和kafka等等中间件相提并论，上述方法可适用于一些简单的定时任务，消息传递发布的应用。
PubSub发布订阅
在上面的内容中讲了利用list来实现简单的消息队列，但是其有一定的不足，就是不支持消息的多播机制，在redis中直接提供和了publish/subscribe指令来实现发布订阅模式。
下面是利用尝试简单的pub/sub测试，利用两个Redis-Cli来演示：
1.首先利用subscribe指令来订阅一个topic（pub-test）
2.开启另一个cli客户端，publish一个message到pub-test
3.观察订阅主题的redis-cli，已经进入了订阅监听模式，并且在publish一个消息后，接收到消息：
通过以上对某个topic的发布订阅，可以做到消息的多播。
在redis的pub/sub机制中，也存在很多的缺点，消息类似于广播的机制，发布后的消息并不会存下来，所以只会发布给当时正在监听的消费者，假设有几个消费者，如果其中一个挂掉，则只有另外的消费者可以收到发布的消息，挂掉的消费者客户端再次链接的时候，是不会再次收到之前的消息的。
对于这种模式大多数情况下找不到应用模式，因为只能做到一个实时的通信并且不会将消息持久化，所以在Redis的历史长河中，并没有什么重要地位，甚至Redistemplate对他的支持比起其他的各种基本指令来说也比较繁杂。
从上所述，类似的多播和持久化甚至能够控制消费者对消息的历史消费点，更推荐Kafka这种专业的消息系统。